JDK_API剖析之java.util包

Java的实用工具类库java.util包。在这个包中，Java提供了一些实用的方法和数据结构。

一、接口

1、Collection<E>

• 接口
• 自1.2开始有
• 继承Iterable<E>
• Collection 层次结构 中的根接口。Collection 表示一组对象，这些对象也称为 collection 的 元素 。一些 collection 允许有重复的元素，而另一些则不允许。一些 collection 是有序的，而另一些则是无序的。JDK 不提供此接口的任何 直接 实现：它提供更具体的子接口（如 Set 和 List ）实现。此接口通常用来传递 collection，并在需要最大普遍性的地方操作这些 collection。

2、Comparator<T>

• 接口
• 自1.2开始有
• 无父类
• 强行对某个对象 collection 进行 整体排序 的比较函数。可以将 Comparator 传递给 sort 方法（如 Collections.sort 或 Arrays.sort ），从而允许在排序顺序上实现精确控制。还可以使用 Comparator 来控制某些数据结构（如 有序 set 或 有序映射 ）的顺序，或者为那些没有 自然顺序 的对象 collection 提供排序。

3、Deque<E>

• 接口
• 自1.6开始有
• 继承Queue<E>

• 一个线性 collection，支持在两端插入和移除元素。名称 deque 是“double ended queue（双端队列）”的缩写，通常读为“deck”。大多数 Deque 实现对于它们能够包含的元素数没有固定限制，但此接口既支持有容量限制的双端队列，也支持没有固定大小限制的双端队列。

4、Enumeration<E>

• 接口
• 自1.0开始有
• 继承Queue<E>

• 实现 Enumeration 接口的对象，它生成一系列元素，一次生成一个。连续调用 nextElement 方法将返回一系列的连续元素。

  例如，要输出 Vector<E> v 的所有元素，可使用以下方法：

     for (Enumeration<E> e = v.elements(); e.hasMoreElements();)
  
         System.out.println(e.nextElement());

  这些方法主要通过向量的元素、哈希表的键以及哈希表中的值进行枚举。枚举也用于将输入流指定到 SequenceInputStream 中。

  注：此接口的功能与 Iterator 接口的功能是重复的。此外，Iterator 接口添加了一个可选的移除操作，并使用较短的方法名。新的实现应该优先考虑使用 Iterator 接口而不是 Enumeration 接口。

5、 EventListener

• 标记接口
• 自1.1开始有
• 无父

• 所有事件侦听器接口必须扩展的标记接口。

• 没有方法定义

6、 Formattable

• 接口
• 自1.5开始有
• 无父

• Formattable 接口必须通过需要执行自定义格式化（使用 Formatter 的 's' 转换说明符）的任何类来实现。此接口允许对格式化任意对象的基本控制。

7、Iterator<E>

• 接口
• 自1.2开始有
• 无父

• 对 collection 进行迭代的迭代器。迭代器取代了 Java Collections Framework 中的 Enumeration。迭代器与枚举有两点不同：

  • 迭代器允许调用者利用定义良好的语义在迭代期间从迭代器所指向的 collection 移除元素。
  • 方法名称得到了改进。

  此接口是 Java Collections Framework 的成员。

8、List<E>

• 接口
• 自1.2开始有
• 继承Collection<E>

