再也不用怕HashMap

HashMap是最高频的考点了，必须深入复习。

参考链接

1. 漫画：什么是HashMap？
2. 漫画：高并发下的HashMap
3. HashMap? ConcurrentHashMap? 相信看完这篇没人能难住你！

引入

HashMap初认识

众所周知，HashMap是一个用于存储Key-Value键值对的集合，每一个键值对也叫做Entry。这些个键值对（Entry）分散存储在一个数组当中，这个数组就是HashMap的主干。

HashMap数组每一个元素的初始值都是Null。

对于HashMap，我们最常使用的是两个方法：Get 和 Put。

put

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节点插入链表时，使用的是“头插法”。因为HashMap的发明者认为，后插入的Entry被查找的可能性更大。

get

使用Get方法根据Key来查找Value的时候，发生了什么呢？

首先会把输入的Key做一次Hash映射，得到对应的index：index = Hash（“apple”）

由于刚才所说的Hash冲突，同一个位置有可能匹配到多个Entry，这时候就需要顺着对应链表的头节点，一个一个向下来查找。假设我们要查找的Key是“apple”：

第一步，我们查看的是头节点Entry6，Entry6的Key是banana，显然不是我们要找的结果。

第二步，我们查看的是Next节点Entry1，Entry1的Key是apple，正是我们要找的结果。

深入问题

HashMap初始长度是16

之前说过，从Key映射到HashMap数组的对应位置，会用到一个Hash函数：

index = Hash（“apple”）

如何实现一个尽量均匀分布的Hash函数呢？我们通过利用Key的HashCode值来做某种运算。

如何进行位运算呢？
有如下的公式（Length是HashMap的长度）：

index =  HashCode（Key） &  （Length - 1）

下面我们以值为“book”的Key来演示整个过程：

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

可以说，Hash算法最终得到的index结果，完全取决于Key的Hashcode值的最后几位。

也就是说，当HashMap长度为10的时候，有些index结果的出现几率会更大，而有些index结果永远不会出现（比如0111）！

这样，显然不符合Hash算法均匀分布的原则。反观长度16或者其他2的幂，Length-1的值是所有二进制位全为1，这种情况下，index的结果等同于HashCode后几位的值。只要输入的HashCode本身分布均匀，Hash算法的结果就是均匀的。

高并发下的HashMap

HashMap的容量是有限的。当经过多次元素插入，使得HashMap达到一定饱和度时，Key映射位置发生冲突的几率会逐渐提高。

这时候，HashMap需要扩展它的长度，也就是进行Resize。

影响发生Resize的因素有两个：

1. CapacityHashMap的当前长度。上一期曾经说过，HashMap的长度是2的幂。2
2. LoadFactorHashMap负载因子，默认值为0.75f。

衡量HashMap是否进行Resize的条件如下：HashMap.Size >= Capacity * LoadFactor

1. 扩容创建一个新的Entry空数组，长度是原数组的2倍。
2. ReHash遍历原Entry数组，把所有的Entry重新Hash到新数组。

为什么要重新Hash呢？
因为长度扩大以后，Hash的规则也随之改变。
让我们回顾一下Hash公式：

index = HashCode（Key） & （Length - 1）

当原数组长度为8时，Hash运算是和111B做与运算；
新数组长度为16，Hash运算是和1111B做与运算。Hash结果显然不同。

Resize前的HashMap

Resize后的HashMap

死锁

多线程下多个线程同时进行rehash操作可能会导致链表中出现环，从而导致程序进入死循环。这就是多线程下HashMap不是线程安全的原因。

杜绝死锁的方法

总结

1.Hashmap在插入元素过多的时候需要进行Resize，Resize的条件是HashMap.Size >= Capacity * LoadFactor。
2.Hashmap的Resize包含扩容和ReHash两个步骤，ReHash在并发的情况下可能会形成链表环。

HashMap 1.7 与1.8的区别

众所周知 HashMap 底层是基于 数组 + 链表 组成的，不过在 jdk1.7 和 1.8 中具体实现稍有不同。
1.7中的实现

1.7中一个很明显的缺点就是：

当 Hash 冲突严重时，在桶上形成的链表会变的越来越长，这样在查询时的效率就会越来越低；时间复杂度为 O(N)。

因此 1.8 中重点优化了这个查询效率。

从这两个核心方法（get/put）可以看出 1.8 中对大链表做了优化，修改为红黑树之后查询效率直接提高到了 O(logn)。

但是 HashMap 原有的问题也都存在，比如在并发场景下使用时容易出现死循环。

看过上文的还记得在 HashMap 扩容的时候会调用 resize() 方法，就是这里的并发操作容易在一个桶上形成环形链表；这样当获取一个不存在的 key 时，计算出的 index 正好是环形链表的下标就会出现死循环。

遍历方式

还有一个值得注意的是 HashMap 的遍历方式，通常有以下几种：

Iterator<Map.Entry<String, Integer>> entryIterator = map.entrySet().iterator();
        while (entryIterator.hasNext()) {
            Map.Entry<String, Integer> next = entryIterator.next();
            System.out.println("key=" + next.getKey() + " value=" + next.getValue());
        }
        
Iterator<String> iterator = map.keySet().iterator();
        while (iterator.hasNext()){
            String key = iterator.next();
            System.out.println("key=" + key + " value=" + map.get(key));
        }

复制代码强烈建议使用第一种 EntrySet 进行遍历。
第一种可以把 key value 同时取出，第二种还得需要通过 key 取一次 value，效率较低。