HashMap 和 LinkedHashMap

HashMap 和 LinkedHashMap

HashMap: 

基于哈希表的 Map 接口的实现。

此实现提供所有可选的映射操作，并允许使用 null 值和 null 键。

（除了非同步和允许使用 null 之外，HashMap 类与 Hashtable 大致相同。）此类不保证映射的顺序，特别是它不保证该顺序恒久不变。

此实现假定哈希函数将元素适当地分布在各桶之间，可为基本操作（get 和 put）提供稳定的性能。

迭代 collection 视图所需的时间与 HashMap 实例的“容量”（桶的数量）及其大小（键-值映射关系数）成比例。

所以，如果迭代性能很重要，则不要将初始容量设置得太高（或将加载因子设置得太低）。

HashMap 的实例有两个参数影响其性能：初始容量 和加载因子。

容量 是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。

加载因子 是哈希表在其容量自动增加之前可以达到多满的一种尺度。

当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表进行 rehash 操作（即重建内部数据结构），从而哈希表将具有大约两倍的桶数。

通常，默认加载因子 (.75) 在时间和空间成本上寻求一种折衷。

加载因子过高虽然减少了空间开销，但同时也增加了查询成本（在大多数 HashMap 类的操作中，包括 get 和 put 操作，都反映了这一点）。

在设置初始容量时应该考虑到映射中所需的条目数及其加载因子，以便最大限度地减少 rehash 操作次数。

如果初始容量大于最大条目数除以加载因子，则不会发生 rehash 操作。

如果很多映射关系要存储在 HashMap 实例中，则相对于按需执行自动的 rehash 操作以增大表的容量来说，使用足够大的初始容量创建它将使得映射关系能更有效地存储。

注意， 此实现不是同步的。如果多个线程同时访问一个哈希映射，而其中至少一个线程从结构上修改了该映射，则它必须 保持外部同步。

（结构上的修改是指添加或删除一个或多个映射关系的任何操作；仅改变与实例已经包含的键关联的值不是结构上的修改。）

这一般通过对自然封装该映射的对象进行同步操作来完成。

如果不存在这样的对象，则应该使用 Collections.synchronizedMap 方法来“包装”该映射。

最好在创建时完成这一操作，以防止对映射进行意外的非同步访问，如下所示：

  Map m = Collections.synchronizedMap(new HashMap(...));

由所有此类的“collection 视图方法”所返回的迭代器都是快速失败 的：

在迭代器创建之后，如果从结构上对映射进行修改，除非通过迭代器本身的 remove 方法，其他任何时间任何方式的修改，迭代器都将抛出 ConcurrentModificationException。

因此，面对并发的修改，迭代器很快就会完全失败，而不冒在将来不确定的时间发生任意不确定行为的风险。

注意，迭代器的快速失败行为不能得到保证，一般来说，存在非同步的并发修改时，不可能作出任何坚决的保证。

快速失败迭代器尽最大努力抛出 ConcurrentModificationException。

因此，编写依赖于此异常的程序的做法是错误的，正确做法是：迭代器的快速失败行为应该仅用于检测程序错误。

LinkedHashMap:

Map 接口的哈希表和链接列表实现，具有可预知的迭代顺序。

此实现与 HashMap 的不同之处在于，后者维护着一个运行于所有条目的 双重链接列表。

此 链接列表定义了迭代顺序，该迭代顺序通常就是将键插入到映射中的顺序（插入顺序）。

注意，如果在映射中重新插入 键，则插入顺序不受影响。（如果在调用 m.put(k, v) 前 m.containsKey(k) 返回了 true，则调用时会将键 k 重新插入到映射 m 中。）

此实现可以让客户避免未指定的、由 HashMap（及 Hashtable）所提供的通常为杂乱无章的排序工作，同时无需增加与 TreeMap 相关的成本。

使用它可以生成一个与原来顺序相同的映射副本，而与原映射的实现无关：

  void foo(Map m) {

  Map copy = new LinkedHashMap(m);

  ...

  }

