HashMap 1.7 与 1.8 的区别（2）

我也不清楚

已于 2022-04-11 18:17:36 修改

阅读量224

点赞数

分类专栏： JAVA 文章标签： java

于 2022-04-11 18:13:20 首次发布

本文链接：https://blog.csdn.net/chenyang_wei/article/details/124105497

版权

JAVA 专栏收录该内容

13 篇文章 1 订阅

订阅专栏

HashMap 结构图

JDK1.7 HashMap结构为数组 + 链表（发生元素碰撞时，会将新元素添加到链表开头）；

JDK1.8 HashMap结构为数组 + 链表 + 红黑树（发生元素碰撞时，会将新元素添加到链表末尾，当

HashMap 总容量大于等于 64 ，并且某个链表的大小大于等于 8 ，会将链表转化为红黑树（注意：

红黑树是二叉树的一种））。

在 JDK1.7 及之前的版本中， HashMap 又叫散列链表：基于一个数组以及多个链表的实现， hash 值冲突的时候，

就将对应节点以链表的形式存储。

JDK1.8 中，当同一个 hash 值（ Table 上元素）的链表节点数不小于 8 时，将不再以单链表的形式存储了，会被调整成一颗红黑树。这就是 JDK7 与 JDK8 中 HashMap 实现的最大区别。

其下基于 JDK1.7.0_80 与 JDK1.8.0_66 做的分析

JDK1.7 中使用一个 Entry 数组来存储数据，用 key 的 hashcode 取模来决定 key 会被放到数组里的位置，如果 hashcode 相同，或者 hashcode 取模后的结果相同（ hash collision ），那么这些 key 会被定位到 Entry 数组的同一个格子里，这些 key 会形成一个链表。

在 hashcode 特别差的情况下，比方说所有 key 的 hashcode 都相同，这个链表可能会很长，那么 put/get 操作都可能需要遍历这个链表，也就是说时间复杂度在最差情况下会退化到 O(n)

JDK1.8 中

使用一个 Node 数组来存储数据，但这个 Node 可能是链表结构，也可能是红黑树结构如果插入的 key 的 hashcode 相同，那么这些 key 也会被定位到 Node 数组的同一个格子里。如果同一个格子里的key 不超过 8 个，使用链表结构存储。如果超过了8 个，那么会调用 treeifyBin 函数，将链表转换为红黑树。那么即使 hashcode 完全相同，由于红黑树的特点，查找某个特定元素，也只需要 O(log n) 的开销也就是说put/get 的操作的时间复杂度最差只有 O(log n) 听起来挺不错，但是真正想要利用 JDK1.8 的好处，有一个限制：key的对象，必须正确的实现了 Compare 接如果没有实现 Compare 接口，或者实现得不正确（比方说所有 Compare 方法都返回 0 ）那 JDK1.8 的 HashMap 其实还是慢于 JDK1.7 的

简单的测试数据如下：

向 HashMap 中 put/get 1w 条 hashcode 相同的对象

JDK1.7: put 0.26s ， get 0.55s

JDK1.8 （未实现 Compare 接口）： put 0.92s ， get 2.1s

但是如果正确的实现了 Compare 接口，那么 JDK1.8 中的 HashMap 的性能有巨大提升，这次 put/get 100W 条

hashcode 相同的对象

JDK1.8 （正确实现 Compare 接口，）： put/get 大概开销都在 320 ms 左右;

补充：

二、JDK8 HashMap重排序

如果删除了 HashMap 中红黑树的某个元素导致元素重排序时，不需要计算待重排序的元素的 HashCode 码，只需要将当前元素放到（HashMap 总长度 + 当前元素在 HashMap 中的位置）的位置即可。

三、HashMap 是线程安全的吗，为什么不是线程安全的

不是线程安全的；

如果有两个线程 A 和 B ，都进行插入数据，刚好这两条不同的数据经过哈希计算后得到的哈希码是一样的，且该位置还没有其他的数据。所以这两个线程都会进入我在上面标记为1 的代码中。假设一种情况，线程 A 通过 if 判断，该位置没有哈希冲突，进入了if 语句，还没有进行数据插入，这时候 CPU 就把资源让给了线程 B ，线程 A 停在了 if 语句里面，线程B 判断该位置没有哈希冲突（线程 A 的数据还没插入），也进入了 if 语句，线程 B 执行完后，轮到线程 A 执行，现在线程A 直接在该位置插入而不用再判断。这时候，你会发现线程 A 把线程 B 插入的数据给覆盖了。发生了线程不安全情况。本来在 HashMap 中，发生哈希冲突是可以用链表法或者红黑树来解决的，但是在多线程中，可能就直接给覆盖了。

上面所说的是一个图来解释可能更加直观。如下面所示，两个线程在同一个位置添加数据，后面添加的数据就覆盖住了前面添加的。

如果上述插入是插入到链表上，如两个线程都在遍历到最后一个节点，都要在最后添加一个数据，那么后面添加数据的线程就会把前面添加的数据给覆盖住。则在扩容的时候也可能会导致数据不一致，因为扩容是从一个数组拷贝到另外一个数组。

四、HashMap 的扩容过程

当向容器添加元素的时候，会判断当前容器的元素个数，如果大于等于阈值 ( 知道这个阈字怎么念吗？不念 fa 值，念 yu 值四声 )--- 即当前数组的长度乘以加载因子的值的时候，就要自动扩容啦。

扩容 ( resize ) 就是重新计算容量，向 HashMap 对象里不停的添加元素，而 HashMap 对象内部的数组无法装载更多的元素时，对象就需要扩大数组的长度，以便能装入更多的元素。当然 Java 里的数组是无法自动扩容的，方法是使用一个新的数组代替已有的容量小的数组，就像我们用一个小桶装水，如果想装更多的水，就得换大水桶。

cap =3 ， hashMap 的容量为 4 ；

cap =4 ， hashMap 的容量为 4 ；