• 有序的 collection（也称为 序列 ）。此接口的用户可以对列表中每个元素的插入位置进行精确地控制。用户可以根据元素的整数索引（在列表中的位置）访问元素，并搜索列表中的元素。

  与 set 不同，列表通常允许重复的元素。更确切地讲，列表通常允许满足 e1.equals(e2) 的元素对 e1 和 e2 ，并且如果列表本身允许 null 元素的话，通常它们允许多个 null 元素。难免有人希望通过在用户尝试插入重复元素时抛出运行时异常的方法来禁止重复的列表，但我们希望这种用法越少越好。

  List 接口在 iterator 、 add 、 remove 、 equals 和 hashCode 方法的协定上加了一些其他约定，超过了 Collection 接口中指定的约定。为方便起见，这里也包括了其他继承方法的声明。

  List 接口提供了 4 种对列表元素进行定位（索引）访问方法。列表（像 Java 数组一样）是基于 0 的。注意，这些操作可能在和某些实现（例如 LinkedList 类）的索引值成比例的时间内执行。因此，如果调用者不知道实现，那么在列表元素上迭代通常优于用索引遍历列表。

  List 接口提供了特殊的迭代器，称为 ListIterator ，除了允许 Iterator 接口提供的正常操作外，该迭代器还允许元素插入和替换，以及双向访问。还提供了一个方法来获取从列表中指定位置开始的列表迭代器。

  List 接口提供了两种搜索指定对象的方法。从性能的观点来看，应该小心使用这些方法。在很多实现中，它们将执行高开销的线性搜索。

  List 接口提供了两种在列表的任意位置高效插入和移除多个元素的方法。

  注意：尽管列表允许把自身作为元素包含在内，但建议要特别小心：在这样的列表上， equals 和 hashCode 方法不再是定义良好的。

  某些列表实现对列表可能包含的元素有限制。例如，某些实现禁止 null 元素，而某些实现则对元素的类型有限制。试图添加不合格的元素会抛出未经检查的异常，通常是 NullPointerException 或 ClassCastException 。试图查询不合格的元素是否存在可能会抛出异常，也可能简单地返回 false；某些实现会采用前一种行为，而某些则采用后者。概括地说，试图对不合格元素执行操作时，如果完成该操作后不会导致在列表中插入不合格的元素，则该操作可能抛出一个异常，也可能成功，这取决于实现的选择。此接口的规范中将这样的异常标记为“可选”。

  此接口是 Java Collections Framework 的成员。

9、ListIterator<E>

• 接口
• 自1.2开始有
• 继承Iterator<E>

• 系列表迭代器，允许程序员按任一方向遍历列表、迭代期间修改列表，并获得迭代器在列表中的当前位置。 ListIterator 没有当前元素；它的 光标位置 始终位于调用 previous() 所返回的元素和调用 next() 所返回的元素之间。长度为 n 的列表的迭代器有 n+1 个可能的指针位置，如下面的插入符举例说明：

                        Element(0)   Element(1)   Element(2)   ... Element(n-1)
  
   cursor positions:  ^            ^            ^            ^                  ^
  

  注意， remove() 和 set(Object) 方法 不是 根据光标位置定义的；它们是根据对调用 next() 或 previous() 所返回的最后一个元素的操作定义的。

10、Map<K,V>

• 接口
• 自1.2开始有
• 无父

• 将键映射到值的对象。一个映射不能包含重复的键；每个键最多只能映射到一个值。

  此接口取代 Dictionary 类，后者完全是一个抽象类，而不是一个接口。

  Map 接口提供三种 collection 视图 ，允许以键集、值集或键-值映射关系集的形式查看某个映射的内容。映射 顺序 定义为迭代器在映射的 collection 视图上返回其元素的顺序。某些映射实现可明确保证其顺序，如 TreeMap 类；另一些映射实现则不保证顺序，如 HashMap 类。

11、Map.Entry<K,V>

• 接口
• 自1.2开始有
• 继承Iterator<E>
• 映射项（键-值对）。 Map.entrySet 方法返回映射的 collection 视图，其中的元素属于此类。获得映射项引用的 唯一 方法是通过此 collection 视图的迭代器来实现。这些 Map.Entry 对象 仅 在迭代期间有效；更确切地讲，如果在迭代器返回项之后修改了底层映射，则某些映射项的行为是不确定的，除了通过 setValue 在映射项上执行操作之外。

12、NavigableMap<K,V>

• 接口
• 自1.6开始有
• 继承SortedMap<E>
• 扩展的 SortedMap ，具有了针对给定搜索目标返回最接近匹配项的导航方法。方法 lowerEntry 、 floorEntry 、 ceilingEntry 和 higherEntry 分别返回与小于、小于等于、大于等于、大于给定键的键关联的 Map.Entry 对象，如果不存在这样的键，则返回 null 。类似地，方法 lowerKey 、 floorKey 、 ceilingKey 和 higherKey 只返回关联的键。所有这些方法是为查找条目而不是遍历条目而设计的。

13、NavigableSet<E>