如果模块通过输入得到一个映射，复制这个映射，然后返回由此副本确定其顺序的结果，这种情况下这项技术特别有用。（客户通常期望返回的内容与其出现的顺序相同。）

提供特殊的构造方法来创建链接哈希映射，该哈希映射的迭代顺序就是最后访问其条目的顺序，从近期访问最少到近期访问最多的顺序（ 访问顺序）。

这种映射很适合构建 LRU 缓存。

调用 put 或 get 方法将会访问相应的条目（假定调用完成后它还存在）。

putAll 方法以指定映射的条目集迭代器提供的键-值映射关系的顺序，为指定映射的每个映射关系生成一个条目访问。

任何其他方法均不生成条目访问。特别是，collection 视图上的操作不 影响底层映射的迭代顺序。

可以重写 removeEldestEntry(Map.Entry) 方法来实施策略，以便在将新映射关系添加到映射时自动移除旧的映射关系。

此类提供所有可选的 Map 操作，并且允许 null 元素。

与 HashMap 一样，它可以为基本操作（add、contains 和 remove）提供稳定的性能，假定哈希函数将元素正确分布到桶中。

由于增加了维护链接列表的开支，其性能很可能比 HashMap 稍逊一筹，

不过这一点例外： LinkedHashMap 的 collection 视图迭代所需时间与映射的大小 成比例。

HashMap 迭代时间很可能开支较大，因为它所需要的时间与其容量 成比例。

链接的哈希映射具有两个影响其性能的参数：初始容量和加载因子。

它们的定义与 HashMap 极其相似。

要注意，为初始容量选择非常高的值对此类的影响比对 HashMap 要小，因为此类的迭代时间不受容量的影响。

注意， 此实现不是同步的。如果多个线程同时访问链接的哈希映射，而其中至少一个线程从结构上修改了该映射，则它必须 保持外部同步。

这一般通过对自然封装该映射的对象进行同步操作来完成。

如果不存在这样的对象，则应该使用 Collections.synchronizedMap 方法来“包装”该映射。

最好在创建时完成这一操作，以防止对映射的意外的非同步访问：

  Map m = Collections.synchronizedMap(new LinkedHashMap(...));

结构修改是指添加或删除一个或多个映射关系，或者在按访问顺序链接的哈希映射中影响迭代顺序的任何操作。

在按插入顺序链接的哈希映射中，仅更改与映射中已包含键关联的值不是结构修改。在按访问顺序链接的哈希映射中，仅利用 get 查询映射不是结构修改。）

Collection（由此类的所有 collection 视图方法所返回）的 iterator 方法返回的迭代器都是快速失败 的：

在迭代器创建之后，如果从结构上对映射进行修改，除非通过迭代器自身的 remove 方法，其他任何时间任何方式的修改，迭代器都将抛出 ConcurrentModificationException。

因此，面对并发的修改，迭代器很快就会完全失败，而不冒将来不确定的时间任意发生不确定行为的风险。

注意，迭代器的快速失败行为无法得到保证，因为一般来说，不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器会尽最大努力抛出 ConcurrentModificationException。

因此，编写依赖于此异常的程序的方式是错误的，正确做法是：迭代器的快速失败行为应该仅用于检测程序错误。

总结：

1.HashMap内部使用键值对数组存储 Entry<K,V>[] table ，数组中每个元素是一个键值对链表，散列存储。

2.LinkedHashMap 是双向链表，内部使用链表存储

3. Hashtable与HashMap类似，

不同的是：它不允许记录的键或者值为空；它支持线程的同步，即任一时刻只有一个线程能写Hashtable，因此也导致了Hashtable在写入时会比较慢。

4.HashMap 扩容 直接扩容二倍。

5.HashMap允许一个键为null的键值对。TreeMap不允许键为null的键值对。

因为TreeMap通过比较器比较后对键值对进行排序，使用比较器进行比较时需要将Object类型向下转型，转型过程中如果对象为NullPointerException()。