JAVA源码分析-HashMap源码分析(二）

本文继续分析HashMap的源码。本文的重点是resize()方法和HashMap中其他的一些方法，希望各位提出宝贵的意见。

话不多说，咱们上源码。

final Node[] resize() {
        Node[] oldTab = table;
        
        //如果老的数组为空，老的数组容量设为0
        int oldCap = (oldTab == null) ? 0 : oldTab.length;
        int oldThr = threshold;
        int newCap, newThr = 0;
        
        //如果老的数组容量大于0，首先判断是否大于等于HashMap的最大容量，
        //如果true，将阈值设置为Integer的最大值，同时数组容量不变
        if (oldCap > 0) {
            if (oldCap >= MAXIMUM_CAPACITY) {
                threshold = Integer.MAX_VALUE;
                return oldTab;
            }
            
            //如果扩容后的数组容量小于我们规定的最大数组容量，而且老的数组容量大于等于16，
            //对数组进行扩容，扩容后的数组容量为原来的两倍；同时阈值也扩容为原来的两倍
            else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                     oldCap >= DEFAULT_INITIAL_CAPACITY)
                newThr = oldThr << 1; // double threshold
        }
        
        //如果老的数组容量为0，而且老的阈值大于0，则新的容量=老的阈值
        else if (oldThr > 0) // initial capacity was placed in threshold
            newCap = oldThr;
        else {               //老的阈值=0，容量和阈值都初始化为默认值，即16和12
            newCap = DEFAULT_INITIAL_CAPACITY;
            newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
        }
        
        //如果新的阈值为0，为新的阈值赋值
        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)
                //如果链表中只有一个数据，直接重新计算hash值，放入新的数组中
                        newTab[e.hash & (newCap - 1)] = e;
                //如果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;
}

上面一段代码的内容比较好理解，都已经根据注释就能看懂，主要的内容在下半部分：扩容后和扩容前，数据存放位置的变化。我们可以理解一下。

经过观测可以发现，我们使用的是2次幂的扩展(指长度扩为原来2倍)，所以，元素的位置要么是在原位置，要么是在原位置再移动2次幂的位置。看下图可以明白这句话的意思，n为table的长度，图（a）表示扩容前的key1和key2两种key确定索引位置的示例，图（b）表示扩容后key1和key2两种key确定索引位置的示例，其中hash1是key1对应的哈希与高位运算结果。

image

元素在重新计算hash之后，因为n变为2倍，那么n-1的mask范围在高位多1bit(红色)，因此新的index就会发生这样的变化：

image

因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap”，可以看看下图为16扩充为32的resize示意图：

image

这个设计确实非常的巧妙，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。有一点注意区别，JDK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，JDK1.8不会倒置。

小结

以上就是HashMap中比较重要的源码分析，希望大家能有所收获。高并发时，HashMap还有一些问题，具体是啥问题，大家搜一搜吧，后续可能会出相应的文章，届时再详细解析。所以，在高并发的情况下，还是尽量使用ConcurrentHashMap，后续也会对ConcurrentHashMap的源码进行解析，希望大家关注。

参考

• http://www.importnew.com/20386.html
• JDK 源码