• 接口
• 自1.6开始有
• 继承SortedSet<K，V>
• 扩展的 SortedSet ，具有了为给定搜索目标报告最接近匹配项的导航方法。方法 lower 、 floor 、 ceiling 和 higher 分别返回小于、小于等于、大于等于、大于给定元素的元素，如果不存在这样的元素，则返回 null 。可以按升序或降序访问和遍历 NavigableSet 。 descendingSet 方法返回 set 的一个视图，该视图表示的所有关系方法和方向方法都是逆向的。升序操作和视图的性能很可能比降序操作和视图的性能要好。此外，此接口还定义了 pollFirst 和 pollLast 方法，它们返回并移除最小和最大的元素（如果存在），否则返回 null 。 subSet 、 headSet 和 tailSet 方法与名称相似的 SortedSet 方法的不同之处在于：可以接受用于描述是否包括（或不包括）下边界和上边界的附加参数。任何 NavigableSet 的 Submap 必须实现 NavigableSet 接口。

14、Observer

• 接口
• 自1.0开始有
• 无父

• 一个可在观察者要得到 observable 对象更改通知时可实现 Observer 接口的类。

15、Queue<E>

• 接口
• 自1.5开始有
• 继承Collection<E>

• 在处理元素前用于保存元素的 collection。除了基本的 Collection 操作外，队列还提供其他的插入、提取和检查操作。每个方法都存在两种形式：一种抛出异常（操作失败时），另一种返回一个特殊值（ null 或 false ，具体取决于操作）。插入操作的后一种形式是用于专门为有容量限制的 Queue 实现设计的；在大多数实现中，插入操作不会失败。

  	抛出异常	返回特殊值
  插入	add(e)	offer(e)
  移除	remove()	poll()
  检查	element()	peek()

  队列通常（但并非一定）以 FIFO（先进先出）的方式排序各个元素。不过优先级队列和 LIFO 队列（或堆栈）例外，前者根据提供的比较器或元素的自然顺序对元素进行排序，后者按 LIFO（后进先出）的方式对元素进行排序。无论使用哪种排序方式，队列的 头 都是调用 remove() 或 poll() 所移除的元素。在 FIFO 队列中，所有的新元素都插入队列的 末尾 。其他种类的队列可能使用不同的元素放置规则。每个 Queue 实现必须指定其顺序属性。

  如果可能， offer 方法可插入一个元素，否则返回 false 。这与 Collection.add 方法不同，该方法只能通过抛出未经检查的异常使添加元素失败。 offer 方法设计用于正常的失败情况，而不是出现异常的情况，例如在容量固定（有界）的队列中。

  remove() 和 poll() 方法可移除和返回队列的头。到底从队列中移除哪个元素是队列排序策略的功能，而该策略在各种实现中是不同的。 remove() 和 poll() 方法仅在队列为空时其行为有所不同： remove() 方法抛出一个异常，而 poll() 方法则返回 null 。

  element() 和 peek() 返回，但不移除，队列的头。

  Queue 接口并未定义 阻塞队列的方法 ，而这在并发编程中是很常见的。 BlockingQueue 接口定义了那些等待元素出现或等待队列中有可用空间的方法，这些方法扩展了此接口。

  Queue 实现通常不允许插入 null 元素，尽管某些实现（如 LinkedList ）并不禁止插入 null 。即使在允许 null 的实现中，也不应该将 null 插入到 Queue 中，因为 null 也用作 poll 方法的一个特殊返回值，表明队列不包含元素。

  Queue 实现通常未定义 equals 和 hashCode 方法的基于元素的版本，而是从 Object 类继承了基于身份的版本，因为对于具有相同元素但有不同排序属性的队列而言，基于元素的相等性并非总是定义良好的。

16、RandomAccess

• 标记接口
• 自1.4开始有
• 无父

