JAVA 集合源码解读之HashMap

最新推荐文章于 2022-06-04 21:28:16 发布

破晓-我思故我在

最新推荐文章于 2022-06-04 21:28:16 发布

阅读量170

点赞数

文章标签： JAVA 集合 HashMap

jdk 1.8以后 HashMap 的变化

原文链接：https://www.cnblogs.com/xiaoxi/p/7233201.html
在JDK1.8之前，HashMap采用数组+链表实现，即使用链表处理冲突，同一hash值的节点都存储在一个链表里。但是当位于一个桶中的元素较多，即hash值相等的元素较多时，通过key值依次查找的效率较低。而JDK1.8中，HashMap采用数组+链表+红黑树实现，当链表长度超过阈值（8）时，将链表转换为红黑树，这样大大减少了查找时间。

下图中代表jdk1.8之前的hashmap结构，左边部分即代表哈希表，也称为哈希数组，数组的每个元素都是一个单链表的头节点，链表是用来解决冲突的，如果不同的key映射到了数组的同一位置处，就将其放入单链表中。

jdk1.8之前的hashmap都采用上图的结构，都是基于一个数组和多个单链表，hash值冲突的时候，就将对应节点以链表的形式存储。如果在一个链表中查找其中一个节点时，将会花费O（n）的查找时间，会有很大的性能损失。到了jdk1.8，当同一个hash值的节点数不小于8时，不再采用单链表形式存储，而是采用红黑树，如下图所示。

重要方法分析：
（1）putVal方法：
首先说明，HashMap并没有直接提供putVal接口给用户调用，而是提供的put方法，而put方法就是通过putVal来插入元素的。

（2）getNode方法
说明：HashMap同样并没有直接提供getNode接口给用户调用，而是提供的get方法，而get方法就是通过getNode来取得元素的。

final Node<K,V> getNode(int hash, Object key) {
    Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
    // table已经初始化，长度大于0，根据hash寻找table中的项也不为空
    if ((tab = table) != null && (n = tab.length) > 0 &&
        (first = tab[(n - 1) & hash]) != null) {
        // 桶中第一项(数组元素)相等
        if (first.hash == hash && // always check first node
            ((k = first.key) == key || (key != null && key.equals(k))))
            return first;
        // 桶中不止一个结点
        if ((e = first.next) != null) {
            // 为红黑树结点
            if (first instanceof TreeNode)
                // 在红黑树中查找
                return ((TreeNode<K,V>)first).getTreeNode(hash, key);
            // 否则，在链表中查找
            do {
                if (e.hash == hash &&
                    ((k = e.key) == key || (key != null && key.equals(k))))
                    return e;
            } while ((e = e.next) != null);
        }
    }
    return null;
}

