HashMap图文源码解析

目录

• Put方法的原理
• Get方法的原理
• 高并发下的HashMap（jdk8以下版本）
• 问题
  • HashMap的初始长度？
  • 为什么长度必须是16或是2的幂？比如HashMap的长度是10会是怎么样的？
  • Hashmap为什么线程不安全？
  • Hashmap中的key可以为任意对象或数据类型吗？
• 占位符

---

　　HashMap是一个看似简单实而复杂的类，也是在面试中很容易问道的问题，哈哈哈，不怕。。。

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

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

　　

　　对于HashMap，我们最常使用的是两个方法：Get 和 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节点插入链表时，使用的是“头插法”。至于为什么不插入链表尾部，后面会有解释。

Get方法的原理

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

　　首先会把输入的Key做一次Hash映射，得到对应的index：

　　　　index =  Hash（“apple”）

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

　　待查找Key:

　　

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

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

　　之所以把Entry6放在头节点，是因为HashMap的发明者认为，后插入的Entry被查找的可能性更大。

高并发下的HashMap（jdk8以下版本）

　　在分析高并发场景之前，需要搞清楚【ReHash】

　　ReHash是HashMap在扩容时候的一个步骤

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

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

　　

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

　　1.Capacity

　　HashMap的当前长度。上一期曾经说过，HashMap的长度是2的幂。

　　2.LoadFactor

　　HashMap负载因子，默认值为0.75f。

　　衡量HashMap是否进行Resize的条件如下:

　　　　HashMap.Size   >=  Capacity * LoadFactor

　　HashMap的Resize不是简单地把长度扩大，而是经过下面两步：

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的Java代码如下：

/**
 * Transfers all entries from current table to newTable.
 */
void transfer(Entry[] newTable, boolean rehash) {
    int newCapacity = newTable.length;
    for (Entry<K,V> e : table) {
        while(null != e) {
            Entry<K,V> next = e.next;
            if (rehash) {
                e.hash = null == e.key ? 0 : hash(e.key);
            }
            int i = indexFor(e.hash, newCapacity);
            e.next = newTable[i];
            newTable[i] = e;
            e = next;
        }
    }
}

　　上述流程在单线程下执行并没有问题，可惜HashMap并非线程安全

 　　在多线环境中：（比较烧脑）

　　假设一个HashMap已经到了Resize的临界点。此时有两个线程A和B，在同一时刻对HashMap进行Put操作：

　　

　　

　　此时达到Resize条件，两个线程各自进行Rezie的第一步，也就是扩容：

　　线程A：

　　

　　线程B：

　　

　　原数组：

　　

　　这时候，两个线程都走到了ReHash的步骤。让我们回顾一下ReHash的代码

 　　

　　假如此时线程B遍历到Entry3对象，刚执行完红框里的这行代码，线程就被挂起。对于线程B来说：

　　　　e = Entry3

　　　　next = Entry2

　　这时候线程A畅通无阻地进行着Rehash，当ReHash完成后，结果如下（图中的e和next，代表线程B的两个引用）：

　　线程A：

　　

　　线程B：

　　

　　原数组：

　　

　　直到这一步，看起来没什么毛病。接下来线程B恢复，继续执行属于它自己的ReHash。线程B刚才的状态是：

　　e = Entry3

　　next = Entry2

　　

　　当执行到上面这一行时，显然 i = 3，因为刚才线程A对于Entry3的hash结果也是3。

 　　

我们继续执行到这两行，Entry3放入了线程B的数组下标为3的位置，并且e指向了Entry2。此时e和next的指向如下：

　　e = Entry2

　　next = Entry2

整体情况如图所示：

线程A：

线程B：

　　原数组：

　　

　　接着是新一轮循环，又执行到红框内的代码行：

　　

　　e = Entry2

　　next = Entry3

 　　整体情况如图所示：

　　线程A：

　　

　　线程B：

　　

　　原数组：

　　

　　接下来执行下面的三行，用头插法把Entry2插入到了线程B的数组的头结点：

 　　

　　整体情况如图所示：

　　线程A：

　　

　　线程B：

　　

　　原数组：

 　　

　　第三次循环开始，又执行到红框的代码：

 　　

　　e = Entry3

　　next = Entry3.next = null

　　最后一步，当我们执行下面这一行的时候，见证奇迹的时刻来临了

 　　

　　newTable[i] = Entry2

　　e = Entry3

　　Entry2.next = Entry3

　　Entry3.next = Entry2

链表出现了环形！

整体情况如图所示：

 　　线程A：

　　

　　线程B：

　　

　　原数组：

 　　

此时，问题还没有直接产生。当调用Get查找一个不存在的Key，而这个Key的Hash结果恰好等于3的时候，由于位置3带有环形链表，所以程序将会进入死循环！

这种情况，不禁让人联想到一道经典的面试题：

　　漫画算法：如何判断链表有环？

 　　在高并发场景下，我们通常采用另一个集合类ConcurrentHashMap，这个集合类兼顾了线程安全和性能

总结

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

问题

HashMap的初始长度？

　　HashMap的默认初始长度是16，并且每次自动扩展或是手动初始化时长度必须是2的幂

　　为什么是16？——>>是为了服务从key映射到index的Hash算法

　　之前说过，从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值的最后几位。

为什么长度必须是16或是2的幂？比如HashMap的长度是10会是怎么样的？

　　这样做不但效果上等同于取模，而且还大大提高了性能

　　假设HashMap的长度为10，重复刚才的运算步骤：

　　　　

　　单独看这个结果，表面上并没有问题。我们再来尝试一个新的HashCode  101110001110101110 1011 ：

 　　　　

　　让我们再换一个HashCode 101110001110101110 1111 试试  ：

 　　　　

　　是的，虽然HashCode的倒数第二第三位从0变成了1，但是运算的结果都是1001。也就是说，当HashMap长度为10的时候，有些index结果的出现几率会更大，而有些index结果永远不会出现（比如0111）

　　这样，显然不符合Hash算法均匀分布的原则。

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

总结：

1. 提高运算速度
2. 增加散列度，降低冲突
3. 减少内存碎片

　　Jdk1.8改进了HashMap，如果链表长度超过8，单链表自动转换红黑树以提高搜索效率和查询速度

• 漫画：什么是红黑树？

Hashmap为什么线程不安全？（hash碰撞和扩容导致）

　　在并发插入元素时，HashMap扩容的时候可能会形成环形链表，让下一次读操作出现死循环。

　　非线程安全：

　　　　任一时刻可以由多个线程同时写HashMap，可能导致数据不一致

　　线程安全：

1. 用Collections的SynchronizedMap()说的HashMap线程安全
2. 使用ConcurrentHashMap　　

Hashmap中的key可以为任意对象或数据类型吗？

　　可以为null，但是不能为可变对象，如果是可变对象，对象中的属性改变，那么Hash也要进行相应的改变，导致下次五大找到已存在的Map中的数据

本文转发整合：

• 漫画：什么是HashMap？

• 漫画：高并发下的HashMap