• List 实现所使用的标记接口，用来表明其支持快速（通常是固定时间）随机访问。此接口的主要目的是允许一般的算法更改其行为，从而在将其应用到随机或连续访问列表时能提供良好的性能。

  将操作随机访问列表的最佳算法（如 ArrayList ）应用到连续访问列表（如 LinkedList ）时，可产生二次项的行为。如果将某个算法应用到连续访问列表，那么在应用可能提供较差性能的算法前，鼓励使用一般的列表算法检查给定列表是否为此接口的一个 instanceof ，如果需要保证可接受的性能，还可以更改其行为。

  现在已经认识到，随机和连续访问之间的区别通常是模糊的。例如，如果列表很大时，某些 List 实现提供渐进的线性访问时间，但实际上是固定的访问时间。这样的 List 实现通常应该实现此接口。实际经验证明，如果是下列情况，则 List 实现应该实现此接口，即对于典型的类实例而言，此循环：

       for (int i=0, n=list.size(); i < n; i++)
  
           list.get(i);
   

  的运行速度要快于以下循环：

       for (Iterator i=list.iterator(); i.hasNext(); )
  
           i.next();
   

• 没有方法

17、Set<E>

• 接口
• 自1.2开始有
• 继承Collection<E>

• 一个不包含重复元素的 collection。更确切地讲，set 不包含满足 e1.equals(e2) 的元素对 e1 和 e2 ，并且最多包含一个 null 元素。正如其名称所暗示的，此接口模仿了数学上的 set 抽象。

  在所有构造方法以及 add 、 equals 和 hashCode 方法的协定上， Set 接口还加入了其他规定，这些规定超出了从 Collection 接口所继承的内容。出于方便考虑，它还包括了其他继承方法的声明（这些声明的规范已经专门针对 Set 接口进行了修改，但是没有包含任何其他的规定）。

  对这些构造方法的其他规定是（不要奇怪），所有构造方法必须创建一个不包含重复元素的 set（正如上面所定义的）。

  注：如果将可变对象用作 set 元素，那么必须极其小心。如果对象是 set 中某个元素，以一种影响 equals 比较的方式改变对象的值，那么 set 的行为就是不确定的。此项禁止的一个特殊情况是不允许某个 set 包含其自身作为元素。

  某些 set 实现对其所包含的元素有所限制。例如，某些实现禁止 null 元素，而某些则对其元素的类型所有限制。试图添加不合格的元素会抛出未经检查的异常，通常是 NullPointerException 或 ClassCastException 。试图查询不合格的元素是否存在可能会抛出异常，也可能简单地返回 false；某些实现会采用前一种行为，而某些则采用后者。概括地说，试图对不合格元素执行操作时，如果完成该操作后不会导致在 set 中插入不合格的元素，则该操作可能抛出一个异常，也可能成功，这取决于实现的选择。此接口的规范中将这样的异常标记为“可选”。

18、SortedMap<K,V>

• 接口
• 自1.2开始有
• 继承Map<K,V>

• 进一步提供关于键的 总体排序 的 Map 。该映射是根据其键的自然顺序进行排序的，或者根据通常在创建有序映射时提供的 Comparator 进行排序。对有序映射的 collection 视图（由 entrySet 、 keySet 和 values 方法返回）进行迭代时，此顺序就会反映出来。要采用此排序方式，还需要提供一些其他操作（此接口是 SortedSet 的对应映射）。

19、SortedSet<E>

• 接口
• 自1.2开始有
• 继承Set<E>

• 进一步提供关于元素的 总体排序 的 Set 。这些元素使用其自然顺序进行排序，或者根据通常在创建有序 set 时提供的 Comparator 进行排序。该 set 的迭代器将按元素升序遍历 set。提供了一些附加的操作来利用这种排序。（此接口是 SortedMap 的 set 对应接口）。

二、类

20、AbstractCollection<E>

• 抽象类
• 自1.2开始有
• 实现Collection<E>

• 此类提供 Collection 接口的骨干实现，以最大限度地减少了实现此接口所需的工作。

  要实现一个不可修改的 collection，编程人员只需扩展此类，并提供 iterator 和 size 方法的实现。（ iterator 方法返回的迭代器必须实现 hasNext 和 next 。）

  要实现可修改的 collection，编程人员必须另外重写此类的 add 方法（否则，会抛出 UnsupportedOperationException ）， iterator 方法返回的迭代器还必须另外实现其 remove 方法。

  按照 Collection 接口规范中的建议，编程人员通常应提供一个 void （无参数）和 Collection 构造方法。

  此类中每个非抽象方法的文档详细描述了其实现。如果要实现的 collection 允许更有效的实现，则可以重写这些方法中的每个方法。

