一、数据结构
最大的变化就是,数据结构做了优化。在Java1.7中,HashMap的数据结构为数组+单向链表。Java1.8中变成了数组+单向链表+红黑树。
jdk1.7:
插入key-value时主要有两个步骤:
1.根据key的hash值,找到key-value要存放的桶(bucketIndex),也就是对应数组元素的下标。
2.当不同key发生哈希冲突时,key-value会以单向链表的形式存储,并使用头插法插入。
jdk1.8:
插入key-value时,增加了一个链表与红黑树之间转换的步骤 -> 当链表节点数量达到树化阀值TREEIFY_THRESHOLD(阀值>8,并且数组长度>64)时,链表就会转化为红黑树。
需要注意的是,当红黑树的节点数量减少到UNTREEIFY_THRESHOLD <=6时,红黑树又会转化为单向链表。
为什么?
1.链表的增删效率高,查询效率低。
2.红黑树的增删效率低,查询效率高。
3.当HashMap中存储的数据越来越多,链表越来越长,查询数据效率就不太理想。使用红黑树代替链表,虽然牺牲了部分增删的性能,却提升了查询的性能。
链表查询的时间复杂度为O(n),红黑树查询的时间复杂度为O(logn)。log8 = 3
二、链表插入节点的方式
在Java1.7中,插入链表节点使用头插法。Java1.8中变成了尾插法。
为什么?
头插法主要存在的问题是:并发下调用transfer()方法,可能会导致链表死循环,调用get()方法时会进入死循环,以及数据的丢失。
三、hash函数
Java1.8的hash()中,将hash值高位(前16位)参与到取模的运算中,使得计算结果的不确定性增强,降低发生哈希碰撞的概率。
四、扩容时计算数组元素下标的算法
为什么?
实际上,我们很容易发现规律:
原本在同一个桶中的key,在扩容后,HashMap容量翻倍,再去取模,实际上是需要高一位来参与计算的。(e.hash & oldCap) == 0就是进行了这样的计算。
当高位是0时,newBucketIndex = oldBucketIndex,此时元素还是存放在原来的桶中;
当高位是1时,newBucketIndex = oldBucketIndex + oldTable.length,这时元素需要移动到扩容产生的桶中。