（3）resize方法 (来源：https://blog.youkuaiyun.com/v123411739/article/details/78996181)

在jdk1.8中，resize方法是在hashmap中的键值对大于阀值时或者初始化时，就调用resize方法进行扩容；
每次扩展的时候，都是扩展2倍；
如果e的hash值与老表的容量（为一串只有1个为2的二进制数，例如16为0000 0000 0001 0000）进行位与运算为0，则说明e节点扩容后的索引位置跟老表的索引位置一样（见例子1），进行链表拼接操作：如果loTail为空，代表该节点为第一个节点，则将loHead赋值为该节点；否则将节点添加在loTail后面，并将loTail赋值为新增的节点。
如果e的hash值与老表的容量（为一串只有1个为2的二进制数，例如16为0000 0000 0001 0000）进行位与运算为1，则说明e节点扩容后的索引位置为：老表的索引位置＋oldCap（见例子1），进行链表拼接操作：如果hiTail为空，代表该节点为第一个节点，则将hiHead赋值为该节点；否则将节点添加在hiTail后面，并将hiTail赋值为新增的节点。

final Node<K,V>[] resize() {
    Node<K,V>[] oldTab = table;
    int oldCap = (oldTab == null) ? 0 : oldTab.length;
    int oldThr = threshold;
    int newCap, newThr = 0;
    if (oldCap > 0) {   // 老table不为空
        if (oldCap >= MAXIMUM_CAPACITY) {      // 老table的容量超过最大容量值
            threshold = Integer.MAX_VALUE;  // 设置阈值为Integer.MAX_VALUE
            return oldTab;
        }
        // 将新容量赋值为老容量*2，如果新容量<最大容量并且老容量>=16, 则将新阈值设置为原来的两倍
        else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                 oldCap >= DEFAULT_INITIAL_CAPACITY)   
            newThr = oldThr << 1; // double threshold
    }
    else if (oldThr > 0) // 老表的容量为0, 老表的阈值大于0, 是因为初始容量被放入阈值
        newCap = oldThr;	// 则将新表的容量设置为老表的阈值 
    else {	// 老表的容量为0, 老表的阈值为0, 则为空表，设置默认容量和阈值
        newCap = DEFAULT_INITIAL_CAPACITY; 
        newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
    }
    if (newThr == 0) {  // 如果新阈值为空, 则通过新的容量*负载因子获得新阈值
        float ft = (float)newCap * loadFactor;
        newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                  (int)ft : Integer.MAX_VALUE);
    }
    threshold = newThr; // 将当前阈值赋值为刚计算出来的新的阈值
    @SuppressWarnings({"rawtypes","unchecked"})
    // 定义新表,容量为刚计算出来的新容量
    Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
    table = newTab; // 将当前的表赋值为新定义的表
    if (oldTab != null) {   // 如果老表不为空, 则需遍历将节点赋值给新表
        for (int j = 0; j < oldCap; ++j) {
            Node<K,V> e;
            if ((e = oldTab[j]) != null) {  // 将索引值为j的老表头节点赋值给e
                oldTab[j] = null; // 将老表的节点设置为空, 以便垃圾收集器回收空间
                // 如果e.next为空, 则代表老表的该位置只有1个节点, 
                // 通过hash值计算新表的索引位置, 直接将该节点放在该位置
                if (e.next == null) 
                    newTab[e.hash & (newCap - 1)] = e;
                else if (e instanceof TreeNode)
                	 // 调用treeNode的hash分布(跟下面最后一个else的内容几乎相同)
                    ((TreeNode<K,V>)e).split(this, newTab, j, oldCap); 
                else { // preserve order
                    Node<K,V> loHead = null, loTail = null; // 存储跟原索引位置相同的节点
                    Node<K,V> hiHead = null, hiTail = null; // 存储索引位置为:原索引+oldCap的节点
                    Node<K,V> next;
                    do {
                        next = e.next;
                        //如果e的hash值与老表的容量进行与运算为0,则扩容后的索引位置跟老表的索引位置一样
                        if ((e.hash & oldCap) == 0) {   
                            if (loTail == null) // 如果loTail为空, 代表该节点为第一个节点
                                loHead = e; // 则将loHead赋值为第一个节点
                            else    
                                loTail.next = e;    // 否则将节点添加在loTail后面
                            loTail = e; // 并将loTail赋值为新增的节点
                        }
                        //如果e的hash值与老表的容量进行与运算为1,则扩容后的索引位置为:老表的索引位置＋oldCap
                        else {  
                            if (hiTail == null) // 如果hiTail为空, 代表该节点为第一个节点
                                hiHead = e; // 则将hiHead赋值为第一个节点
                            else
                                hiTail.next = e;    // 否则将节点添加在hiTail后面
                            hiTail = e; // 并将hiTail赋值为新增的节点
                        }
                    } while ((e = next) != null);
                    if (loTail != null) {
                        loTail.next = null; // 最后一个节点的next设为空
                        newTab[j] = loHead; // 将原索引位置的节点设置为对应的头结点
                    }
                    if (hiTail != null) {
                        hiTail.next = null; // 最后一个节点的next设为空
                        newTab[j + oldCap] = hiHead; // 将索引位置为原索引+oldCap的节点设置为对应的头结点
                    }
                }
            }
        }
    }
    return newTab;
}

为什么链表元素个数大于等于8转换成红黑树，小于等于6转换成链表