21、AbstractList<E>

• 抽象类
• 自1.2开始有
• 继承AbstractCollection<E>,实现List<E>

• 此类提供 List 接口的骨干实现，以最大限度地减少实现“随机访问”数据存储（如数组）支持的该接口所需的工作。对于连续的访问数据（如链表），应优先使用 AbstractSequentialList ，而不是此类。

  要实现不可修改的列表，编程人员只需扩展此类，并提供 get(int) 和 size() 方法的实现。

  要实现可修改的列表，编程人员必须另外重写 set(int, E) 方法（否则将抛出 UnsupportedOperationException ）。如果列表为可变大小，则编程人员必须另外重写 add(int, E) 和 remove(int) 方法。

  按照 Collection 接口规范中的建议，编程人员通常应该提供一个 void（无参数）和 collection 构造方法。

  与其他抽象 collection 实现不同，编程人员 不必 提供迭代器实现；迭代器和列表迭代器由此类在以下“随机访问”方法上实现： get(int) 、 set(int, E) 、 add(int, E) 和 remove(int) 。

  此类中每个非抽象方法的文档详细描述了其实现。如果要实现的 collection 允许更有效的实现，则可以重写所有这些方法。

22、AbstractMap<K，V>

• 抽象类
• 自1.2开始有
• 实现Map<K,V>

• 此类提供 Collection 接口的骨干实现，以最大限度地减少了实现此接口所需的工作。

  要实现一个不可修改的 collection，编程人员只需扩展此类，并提供 iterator 和 size 方法的实现。（ iterator 方法返回的迭代器必须实现 hasNext 和 next 。）

  要实现可修改的 collection，编程人员必须另外重写此类的 add 方法（否则，会抛出 UnsupportedOperationException ）， iterator 方法返回的迭代器还必须另外实现其 remove 方法。

  按照 Collection 接口规范中的建议，编程人员通常应提供一个 void （无参数）和 Collection 构造方法。

  此类中每个非抽象方法的文档详细描述了其实现。如果要实现的 collection 允许更有效的实现，则可以重写这些方法中的每个方法。

23、AbstractMap.SimpleEntry<K,V>

• 类
• 自1.6开始有
• 实现Map.Entry<K,V>, Serializable

• 维护键和值的 Entry。可以使用 setValue 方法更改值。此类简化了构建自定义映射实现的过程。例如，可以使用 Map.entrySet().toArray 方法方便地返回 SimpleEntry 实例数组。

24、AbstractMap.SimpleImmutableEntry<K,V>

• 类
• 自1.6开始有
• 实现Map.Entry<K,V>, Serializable

• 维护不可变的键和值的 Entry。此类不支持 setValue 方法。在返回线程安全的键-值映射关系快照的方法中，此类也许很方便。

25、AbstractQueue<E>

• 抽象类
• 自1.5开始有
• 继承AbstractCollection<E>

• 此类提供某些 Queue 操作的骨干实现。此类中的实现适用于基本实现 不 允许包含 null 元素时。 add 、 remove 和 element 方法分别基于 offer 、 poll 和 peek 方法，但是它们通过抛出异常而不是返回 false 或 null 来指示失败。

  扩展此类的 Queue 实现至少必须定义一个不允许插入 null 元素的 Queue.offer(E) 方法，该方法以及 Queue.peek() 、 Queue.poll() 、 Collection.size() 和 Collection.iterator() 都支持 Iterator.remove() 方法。通常还要重写其他方法。如果无法满足这些要求，那么可以转而考虑为 AbstractCollection 创建子类。

26、AbstractSequentialList<E>

• 抽象类
• 自1.2开始有
• 继承AbstractList<E>

