JDK1.8中HashMap的底层实现

1.HashMap底层数据结构

jdk1.7:  数组 + 链表

jdk1.8: 数组 + 链表 + 红黑树 

根据源码可知: 数组默认初始长度为16

链表转为红黑树条件: 数组长度64,链表长度为8

红黑树退化为链表: 当链表长度为6(避免因在8附近导致链表/红黑树频繁转化) 

2.头插法与尾插法

在向hashMap中存数据的过程中,底层实际是将数据存到数组上,经过如下步骤计算: 

如图: 先拿到key的hashcode(共32位),将前16位与后16位进行异或(^)运算,得到hash值

 再用数组长度-1 和hash 做 位与(&)运算,得到最终数组下标,然后存入.hash函数,也叫扰动函数.

减少数据存放发生hash冲突的概率.

 当发生hash冲突时,会生成单向链表.插入方式有头插法和尾插法.

jdk1.7用的是头插法,会存在链表发生反转,多线程环境下可能产生死循环(环形链表)

jdk1.8改良为尾插法,解决了链表反转和多线程环境死循环问题,但存在多线程环境数据覆盖问题

3.底层扩容相关机制

初始数组长度为16,加载因子为0.75(减少hash冲突)

扩容为原先长度*2,数组长度上线为2的30次幂(位运算是1<<30)

1.8的条件是> 数组长度* 加载因子 

 如果数组进行扩容，数组长度发生变化，而存储位置 index = h&(length-1)，index也可能会发生变化，需要重新计算index。

HashMap的数组长度一定保持2的次幂，比如16的二进制表示为 10000，那么length-1就是15，二进制为01111，同理扩容后的数组长度为32，二进制表示为100000，length-1为31，二进制表示为011111。从下图可以我们也能看到这样会保证低位全为1，而扩容后只有一位差异，也就是多出了最左位的1，这样在通过 h&(length-1)的时候，只要h对应的最左边的那一个差异位为0，就能保证得到的新的数组索引和老数组索引一致(大大减少了之前已经散列良好的老数组的数据位置重新调换)，这也是为啥数组长度必须是2的幂次原因之一。

另外，数组长度必须是2的幂次的另一原因就是能保证数据分布的均匀性。

JDK1.8中将transfer()方法的操作也放入了resize()方法中，而由于JDK1.8引入了红黑树的结构，扩容的操作看起来也更加复杂。 

 
 /**
     * Initializes or doubles table size.  If null, allocates in
     * accord with initial capacity target held in field threshold.
     * Otherwise, because we are using power-of-two expansion, the
     * elements from each bin must either stay at same index, or move
     * with a power of two offset in the new table.
     *
     * @return the table
     */
    final Node[] resize() {
        Node[] oldTab = table;
        int oldCap = (oldTab == null) ? 0 : oldTab.length;
        int oldThr = threshold;
        int newCap, newThr = 0;
        if (oldCap > 0) {
            if (oldCap >= MAXIMUM_CAPACITY) {
                threshold = Integer.MAX_VALUE;
                return oldTab;
            }
            else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                     oldCap >= DEFAULT_INITIAL_CAPACITY)
                newThr = oldThr << 1; // double threshold
        }
        else if (oldThr > 0) // initial capacity was placed in threshold
            newCap = oldThr;
        else {               // zero initial threshold signifies using defaults
            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[] newTab = (Node[])new Node[newCap];
        table = newTab;
        if (oldTab != null) {
            // 数据转移操作
            for (int j = 0; j < oldCap; ++j) {
                Node e;
                if ((e = oldTab[j]) != null) {
                    oldTab[j] = null;
                    // 元素没有后续节点，直接放入新数组对应索引位置
                    if (e.next == null)
                        newTab[e.hash & (newCap - 1)] = e;
                    // 元素是树节点，进行树转移操作（本文暂不考虑）
                    else if (e instanceof TreeNode)
                        ((TreeNode)e).split(this, newTab, j, oldCap);
                    else { // preserve order
                        // 不是树节点并且有后续节点那就只剩下链表形式了
                        Node loHead = null, loTail = null;
                        Node hiHead = null, hiTail = null;
                        Node next;
                        // 尾插法转移链表数据
                        do {
                            next = e.next;
                            // 索引不进行变化，放入新数组和原数组一样的位置
                            if ((e.hash & oldCap) == 0) {
                                if (loTail == null)
                                    // 直接放入
                                    loHead = e;
                                else
                                    // 尾插法
                                    loTail.next = e;
                                loTail = e;
                            }
                            else {
                                // 需要重新计算元素在新数组中的位置
                                if (hiTail == null)
                                    // 直接放入
                                    hiHead = e;
                                else
                                    // 尾插法
                                    hiTail.next = e;
                                hiTail = e;
                            }
                        } while ((e = next) != null);
                        if (loTail != null) {
                            loTail.next = null;
                            newTab[j] = loHead;
                        }
                        if (hiTail != null) {
                            // 重新计算的数组索引位置也就是原索引加上原数组长度
                            hiTail.next = null;
                            newTab[j + oldCap] = hiHead;
                        }
                    }
                }
            }
        }
        return newTab;
    }

4.concurrentHashMap

上面说到,jdk1.8虽然解决了链表反转和死循环问题,但是依然存在多线程环境数据覆盖的问题.

使用线程安全的 Hashtable 类代替，该类在对数据操作的时候都会上锁，也就是加上 synchronized

使用线程安全的 ConcurrentHashMap 类代替，该类在 JDK 1.7 和 JDK 1.8 的底层原理有所不同，JDK 1.7 采用数组 + 链表存储数据，使用分段锁 Segment 保证线程安全；JDK 1.8 采用数组 + 链表/红黑树存储数据，使用 CAS + synchronized 保证线程安全。

不过**前两者的线程并发度并不高，容易发生大规模阻塞，**所以一般使用的都是 ConcurrentHashMap，他的性能和效率明显高于前者。

ConcurrentHashMap1.7

 Java 7 中 ConcurrentHashMap 的存储结构如上图，ConcurrnetHashMap 由很多个 Segment 组合，而每一个 Segment 是一个类似于 HashMap 的结构，所以每一个 HashMap 的内部可以进行扩容。但是 Segment 的个数一旦初始化就不能改变，默认 Segment 的个数是 16 个，你也可以认为 ConcurrentHashMap 默认支持最多 16 个线程并发。

JDK1.8 ConcurrentHashMap在性能方面的优化

1. 在jdk1.8里面ConcurrentHashMap锁的粒度，是数组中的某一个节点，而在jdk1.7里面。它锁定的是Segment，锁的范围要更大，所以性能上它会更低。

2. 引入红黑树这样一个机制，去降低了数据查询的时间复杂度，红黑树的时间复杂度实是O(logn)

3. 底层数据结构：Synchronized + CAS +Node +红黑树.Node的val和next都用volatile保证,保证可见性,查找,替换,赋值操作都使用CAS

   为什么在有Synchronized 的情况下还要使用CAS?

   因为CAS是乐观锁,在一些场景中(并发不激烈的情况下)它比Synchronized和ReentrentLock的效率要高,当CAS保障不了线程安全的情况下(扩容或者hash冲突的情况下)转成Synchronized 来保证线程安全,大大提高了低并发下的性能.