java 各个Map的区别

java各个Map的区别

ConcurrentHashMap

支持检索的完全并发和更新的所期望可调整并发的哈希表。（线程安全）此类遵守与Hashtable相同的功能规范，并且包括对应于Hashtable的每个方法的方法版本。不过，尽管所有操作都是线程安全的，但检索操作不必锁定，并且不支持以某种防止所有访问的方式锁定整个表。此类可以通过程序完全与Hashtable进行互操作，这取决于其线程安全，而与其同步细节无关。

检索操作（包括get）通常不会受阻塞，因此，可能与更新操作交迭（包括put和remove）。检索会影响最近完成的更新操作的结果。对于一些聚合操作，比如putAll和clear，并发检索可能只影响某些条目的插入和移除。类似地，在创建迭代器/枚举时或自此之后，Iterators和Enumerations返回在某一时间点上影响哈希表状态的元素。它们不会抛出

ConcurrentModificationException。不过，迭代器被设计成每次仅由一个线程使用。

这允许通过可选的concurrencyLevel构造方法参数（默认值为16）来引导更新操作之间的并发，该参数用作内部调整大小的一个提示。表是在内部进行分区的，试图允许指示无争用并发更新的数量。因为哈希表中的位置基本上是随意的，所以实际的并发将各不相同。理想情况下，应该选择一个尽可能多地容纳并发修改该表的线程的值。使用一个比所需要的值高很多的值可能会浪费空间和时间，而使用一个显然低很多的值可能导致线程争用。对数量级估计过高或估计过低通常都会带来非常显著的影响。当仅有一个线程将执行修改操作，而其他所有线程都只是执行读取操作时，才认为某个值是合适的。此外，重新调整此类或其他任何种类哈希表的大小都是一个相对较慢的操作，因此，在可能的时候，提供构造方法中期望表大小的估计值是一个好主意。（开始构造函数到时候必须考虑到他们的容量和因子）对于经常迭代时更重要

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

此类与Hashtable相似，但与HashMap不同，它“不”允许将null用作键或值。

此类是Java Collections Framework的成员。

EnumMap

与枚举类型键一起使用的专用Map实现。枚举映射中所有键都必须来自单个枚举类型，该枚举类型在创建映射时显式或隐式地指定。枚举映射在内部表示为数组。此表示形式非常紧凑且高效。

枚举映射根据其键的自然顺序来维护（该顺序是声明枚举常量的顺序）。在集合视图（keySet()、entrySet()和values()）所返回的迭代器中反映了这一点。

由集合视图返回的迭代器是弱一致的：它们不会抛出

ConcurrentModificationException，也不一定显示在迭代进行时发生的任何映射修改的效果。

不允许使用null键。试图插入null键将抛出NullPointerException。但是，试图测试是否出现null键或移除null键将不会抛出异常。允许使用null值。

像大多数集合一样，EnumMap是不同步的。(HashMap)如果多个线程同时访问一个枚举映射，并且至少有一个线程修改该映射，则此枚举映射在外部应该是同步的。这一般通过对自然封装该枚举映射的某个对象进行同步来完成。如果不存在这样的对象，则应该使用Collections.synchronizedMap(java.util.Map)方法来“包装”该枚举。最好在创建时完成这一操作，以防止意外的非同步访问：Mapm=Collections.synchronizedMap(newEnumMap(...));实现注意事项：所有基本操作都在固定时间内执行。虽然并不保证，但它们很可能比其HashMap副本更快。

HashMap

基于哈希表的Map接口的实现。此实现提供所有可选的映射操作，并允许使用null值和null键。（除了不同步和允许使用null之外，HashMap类与Hashtable大致相同。）此类不保证映射的顺序，特别是它不保证该顺序恒久不变。

此实现假定哈希函数将元素正确分布在各桶之间，可为基本操作（get和put）提供稳定的性能。迭代集合视图所需的时间与HashMap实例的“容量”（桶的数量）及其大小（键-值映射关系数）的和成比例。所以，如果迭代性能很重要，则不要将初始容量设置得太高（或将加载因子设置得太低）。

HashMap的实例有两个参数影响其性能：初始容量和加载因子。容量是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时，通过调用rehash方法将容量翻倍。通常，默认加载因子(.75)在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销，但同时也增加了查询成本（在大多数HashMap类的操作中，包括get和put操作，都反映了这一点）。在设置初始容量时应该考虑到映射中所需的条目数及其加载因子，以便最大限度地降低rehash操作次数。如果初始容量大于最大条目数除以加载因子，则不会发生rehash操作。

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

注意，此实现不是同步的。如果多个线程同时访问此映射，而其中至少一个线程从结构上修改了该映射，则它必须保持外部同步。（结构上的修改是指添加或删除一个或多个映射关系的操作；仅改变与实例已经包含的键关联的值不是结构上的修改。）这一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在这样的对象，则应该使用Collections.synchronizedMap方法来“包装”该映射。最好在创建时完成这一操作，以防止对映射进行意外的不同步访问，如下所示：

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

