HashMap 1.7 与 1.8 的 区别,说明 1.8 做了哪些优化,如何优化的?

Posted 四猿外

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HashMap 1.7 与 1.8 的 区别,说明 1.8 做了哪些优化,如何优化的?相关的知识,希望对你有一定的参考价值。

HashMap结构图
在这里插入图片描述
在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 左右

以上是关于HashMap 1.7 与 1.8 的 区别,说明 1.8 做了哪些优化,如何优化的?的主要内容,如果未能解决你的问题,请参考以下文章

ConcurrentHashMap 1.7和1.8区别

jdk源码hashMap的1.7与1.8的比较

面经五

1.7和1.8 HashMap 源码浅析

ConcurrentHashMap 结构 1.7 与1.8

JDK 1.8 中 HashMap 扩容骚操作的变化问题