基于哈希表的Map接口的实现。
此实现提供了所有可选的映射操作，并允许null值和null键。
（ HashMap类大致相当于Hashtable ，除了它是不同步的并且允许空值。）此类不保证地图的顺序;
特别是，它不保证订单会随着时间的推移保持不变。
该实现为基本操作（ get和put ）提供了恒定时间性能，假设散列函数在桶之间正确地分散元素。 对集合视图的迭代需要与HashMap实例的“容量”（桶数）加上其大小（键值映射的数量）成比例的时间。 因此，如果迭代性能很重要，则不要将初始容量设置得太高（或负载因子太低）非常重要。
HashMap的实例有两个影响其性能的参数： 初始容量和负载因子 。 容量是哈希表中的桶数，初始容量只是创建哈希表时的容量。 加载因子是在自动增加容量之前允许哈希表获取的完整程度的度量。 当哈希表中的条目数超过加载因子和当前容量的乘积时，哈希表将被重新哈希（即，重建内部数据结构），以便哈希表具有大约两倍的桶数。
作为一般规则，默认加载因子（.75）在时间和空间成本之间提供了良好的折衷。 较高的值会减少空间开销，但会增加查找成本（反映在HashMap类的大多数操作中，包括get和put ）。 在设置其初始容量时，应考虑映射中的预期条目数及其负载因子，以便最小化重新散列操作的数量。 如果初始容量大于最大条目数除以加载因子，则不会发生重新加载操作。
如果要将多个映射存储在HashMap实例中，则使用足够大的容量创建映射将允许映射更有效地存储，而不是根据需要执行自动重新散列来扩展表。 请注意，使用具有相同hashCode()许多键是减慢任何哈希表性能的可靠方法。 为了改善影响，当键为Comparable时 ，此类可以使用键之间的比较顺序来帮助打破关系。
请注意，此实现不同步。 如果多个线程同时访问哈希映射，并且至少有一个线程在结构上修改了映射，则必须在外部进行同步。 （结构修改是添加或删除一个或多个映射的任何操作;仅更改与实例已包含的键关联的值不是结构修改。）这通常通过同步自然封装映射的某个对象来完成。 。 如果不存在此类对象，则应使用Collections.synchronizedMap方法“包装”地图。 这最好在创建时完成，以防止意外地不同步访问地图：
Map m = Collections.synchronizedMap(new HashMap(...));
所有这个类的“集合视图方法”返回的迭代器都是快速失败的 ：如果在创建迭代器之后的任何时候对映射进行结构修改，除了通过迭代器自己的remove方法之外，迭代器将抛出ConcurrentModificationException 。 因此，在并发修改的情况下，迭代器快速而干净地失败，而不是在未来的未确定时间冒任意，非确定性行为的风险。
请注意，迭代器的快速失败行为无法得到保证，因为一般来说，在存在不同步的并发修改时，不可能做出任何硬性保证。 失败快速迭代器以尽力而为的方式抛出ConcurrentModificationException 。 因此，编写依赖于此异常的程序以确保其正确性是错误的： 迭代器的快速失败行为应该仅用于检测错误。
此类是Java Collections Framework的成员。