• 此类提供了 List 接口的骨干实现，从而最大限度地减少了实现受“连续访问”数据存储（如链接列表）支持的此接口所需的工作。对于随机访问数据（如数组），应该优先使用 AbstractList ，而不是先使用此类。

  从某种意义上说，此类与在列表的列表迭代器上实现“随机访问”方法（ get(int index) 、 set(int index, E element) 、 add(int index, E element) 和 remove(int index) ）的 AbstractList 类相对立，而不是其他关系。

  要实现一个列表，程序员只需要扩展此类，并提供 listIterator 和 size 方法的实现即可。对于不可修改的列表，程序员只需要实现列表迭代器的 hasNext 、 next 、 hasPrevious 、 previous 和 index 方法即可。

  对于可修改的列表，程序员应该再另外实现列表迭代器的 set 方法。对于可变大小的列表，程序员应该再另外实现列表迭代器的 remove 和 add 方法。

  按照 Collection 接口规范中的推荐，程序员通常应该提供一个 void（无参数）构造方法和 collection 构造方法。

27、AbstractSet<E>

• 抽象类
• 自1.2开始有
• 继承AbstractCollection<E>,实现Set<E>

• 此类提供 Set 接口的骨干实现，从而最大限度地减少了实现此接口所需的工作。

  通过扩展此类来实现一个 set 的过程与通过扩展 AbstractCollection 来实现 Collection 的过程是相同的，除了此类的子类中的所有方法和构造方法都必须服从 Set 接口所强加的额外限制（例如，add 方法必须不允许将一个对象的多个实例添加到一个 set 中）。

  注意，此类并没有重写 AbstractCollection 类中的任何实现。它仅仅添加了 equals 和 hashCode 的实现。

28、ArrayDeque<E>

• 类
• 自1.6开始有
• 实现Deque<E>,Cloneable,Serializable

• Deque 接口的大小可变数组的实现。数组双端队列没有容量限制；它们可根据需要增加以支持使用。它们不是线程安全的；在没有外部同步时，它们不支持多个线程的并发访问。禁止 null 元素。此类很可能在用作堆栈时快于 Stack ，在用作队列时快于 LinkedList 。

  大多数 ArrayDeque 操作以摊销的固定时间运行。异常包括 remove 、 removeFirstOccurrence 、 removeLastOccurrence 、 contains 、 iterator.remove() 以及批量操作，它们均以线性时间运行。

  此类的 iterator 方法返回的迭代器是 快速失败 的：如果在创建迭代器后的任意时间通过除迭代器本身的 remove 方法之外的任何其他方式修改了双端队列，则迭代器通常将抛出 ConcurrentModificationException 。因此，面对并发修改，迭代器很快就会完全失败，而不是冒着在将来不确定的时刻任意发生不确定行为的风险。

  注意，迭代器的快速失败行为不能得到保证，一般来说，存在不同步的并发修改时，不可能作出任何坚决的保证。快速失败迭代器尽最大努力抛出 ConcurrentModificationException 。因此，编写依赖于此异常的程序是错误的，正确做法是： 迭代器的快速失败行为应该仅用于检测 bug。

  此类及其迭代器实现 Collection 和 Iterator 接口的所有 可选 方法。

29、ArrayList<E>

• 类
• 自1.2开始有
• 继承AbstractList<E>实现List<E>, RandomAccess, Cloneable, java.io.Serializable

• List 接口的大小可变数组的实现。实现了所有可选列表操作，并允许包括 null 在内的所有元素。除了实现 List 接口外，此类还提供一些方法来操作内部用来存储列表的数组的大小。（此类大致上等同于 Vector 类，除了此类是不同步的。）

  size 、 isEmpty 、 get 、 set 、 iterator 和 listIterator 操作都以固定时间运行。 add 操作以 分摊的固定时间 运行，也就是说，添加 n 个元素需要 O(n) 时间。其他所有操作都以线性时间运行（大体上讲）。与用于 LinkedList 实现的常数因子相比，此实现的常数因子较低。

  每个 ArrayList 实例都有一个 容量 。该容量是指用来存储列表元素的数组的大小。它总是至少等于列表的大小。随着向 ArrayList 中不断添加元素，其容量也自动增长。并未指定增长策略的细节，因为这不只是添加元素会带来分摊固定时间开销那样简单。

  在添加大量元素前，应用程序可以使用 ensureCapacity 操作来增加 ArrayList 实例的容量。这可以减少递增式再分配的数量。

  注意，此实现不是同步的。 如果多个线程同时访问一个 ArrayList 实例，而其中至少一个线程从结构上修改了列表，那么它 必须 保持外部同步。（结构上的修改是指任何添加或删除一个或多个元素的操作，或者显式调整底层数组的大小；仅仅设置元素的值不是结构上的修改。）这一般通过对自然封装该列表的对象进行同步操作来完成。如果不存在这样的对象，则应该使用 Collections.synchronizedList 方法将该列表“包装”起来。这最好在创建时完成，以防止意外对列表进行不同步的访问：

          List list = Collections.synchronizedList(new ArrayList(...)); 

  此类的 iterator 和 listIterator 方法返回的迭代器是 快速失败的 ：在创建迭代器之后，除非通过迭代器自身的 remove 或 add 方法从结构上对列表进行修改，否则在任何时间以任何方式对列表进行修改，迭代器都会抛出 ConcurrentModificationException 。因此，面对并发的修改，迭代器很快就会完全失败，而不是冒着在将来某个不确定时间发生任意不确定行为的风险。

  注意，迭代器的快速失败行为无法得到保证，因为一般来说，不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器会尽最大努力抛出 ConcurrentModificationException 。因此，为提高这类迭代器的正确性而编写一个依赖于此异常的程序是错误的做法： 迭代器的快速失败行为应该仅用于检测 bug。

