源码版本：JDK 1.7。
集合 Collection，根据已知的内容可以知道有List、Set、Map（严格说，Map不属于Collection）等大类。
先查看 Collection，
public interface Collection<E> extends Iterable<E>
JDK说明如下：
/**
* The root interface in the <i>collection hierarchy</i>. A collection
* represents a group of objects, known as its <i>elements</i>. Some
* collections allow duplicate elements and others do not. Some are ordered
* and others unordered. The JDK does not provide any <i>direct</i>
* implementations of this interface: it provides implementations of more
* specific subinterfaces like <tt>Set</tt> and <tt>List</tt>. This interface
* is typically used to pass collections around and manipulate them where
* maximum generality is desired.
*
* <p><i>Bags</i> or <i>multisets</i> (unordered collections that may contain
* duplicate elements) should implement this interface directly.
*
* <p>All general-purpose <tt>Collection</tt> implementation classes (which
* typically implement <tt>Collection</tt> indirectly through one of its
* subinterfaces) should provide two "standard" constructors: a void (no
* arguments) constructor, which creates an empty collection, and a
* constructor with a single argument of type <tt>Collection</tt>, which
* creates a new collection with the same elements as its argument. In
* effect, the latter constructor allows the user to copy any collection,
* producing an equivalent collection of the desired implementation type.
* There is no way to enforce this convention (as interfaces cannot contain
* constructors) but all of the general-purpose <tt>Collection</tt>
* implementations in the Java platform libraries comply.
*
* <p>The "destructive" methods contained in this interface, that is, the
* methods that modify the collection on which they operate, are specified to
* throw <tt>UnsupportedOperationException</tt> if this collection does not
* support the operation. If this is the case, these methods may, but are not
* required to, throw an <tt>UnsupportedOperationException</tt> if the
* invocation would have no effect on the collection. For example, invoking
* the {@link #addAll(Collection)} method on an unmodifiable collection may,
* but is not required to, throw the exception if the collection to be added
* is empty.
*
* <p><a name="optional-restrictions"/>
* Some collection implementations have restrictions on the elements that
* they may contain. For example, some implementations prohibit null elements,
* and some have restrictions on the types of their elements. Attempting to
* add an ineligible element throws an unchecked exception, typically
* <tt>NullPointerException</tt> or <tt>ClassCastException</tt>. Attempting
* to query the presence of an ineligible element may throw an exception,
* or it may simply return false; some implementations will exhibit the former
* behavior and some will exhibit the latter. More generally, attempting an
* operation on an ineligible element whose completion would not result in
* the insertion of an ineligible element into the collection may throw an
* exception or it may succeed, at the option of the implementation.
* Such exceptions are marked as "optional" in the specification for this
* interface.
*
* <p>It is up to each collection to determine its own synchronization
* policy. In the absence of a stronger guarantee by the
* implementation, undefined behavior may result from the invocation
* of any method on a collection that is being mutated by another
* thread; this includes direct invocations, passing the collection to
* a method that might perform invocations, and using an existing
* iterator to examine the collection.
*
* <p>Many methods in Collections Framework interfaces are defined in
* terms of the {@link Object#equals(Object) equals} method. For example,
* the specification for the {@link #contains(Object) contains(Object o)}
* method says: "returns <tt>true</tt> if and only if this collection
* contains at least one element <tt>e</tt> such that
* <tt>(o==null ? e==null : o.equals(e))</tt>." This specification should
* <i>not</i> be construed to imply that invoking <tt>Collection.contains</tt>
* with a non-null argument <tt>o</tt> will cause <tt>o.equals(e)</tt> to be
* invoked for any element <tt>e</tt>. Implementations are free to implement
* optimizations whereby the <tt>equals</tt> invocation is avoided, for
* example, by first comparing the hash codes of the two elements. (The
* {@link Object#hashCode()} specification guarantees that two objects with
* unequal hash codes cannot be equal.) More generally, implementations of
* the various Collections Framework interfaces are free to take advantage of
* the specified behavior of underlying {@link Object} methods wherever the
* implementor deems it appropriate.
*
* <p>This interface is a member of the
* <a href="{@docRoot}/../technotes/guides/collections/index.html">
* Java Collections Framework</a>.
*
* @param <E> the type of elements in this collection
*
* @author Josh Bloch
* @author Neal Gafter
* @see Set
* @see List
* @see Map
* @see SortedSet
* @see SortedMap
* @see HashSet
* @see TreeSet
* @see ArrayList
* @see LinkedList
* @see Vector
* @see Collections
* @see Arrays
* @see AbstractCollection
* @since 1.2
*/
大意是：
Collection接口是集合框架的根接口。JDK没有为该接口提供任何直接实现，而是提供了更细化的子接口的实现，如Set、List。
所有通用目的的实现类应该提供两个标准构造方法：一个空参数的构造器、一个单参数且参数类型为Collection的构造器。没有强制措施，纯属自觉，JDK很自觉。
每个实现类的同步策略由自己决定。
集合框架接口的很多方法都是基于equals方法，例如contains(obj)。
不过，先不急于深入Collection接口，先看看其继承的Iterable接口，该接口只有一个方法：
public interface Iterable<T> {
Iterator<T> iterator();
}
继续展开 Iterator，还是一个接口：
public interface Iterator<E> {
boolean hasNext();
E next();
void remove();
}
如果使用过该接口，应该明白前两个方法的意义，一个用于判断是否还有下一个元素，另一个用于获取下一个元素同时移动游标。最后一个方法其实是删除当前指向的元素，属于可选的待实现接口方法。
事实上，该接口，Iterator取代了原有的Enumeration接口，对比一下就明白了：
public interface Enumeration<E> {
boolean hasMoreElements();
E nextElement();
}
Iterator 和 Enumeration 如出一辙，只不过 Iterator 更简洁，且多了一个操作。
再返回来看看 Iterable 接口，其唯一的方法是 iterator()，要求返回一个 Iterator对象；所以 Collection 接口的实现们必然实现该方法，来测试一下：
@Test
@SuppressWarnings({ "rawtypes", "unchecked" })
public void testIterator() {
Collection collection = null;
collection = new ArrayList();
collection.add(1);
collection.add(2);
collection.add(3); Iterator iterator = collection.iterator(); // Iterator
while (iterator.hasNext()) {
System.out.println(iterator.next());
}
}
OK，现在来看看Collection本身的接口：
public interface Collection<E> extends Iterable<E> {
// Query Operations - 查询操作
int size();
boolean isEmpty();
boolean contains(Object o);
Iterator<E> iterator();
Object[] toArray();
<T> T[] toArray(T[] a);
// Modification Operations - 修改操作
boolean add(E e);
boolean remove(Object o);
// Bulk Operations - 批量操作
boolean containsAll(Collection<?> c);
boolean addAll(Collection<? extends E> c);
boolean removeAll(Collection<?> c);
boolean retainAll(Collection<?> c);
void clear();
// Comparison and hashing - 对比和哈希
boolean equals(Object o);
int hashCode();
}
不明白为什么还有 iterator() 方法，冗余了吧。
上面的方法，对我来说最需要了解的就是 toArray() 和 toArray(T[] a) ：前者就是字面意思，将集合转成数组；后者虽然也是将集合转成数字，但是，会考虑集合的size和给定数组的length，如果给定数组能容纳集合的元素，则直接返回指定的数组（填充集合元素），否则，返回一个新创建的数组！ -- 就是说，可能会省略分配内存这一步骤。
来个示例：
@Test
public void testToArray() {
// 定义集合
Collection<String> collection = new ArrayList<>();
for (int i = 0; i != 5; ++i) {
collection.add(new String(new char[] { (char) ('a' + i) }));
collection.add(null);
}
System.out.println(collection); // // 定义目标数组
String[] t1 = new String[9];
Arrays.fill(t1, "xxx");
String[] t2 = new String[10];
Arrays.fill(t2, "xxx");
String[] t3 = new String[11];
Arrays.fill(t3, "xxx");
// 转换
String[] r1 = collection.toArray(t1);
String[] r2 = collection.toArray(t2);
String[] r3 = collection.toArray(t3); // 看看返回的数组是否原有数组
System.out.println(r1 == t1); // false
System.out.println(r2 == t2); // true
System.out.println(r3 == t3); // true System.out.println(Arrays.toString(r1));
System.out.println(Arrays.toString(r2));
System.out.println(Arrays.toString(r3)); // 注意，原数组如果仍有空余空间，全部null
}
>>>>>>>>>>>>>>>>>>>>>>>>>未完待续>>>>>>>>>>>>>>>>>>>>>>>>>