原文链接：http://m.nowcoder.com/discuss/69681
在JDK1.8以前版本中，HashMap的实现是数组+链表，它的缺点是即使哈希函数选择的再好，也很难达到元素百分百均匀分布，而且当HashMap中有大量元素都存到同一个桶中时，这个桶会有一个很长的链表，此时遍历的时间复杂度就是O(n)，当然这是最糟糕的情况。

在JDK1.8及以后的版本中引入了红黑树结构，HashMap的实现就变成了数组+链表或数组+红黑树。添加元素时，若桶中链表个数超过8，链表会转换成红黑树；删除元素、扩容时，若桶中结构为红黑树并且树中元素个数较少时会进行修剪或直接还原成链表结构，以提高后续操作性能；遍历、查找时，由于使用红黑树结构，红黑树遍历的时间复杂度为 O(logn)，所以性能得到提升。

HashMap在JDK1.8及以后的版本中引入了红黑树结构，若桶中链表元素个数大于等于8时，链表转换成树结构；若桶中链表元素个数小于等于6时，树结构还原成链表。因为红黑树的平均查找长度是log(n)，长度为8的时候，平均查找长度为3，如果继续使用链表，平均查找长度为8/2=4，这才有转换为树的必要。链表长度如果是小于等于6，6/2=3，虽然速度也很快的，但是转化为树结构和生成树的时间并不会太短。

还有选择6和8，中间有个差值7可以有效防止链表和树频繁转换。假设一下，如果设计成链表个数超过8则链表转换成树结构，链表个数小于8则树结构转换成链表，如果一个HashMap不停的插入、删除元素，链表个数在8左右徘徊，就会频繁的发生树转链表、链表转树，效率会很低。

HashMap的扩容机制(为什么每次扩展或者手动初始化长度必须是2的幂)

原文链接：https://segmentfault.com/a/1190000017509668
hashmap是数组链表结构：hash算法用于将key散列，经计算分散到数组槽中；而两个key算出了同样的值，即产生hash冲突时，就需要将槽中的单个节点升级成链表。由于get时需要对链表其进行遍历，链表越长检索效率越差。那么，计算出的key值落点越平均，hash冲突的可能性越小。

key值落点的计算方式为，key的hash值与数组长度作取余操作，记作key.hascode % array.length。从数学角度考虑，保持array.length为质数会使得计算结果更均衡，hashTable就是这么做的（数组初始值11）。但 hashmap 中 array.length 偏偏选择了2的次幂，是个合数……何故？完全出于性能考虑！

先给出结论——当 array.ength长度是2的次幂时key.hashcode % array.length等于key.hashcode & (array.length - 1)。下面重点看下这个结论是怎么得出来的。

举个例子：
假如 array.length = 2^4 = 16，二进制10000。这个数减去1的结果是1111，也就是array.length -1 = 1111。
（下面这段中的数字都是二进制）
再假设一个key的值为10011011001（很随意写的一个数），与1111做 & 操作，得到的结果是1001（高位部分1001101都舍去了）。而1001必然是一个小于10000的数，对于一个小于10000的数而言，1001 % 10000得到的就是1001自己。
那么刚刚舍弃的高位部分1001101 0000（后面补上了四个0000）就一定能被10000整除吗？答案是肯定的：因为10011010000可以拆成10000000000+10000000+1000000+10000，这几个数都能通过10000的n次左移得到，也就相当于这几个数都能被10000整除。那他们的和，也就是10011010000，一定也可以被10000整除。
因此，最终结论就是：10011011001 & ( 10000 - 1 ) = 10011011001 & 1111 = 1001 = 10011011001 % 10000

放张简图再唠叨一遍以示总结，加深下印象：

再强调一次：当 array.ength长度是2的次幂时，key.hashcode % array.length等于key.hashcode & (array.length - 1)
好，如果你读懂了例子部分，相信你已经基本明白这个结论是站得住脚的（虽然不是纯数学型的讲解）。那么hashmap的作者Doug Lea大神，为什么如此执着于用&操作替换%操作呢？
因为对于二进制生物计算机来说，& 的效率要高于 %！（与、或、非都可看作二进制基本操作，同或、异或次之，+ - * ÷ % 等都基于前面的）

扩容时方便定位

这还不算完，好处不止这一处。
当hashmap需要扩容，重新计算链表元素的hashcode，以进行元素的重新定位时，依然能从“ 数组2次幂 ”的这个设定中借力！