30、Arrays

• 类
• 自1.2开始有
• 无父

• 此类包含用来操作数组（比如排序和搜索）的各种方法。此类还包含一个允许将数组作为列表来查看的静态工厂。

  除非特别注明，否则如果指定数组引用为 null，则此类中的方法都会抛出 NullPointerException 。

  此类中所含方法的文档都包括对 实现 的简短描述。应该将这些描述视为 实现注意事项 ，而不应将它们视为 规范 的一部分。实现者应该可以随意替代其他算法，只要遵循规范本身即可。（例如， sort(Object[]) 使用的算法不必是一个合并排序算法，但它必须是 稳定的 。）

31、BitSet

• 类
• 自1.0开始有

• 实现Cloneable, Serializable

• 此类实现了一个按需增长的位向量。位 set 的每个组件都有一个 boolean 值。用非负的整数将 BitSet 的位编入索引。可以对每个编入索引的位进行测试、设置或者清除。通过逻辑与、逻辑或和逻辑异或操作，可以使用一个 BitSet 修改另一个 BitSet 的内容。

  默认情况下，set 中所有位的初始值都是 false 。

  每个位 set 都有一个当前大小，也就是该位 set 当前所用空间的位数。注意，这个大小与位 set 的实现有关，所以它可能随实现的不同而更改。位 set 的长度与位 set 的逻辑长度有关，并且是与实现无关而定义的。

  除非另行说明，否则将 null 参数传递给 BitSet 中的任何方法都将导致 NullPointerException 。

  在没有外部同步的情况下，多个线程操作一个 BitSet 是不安全的。

32、Calendar

• 抽象类
• 自1.1开始有

• 实现Serializable, Cloneable, Comparable< Calendar>

  Calendar 类是一个抽象类，它为特定瞬间与一组诸如 YEAR 、 MONTH 、 DAY_OF_MONTH 、 HOUR 等 日历字段 之间的转换提供了一些方法，并为操作日历字段（例如获得下星期的日期）提供了一些方法。瞬间可用毫秒值来表示，它是距 历元 （即格林威治标准时间 1970 年 1 月 1 日的 00:00:00.000，格里高利历）的偏移量。

  该类还为实现包范围外的具体日历系统提供了其他字段和方法。这些字段和方法被定义为 protected 。

  与其他语言环境敏感类一样， Calendar 提供了一个类方法 getInstance ，以获得此类型的一个通用的对象。 Calendar 的 getInstance 方法返回一个 Calendar 对象，其日历字段已由当前日期和时间初始化：

       Calendar rightNow = Calendar.getInstance();
   

  Calendar 对象能够生成为特定语言和日历风格实现日期-时间格式化所需的所有日历字段值，例如，日语-格里高里历，日语-传统日历。 Calendar 定义了某些日历字段返回值的范围，以及这些值的含义。例如，对于所有日历，日历系统第一个月的值是 MONTH == JANUARY 。其他值是由具体子类（例如 ERA ）定义的。有关此内容的细节，请参阅每个字段的文档和子类文档。