美文网首页
jdk1.6及1.8 HashMap线程安全分析

jdk1.6及1.8 HashMap线程安全分析

作者: luckiexie | 来源:发表于2019-03-31 14:35 被阅读0次

    前言

        HashMap在java程序中使用颇为频繁,因此掌握HashMap的底层实现显得格外重要。相信大家也知道HashMap是非线程安全的,在多线程环境下应该避免使用HashMap,而应该使用线程安全的ConcurrentHashMap。那么HashMap在多线程环境下到底有什么问题,为什么存在这样的问题,以及jdk1.6及1.8以上实现的差异在哪?本文围绕这几个问题展开,逐一解答所有疑问。

    HashMap底层数据结构及问题分析

    jdk1.6

        jdk1.6的HashMap底层数据结构相当简单,也是大家比较熟悉的数据结构---数组+单向链表。jdk1.6通过数组和链表的组合以拉链法的方式实现HashMap。结构如下图所示:


    拉链法哈希表

        key位置确定方式为pos=hashcode(key) % len,所有冲突的key通过单链表串起来。当HashMap的元素个数超过某个负载值(由负载因素决定)时,会进行扩容,并将所有元素rehash后放置在扩容后的哈希表中,jdk1.6的扩容逻辑如下:

    void transfer(Entry[] newTable) {
            Entry[] src = table;
            int newCapacity = newTable.length;
            for (int j = 0; j < src.length; j++) {
                Entry<K,V> e = src[j];
                if (e != null) {
                    src[j] = null;
                    do {
                        Entry<K,V> next = e.next;
                        int i = indexFor(e.hash, newCapacity);
                        e.next = newTable[i];
                        newTable[i] = e;
                        e = next;
                    } while (e != null);
                }
            }
        }
    

    这段代码逻辑不难,这里简单解读下上述代码做的事情:遍历旧哈希表中所有单链表,找到元素e在新哈希表的位置,然后将其插入到该位置对应链表的头部。循环完后,所有的元素都搬到新哈希表中。由此可以看出,这里采用的是头插入法,这样每次插入时不用遍历链表,提高了性能。但是这里存在一个潜在的风险:在多线程环境下,容易出现循环引用导致死循环。下面具体分析下这种场景。
        假设有两个线程A、B同时对同一个HashMap进行插值操作,并且HashMap容量已到达阈值需要扩容。这时,便会出现并发扩容的情况。假设线程A先执行到Entry<K,V> next = e.next;此时A线程对应哈希表的状态如下:


    哈希表状态-A

    接着,操作系统将A线程挂起,B线程被调度执行,并执行完do while循环中的所有指令,此时B线程对应哈希表状态为:

    哈希表状态-B
    我们可以看到,B执行完一把while循环后,12和20的指向恰好反过来了,这正是头插入法的效果。现在20的下一个元素是12。这时,如果线程A再次被调度执行,那么意外就出现了,因为此时在A线程看来e指向的是12,此时执行e.next = newTable[i];那么其实就是将12的下一个元素再次指向了20,此时的转态如下:
    死循环状态
    从上图可以看出,12的next引用20,20的next引用12,导致死循环。

    jdk1.8

        上一小节我们分析了jdk1.6的HashMap在并发扩容时会导致死循环,本小节我们来看看jdk1.8中HashMap的扩容时如何实现的。和jdk1.6中的HashMap类似,底层数据结构也是采用拉链法实现的hash表,不同的是当链表的元素个数达到8时,链表会转换为红黑树以提高查询的性能。本文的重点是分析扩容问题,因此对于红黑树暂且不讨论(网上一搜一大把)。jdk1.8扩容的逻辑如下:

        final Node<K,V>[] resize() {
            Node<K,V>[] 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<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
            table = newTab;
            if (oldTab != null) {
                for (int j = 0; j < oldCap; ++j) {
                    Node<K,V> 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<K,V>)e).split(this, newTab, j, oldCap);
                        else { // preserve order
                            Node<K,V> loHead = null, loTail = null;
                            Node<K,V> hiHead = null, hiTail = null;
                            Node<K,V> 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;
        }
    

    代码有点长,我们只关心主要扩容执行部分--for循环里。jdk1.8这块的实现逻辑比1.6绕,很多同学一开始很难理清楚,这里简单解释下:和1.6一样也是遍历原始hash表中所有链表,不同的是,在1.8中不是每遍历一个元素就往新hash表中插,而是提前将一个链表中的元素分别组织成低槽位和高槽位的链表,然后再分别将两个链表插入到新hash表中对应的位置。这里比较难理解的是一个单链表为何能拆成两个不同的链表,且保证链表中的元素确实在同一槽位?这里做个论证,假设有个长度为len的hash表,那么第i槽位对应的key的hash值只可能为i、len+i、2*len+i、... 、n*len+i。由于HashMap扩容是翻倍的,即扩容到原来的2倍,因此扩容后的长度为2*len,那之前旧表中第i槽位的元素rehash后在新表中的槽位为:i%2len、(len+i)%2len、(2*len+i)%2len、... 、(n*len+i)%2n,很明显(k*len+i)%2len(k为偶数)的值为i,(k*len+i)%2len(k为奇数)的值为i+len,所以rehash后旧表中第i槽位的key会落在新表第i或者第i+len槽位,这就解释了为什么旧表中一个链表会拆分为两个链表。还是以上面的HashMap为例1.8扩容后的结果如下:

    扩容后的哈希表-1.8
    可以看出,扩容后12和20依然在同一槽位,而且顺序也没变,由于不像1.6使用头插入法, 因此在多线程场景下不会出现死循环。那是不是1.8的HashMap就线程安全了呢?答案是否定的,do while循环进行链表拼接时,由于不是原子操作,会导致拼接覆盖的情况,导致数据丢失。

    小结

        本文主要介绍了HashMap在多线程环境下导致的问题及其原因,欢迎大家沟通交流。

    相关文章

      网友评论

          本文标题:jdk1.6及1.8 HashMap线程安全分析

          本文链接:https://www.haomeiwen.com/subject/wuhsbqtx.html