Java8 Collection接口源码阅读（一）

Collection接口是collection层次结构的根接口。一个collection表示一组对象，每个对象都是collection的元素。一些collection允许重复的元素，而另一些不允许。一些collection中的元素是有序的，而另一些collection中的元素是无序的。JDK不提供这个接口的直接实现，只是提供更具体的字类的实现，像Set和List。这个接口用来传递collection和操作它们，当只有Collection中提供的功能被需要的时候。

bag和multiset(包含重复元素的无序collection)应该直接实现这个接口。

所有通用目的的Collection实现类（通过实现Collection接口的一个子类间接时间Collection的类）应该提供两个标准构造器：一个空构造器（没有参数的构造器），这个构造器创建一个空的collection，还有一个带有单个Collection类型参数的构造器，这个构造器创建一个和它的参数中包含一样元素的collection。实际上，第二个构造器允许用户复制任何collection，创建一个希望的实现类型的拥有相同的元素的collection。这里没有办法强制实行这个约定，因为接口不能包含构造器，但是在Java平台库里的所有通用目的的Collection实现都遵从这个约定。

包含在这个接口中的“破坏性”的方法，也就是那些修改它们操作的collection的方法，被指定抛出UnsupportedOperationException，如果这个collection不支持这个操作的话。如果是这样，这些方法可以，但不必须，抛出UnsupportedOperationException，如果这个调用对collection没有影响的话。例如，在一个不能修改的collection上调用addAll（Collection）方法可能，但不是必须，抛出异常，如果被添加的collection是空的话。

一些collection实现对它包含的元素有所限制。例如，一些实现禁止null元素，一些实现对元素的类型有所限制。尝试添加一个不合格的元素会抛出一个未检查异常，典型的是NullPointerException或者ClassCastException。尝试查询是否包含某个不合格的元素可能抛出异常，或只是返回false；一些实现抛出异常，一些实现返回false。更普遍的是，在一个不合法的元素上尝试一个操作，这个操作的完成不会导致一个不合法的元素插入到collection中，可能抛出一个异常，也可能操作成功，由实现自己选择。在这个接口的规范中，这样的异常被标记为“可选”。

每个collection决定它自己的同步策略。在没有实现的强烈保证下，调用正在被其它线程修改的collection的任何方法都可能导致不确定的行为；这包括直接调用，传递这个collection给一个可能执行调用的方法，或者用一个已经存在的迭代器来检查这个collection。

Collections Framework接口中的许多方法都是根据equals方法定义的。例如，contains(Object o)方法的规范说，“当且仅当这个collection包含至少一个元素e,e满足o==null ? e==null : o.equals(e)时，返回真。”这个规范不应该被解释为暗指，调用带有非空参数o的Collection.contains方法会导致对任何元素e，o.equals(e)方法被调用。实现可以随意进行优化，只要避免调用equals方法，例如，通过最先比较两个元素额hash codes。（hashCode()规范保证，拥有不想等的hash codes的两个对象不可能相等。）更为普遍的是，只要实现者认为是合适的，不同的Collections Framework接口的实现可以利用底层方法指定的行为。

一些对collection执行递归便利的操作可能失败，并抛出一个自引用实例异常，因为这个collection直接或间接的包含自己。这些操作包括clone(), equals(), hashCode() 和toString()。实现可以可选的处理自引用，但是大部分现在的实现没有这么做。

这个接口是Java Collections Framework的一个成员。

default方法实现没有（继承而来的或者其它的）没有应用任何同步协议。如果一个Collection实现有一个指定的同步协议，它必须重写默认实现来应用这个协议。