由所有此类的“集合视图方法”所返回的迭代器都是快速失败的：在迭代器创建之后，如果从结构上对映射进行修改，除非通过迭代器自身的remove或add方法，其他任何时间任何方式的修改，迭代器都将抛出

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

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

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

IdentityHashMap

此类利用哈希表实现Map接口，比较键（和值）时使用引用相等性代替对象相等性。换句话说，在IdentityHashMap中，当且仅当(k1==k2)时，才认为两个键k1和k2相等（在正常Map实现（如HashMap）中，当且仅当满足下列条件时才认为两个键k1和k2相等：(k1==null ? k2==null :

e1.equals(e2))）。

此类不是通用Map实现！此类实现Map接口时，它有意违反Map的常规协定，该协定在比较对象时强制使用equals方法。此类设计仅用于其中需要引用相等性语义的罕见情况。此类的典型用法是拓扑保留对象图形转换，如序列化或深层复制。要执行这样的转换，程序必须维护用于跟踪所有已处理对象引用的“节点表”。节点表一定不等于不同对象，即使它们偶然相等也如此。此类的另一种典型用法是维护代理对象。例如，调试设施可能希望为正在调试程序中的每个对象维护代理对象。

此类提供所有的可选映射操作，并且允许null值和null键。此类对映射的顺序不提供任何保证；特别是不保证顺序随时间的推移保持不变。

此类提供基本操作（get和put）的稳定性能，假定系统标识了将桶间元素正确分开的哈希函数(System.identityHashCode(Object))。

此类具有一个调整参数（影响性能但不影响语义）：expected maximum size。

此参数是希望映射保持的键值映射关系最大数。在内部，此参数用于确定最初组成哈希表的桶数。未指定所期望的最大数量和桶数之间的确切关系。

如果映射的大小（键值映射关系数）已经超过期望的最大数量，则桶数会增加，增加桶数（“重新哈希”）可能相当昂贵，因此创建具有足够大的期望最大数量的标识哈希映射更合算。另一方面，对collection视图进行迭代所需的时间与哈希表中的桶数成正比，所以如果特别注重迭代性能或内存使用，则不宜将期望的最大数量设置得过高。

注意，此实现不是同步的。如果多个线程同时访问此映射，并且其中至少一个线程从结构上修改了该映射，则其必须保持外部同步（结构上的修改是指添加或删除一个或多个映射关系的操作；仅改变与实例已经包含的键关联的值不是结构上的修改。）这一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在这样的对象，则应该使用Collections.synchronizedMap方法来“包装”该映射。最好在创建时完成这一操作，以防止对映射进行意外的不同步访问，如下所示：

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

由所有此类的“collection 视图方法”所返回的迭代器都是快速失败的：在迭代器创建之后，如果从结构上对映射进行修改，除非通过迭代器自身的remove 或add方法，其他任何时间任何方式的修改，迭代器都将抛出

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

注意，迭代器的快速失败行为不能得到保证，一般来说，存在不同步的并发修改时，不可能作出任何强有力的保证。快速失败迭代器尽最大努力抛出

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

实现注意事项：此为简单的线性探头哈希表，如Sedgewick和Knuth原文示例中所述。该数组交替保持键和值（对于大型表来说，它比使用独立组保持键

和值更具优势）。对于多数JRE实现和混合操作，此类比HashMap（它使用链而不使用线性探头）能产生更好的性能。

此类是Java Collections Framework的成员。

TreeMap

SortedMap接口的基于红黑树的实现。此类保证了映射按照升序顺序排列关键字，根据使用的构造方法不同，可能会按照键的类的自然顺序进行排序（参见Comparable），或者按照创建时所提供的比较器进行排序。

此实现为containsKey、get、put和remove操作提供了保证的log(n)时间开销。这些算法是Cormen、Leiserson和Rivest的《Introduction toAlgorithms》中的算法的改编。

注意，如果有序映射要正确实现Map接口，则有序映射所保持的顺序（无论是否明确提供比较器）都必须保持与等号一致。（请参见与等号一致的精确定义的Comparable或Comparator。）这也是因为Map接口是按照等号操作定义的，但映射使用它的compareTo（或compare）方法对所有键进行比较，因此从有序映射的观点来看，此方法认为相等的两个键就是相等的。即使顺序与等号不一致，有序映射的行为仍然是定义良好的；只不过没有遵守Map接口的常规约定。

注意，此实现不是同步的。如果多个线程同时访问一个映射，并且其中至少一个线程从结构上修改了该映射，则其必须保持外部同步。（结构上修改是指添加或删除一个或多个映射关系的操作；仅改变与现有键关联的值不是结构上的修改。）这一般通过对自然封装该映射的某个对象进行同步操作来完成。如果不存在这样的对象，则应该使用Collections.synchronizedMap方法来“包装”该映射。最好在创建时完成这一操作，以防止对映射进行意外的不同步访问，如下所示：

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

由所有此类的“collection 视图方法”所返回的迭代器都是快速失败的：在迭代器创建之后，如果从结构上对映射进行修改，除非通过迭代器自身的remove 或add方法，其他任何时间任何方式的修改，迭代器都将抛出

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

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

此类是Java Collections Framework的成员。