HashMap中负载因子的意义是什么？

学习记录 HashMap中负载因子的意义是什么？

HashMap具有两个重要属性：

`size` 和 `load factor`

HashMap的实例具有两个影响其性能的参数：初始容量(0.75f)和负载因子(load factor)。
容量是哈希表中存储桶的数量，初始容量只是创建哈希表时的容量。
负载因子是在自动增加其哈希表容量之前允许哈希表获得的满度的度量。
当哈希表中的条目数超过负载因子和当前容量的乘积时，哈希表将被重新哈希
（即，内部数据结构将被重建），因此哈希表的存储桶数大约为两倍。通常，默认负载因子（.75）在时间和空间成本之间提供了一个很好的折中方案。
较高的值会减少空间开销，但会增加查找成本（在HashMap类的大多数操作中都得到体现，
包括get和put）。设置映射表的初始容量时，应考虑映射中的预期条目数及其负载因子，
以最大程度地减少重新哈希操作的数量。如果初始容量大于最大条目数除以负载因子，
则将不会进行任何哈希操作。与所有性能优化一样，最好避免过早地进行优化（例如，没有关于瓶颈所在的硬数据）。

HashMap文档：

1.基于哈希表的Map接口的实现。此实现提供所有可选的映射操作，并允许空值和空键。（HashMap 类与Hashtable大致等效，不同之处在于它是不同步的，并且允许为null。）此类不保证映射的顺序。特别是，它不能保证顺序会随着时间的推移保持恒定。

2.假设哈希函数将元素正确分散在存储桶中，则此实现为基本操作（get和put）提供恒定时间的性能。集合视图上的迭代所需的时间与HashMap实例的“容量” （存储桶数）及其大小（键-值映射数）成正比。因此，如果迭代性能很重要，则不要将初始容量设置得过高（或负载因子过低），这一点非常重要。

3.HashMap的实例具有两个影响其性能的参数：初始容量和负载因子。的容量是在哈希表中桶的数量，和初始容量是简单地在创建哈希表中的时间的能力。该负载系数是的哈希表是如何充分允许获得之前它的容量自动增加的措施。当哈希表中的条目数超过负载因子和当前容量的乘积时，哈希表将被重新哈希（即，内部数据结构将被重建），因此哈希表的存储桶数大约为两倍。

4.通常，默认负载因子（.75）在时间和空间成本之间提供了一个很好的折衷方案。较高的值会减少空间开销，但会增加查找成本（在HashMap类的大多数操作中都得到体现，包括get和put）。设置映射表的初始容量时，应考虑映射中的预期条目数及其负载因子，以最大程度地减少重新哈希操作的数量。如果初始容量大于最大条目数除以负载因子，则将不会进行任何哈希操作。

5.如果要将许多映射存储在HashMap实例中，则创建具有足够大容量的映射将比使它根据需要增长表的自动重新哈希处理更有效地存储映射。

6.请注意，此实现未同步。如果多个线程同时访问哈希映射，并且至少有一个线程在结构上修改该映射，则必须在外部进行同步。（结构修改是添加或删除一个或多个映射的任何操作；仅更改与实例已经包含的键相关联的值不是结构修改。）通常通过在自然封装了地图的某个对象上进行同步来实现。。如果不存在这样的对象，则应使用Collections.synchronizedMap 方法“包装”地图。最好在创建时完成此操作，以防止意外不同步地访问Map：
Map m = Collections.synchronizedMap(new HashMap(…));

7.由此类的所有“集合视图方法”返回的迭代器都是快速失败的：如果在创建迭代器后的任何时间以任何方式对地图进行结构修改，除非通过迭代器自己的 remove方法，否则迭代器将抛出 ConcurrentModificationException。因此，面对并发修改，迭代器会快速干净地失败，而不会在未来的不确定时间内冒任意，不确定的行为的风险。