hashmap数组扩容时，新数组length = 原数组length * 2，沿用前面的例子（array.length = 2^4 = 16，二进制10000），array.length 乘以 2 ,即二进制左移一位，由 10000 变成 100000。此时需要重新计算数组槽中的元素位置，如果槽中是链表，链表中每个元素都需要重新计算位置（这里不考虑红黑树）。

计算的公式不变，key.hashcode & (array.length - 1)，由于数组的翻倍（10000->100000），导致 array.length - 1 发生了改变（1111->11111）。此时，扩容前原本被舍弃的高位部分的最后1位，也将参与计算。

在扩容这个历史的拐点，这一位就显得很特别：如果这个位置是0，余数计算的结果将保持不变，意味着扩容后此元素还在这个槽中（槽编号没发生改变）；如果这个位置是1，余数计算结果就变成了原槽索引 + 原array.length。
也就是说，hashmap扩容的元素迁移过程中，由于数组大小是2次幂的巧妙设定，使得只要检查 “ 特殊位 ” 就能确定该元素的最终定位。
给出一个较完整的扩容示意图进行说明：

扩容前

红绿黄三个元素，由各自的hashcode取余后都淤积在数组槽13，组成链表形式

扩容后

红、绿二星所表示的元素的hashcode“ 特殊位 ”为0，取余依然定位在槽13；而黄星表示的元素，hashcode“ 特殊位 ”为1，取余后结果 = 原槽索引 + 原数组大小 = 13 + 16 = 29。（这个结果也和图中黄星的hashcode二进制低位值11101一致）

总结：
对hashmap而言，数组长度始终保持2次幂有两点好处：

能利用 & 操作代替 % 操作，提升性能
数组扩容时，仅仅关注 “特殊位” 就可以重新定位元素

性能，性能，还是性能……

高并发情况下，为什么HashMap可能会出现死锁

HashMap的容量是有限的。当经过多次元素插入，使得HashMap达到一定饱和度时，Key映射位置发生冲突的几率会逐渐提高。这时候，HashMap需要扩展它的长度，也就是进行Resize。

影响发生Resize的因素有两个：
1.Capacity
HashMap的当前长度。上一期曾经说过，HashMap的长度是2的幂。
2.LoadFactor
HashMap负载因子，默认值为0.75f。
衡量HashMap是否进行Resize的条件如下：HashMap.Size >= Capacity * LoadFactor

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

扩容
创建一个新的Entry空数组，长度是原数组的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的Rehash操作可能会带来链表循环
假设一个HashMap已经到了Resize的临界点。此时有两个线程A和B，在同一时刻对HashMap进行Put操作：

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

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

假如此时线程B遍历到Entry3对象，刚执行完红框里的这行代码，线程就被挂起。对于线程B来说：
e = Entry3
next = Entry2
这时候线程A畅通无阻地进行着Rehash，当ReHash完成后，结果如下（图中的e和next，代表线程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
整体情况如图所示：

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

e = Entry2
next = Entry3
整体情况如图所示：

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

整体情况如图所示：

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

e = Entry3
next = Entry3.next = null
最后一步，当我们执行下面这一行的时候，见证奇迹的时刻来临了：

newTable[i] = Entry2
e = Entry3
Entry2.next = Entry3
Entry3.next = Entry2
链表出现了环形！
整体情况如图所示：

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

总结：

Hashmap在插入元素过多的时候需要进行Resize，Resize的条件是HashMap.Size >= Capacity * LoadFactor。
Hashmap的Resize包含扩容和ReHash两个步骤，ReHash在并发的情况下可能会形成链表环。
死循环发生在两个线程同时对hashmap进行put操作，此时map达到resize条件要进行扩容，B在执行的时候被挂起，A线程畅通无阻地进行着Rehash，紧接着B继续执行，造成链表出现了环形
死循环的根本原因是：扩容后同一索引位置的节点顺序会反掉
哈希冲突的解决方法有多种：开放地址法(发生冲突继续寻找下一块未被占用的存储地址)，再散列法，链地址法，HashMap即采用了链地址法