hashMap1.8做了哪些优化？

一、数据结构

        最大的变化就是，数据结构做了优化。在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，这时元素需要移动到扩容产生的桶中。