8.请注意，迭代器的快速失败行为无法得到保证，因为通常来说，在存在不同步的并发修改的情况下，不可能做出任何严格的保证。快速失败的迭代器会尽最大努力抛出ConcurrentModificationException。因此，编写依赖于此异常的程序以确保其正确性是错误的：迭代器的快速失败行为应仅用于检测错误。

什么是HashMap?

HashMap 是一个用于存储Key-Value 键值对的集合，每一个键值对也叫做Entry。
这些个Entry 分散存储在一个数组当中，这个数组就是HashMap 的主干。
HashMap 数组每一个元素的初始值都是Null。

如图一：

Put 方法的原理
调用Put方法的时候发生了什么呢？
比如调用 hashMap.put(“apple”, 0) ，插入一个Key为“apple”的元素。这时候我们需要利用一个哈希函数来确定Entry的插入位置（index）：
index = Hash（“apple”）
假定最后计算出的index是2，那么结果如下：
如图二：

但是，因为HashMap的长度是有限的，当插入的Entry越来越多时，再完美的Hash函数也难免会出现index冲突的情况。比如下面这样：
如图三：

这时候该怎么办呢？我们可以利用链表来解决。
HashMap数组的每一个元素不止是一个Entry对象，也是一个链表的头节点。每一个Entry对象通过Next指针指向它的下一个Entry节点。当新来的Entry映射到冲突的数组位置时，只需要插入到对应的链表即可：
如图四：

新来的Entry节点插入链表时，使用的是“头插法。

Get方法的原理
使用Get方法根据Key来查找Value的时候，发生了什么呢？
首先会把输入的Key做一次Hash映射，得到对应的index：
index = Hash（“apple”）
由于刚才所说的Hash冲突，同一个位置有可能匹配到多个Entry，这时候就需要顺着对应链表的头节点，一个一个向下来查找。假设我们要查找的Key是“apple”：
如图五：

第一步，我们查看的是头节点Entry6，Entry6的Key是banana，显然不是我们要找的结果。
第二步，我们查看的是Next节点Entry1，Entry1的Key是apple，正是我们要找的结果。
之所以把Entry6放在头节点，是因为HashMap的发明者认为，后插入的Entry被查找的可能性更大。

HashMap的初始长度
初始长度为16，且每次自动扩容或者手动初始化的时候必须是2的幂。
如何进行位运算呢？有如下的公式（Length是HashMap的长度）：
之前说过，从Key映射到HashMap数组的对应位置，会用到一个Hash函数：
index = Hash（“apple”）
如何实现一个尽量均匀分布的Hash函数呢？我们通过利用Key的HashCode值来做某种运算。
index = HashCode（Key） & （Length - 1）
下面我们以值为“book”的Key来演示整个过程：

计算book的hashcode，结果为十进制的3029737，二进制的101110001110101110 1001。
假定HashMap长度是默认的16，计算Length-1的结果为十进制的15，二进制的1111。
把以上两个结果做与运算，101110001110101110 1001 & 1111 = 1001，
十进制是9，所以 index=9。

可以说，Hash算法最终得到的index结果，完全取决于Key的Hashcode值的最后几位。
这里的位运算其实是一种快速取模算法。

HashMap 的size为什么必须是2的幂?。这是因为2的幂用二进制表示时所有位都为1，例如16-1=15 的二进制就是1111B。我们说了Hash算法是为了让hash 的分布变得均匀。其实我们可以把1111看成四个通道，表示跟1111 做&运算后分布是均匀的。假如默认长度取10，二进制表示为1010，这样就相当于有两个通道是关闭的，所以计算出来的索引重复的几率比较大。

与君共勉

我要一步一步往上爬
在最高点乘着叶片往前飞
任风吹干流过的泪和汗
我要一步一步往上爬
等待阳光静静看着它的脸
小小的天有大大的梦想
我有属于我的天
任风吹干流过的泪和汗
总有一天我有属于我的天