本文繼續分析HashMap的源碼。本文的重點是resize()方法和HashMap中其他的一些方法，希望各位提出寶貴的意見。
話不多說，咱們上源碼。
final Node<K,V>[] resize() {
Node<K,V>[] 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<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)
//如果鏈表中只有一個數據，直接重新計算hash值，放入新的數組中
newTab[e.hash & (newCap - 1)] = e;
//如果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;
}
上面一段代碼的內容比較好理解，都已經根據注釋就能看懂，主要的內容在下半部分：擴容后和擴容前，數據存放位置的變化。我們可以理解一下。
經過觀測可以發現，我們使用的是2次冪的擴展(指長度擴為原來2倍)，所以，元素的位置要么是在原位置，要么是在原位置再移動2次冪的位置。看下圖可以明白這句話的意思，n為table的長度，圖（a）表示擴容前的key1和key2兩種key確定索引位置的示例，圖（b）表示擴容后key1和key2兩種key確定索引位置的示例，其中hash1是key1對應的哈希與高位運算結果。
元素在重新計算hash之后，因為n變為2倍，那么n-1的mask范圍在高位多1bit(紅色)，因此新的index就會發生這樣的變化：
因此，我們在擴充HashMap的時候，不需要像JDK1.7的實現那樣重新計算hash，只需要看看原來的hash值新增的那個bit是1還是0就好了，是0的話索引沒變，是1的話索引變成“原索引+oldCap”，可以看看下圖為16擴充為32的resize示意圖：
這個設計確實非常的巧妙，既省去了重新計算hash值的時間，而且同時，由于新增的1bit是0還是1可以認為是隨機的，因此resize的過程，均勻的把之前的沖突的節點分散到新的bucket了。這一塊就是JDK1.8新增的優化點。有一點注意區別，JDK1.7中rehash的時候，舊鏈表遷移新鏈表的時候，如果在新表的數組索引位置相同，則鏈表元素會倒置，但是從上圖可以看出，JDK1.8不會倒置。
小結
以上就是HashMap中比較重要的源碼分析，希望大家能有所收獲。高并發時，HashMap還有一些問題，具體是啥問題，大家搜一搜吧，后續可能會出相應的文章，屆時再詳細解析。所以，在高并發的情況下，還是盡量使用ConcurrentHashMap，后續也會對ConcurrentHashMap的源碼進行解析，希望大家關注。
