作者：Grey
原文地址：Java中的HashMap
擴容機制
jdk1.7
先生成新數組。
遍歷老數組中的每個位置上的鏈表上的個元素。
取個元素的key，並基於新數組長度，計算出每個元素在新數組中的下標。
將元素添加到新數組中去。
所有元轉移完了之后，將新數組賦給HashMap對象的table屬性。
jdk1.8
同樣先生成新數組。
遍歷老數組中的每個位置上的鏈表或紅黑樹。
如果是鏈表，則直接將表中的每個元索重新計算下標，並添加到新數組中去。
如果是紅黑樹，則先遍歷紅黑樹，先計算出紅黑樹中每個元索對應在新數組中的下標位置。
- 統計每個下標位置的元索個數。
- 如果該位下的元素個數超過了8，則生成一個新的紅黑樹，開將根節點添加到新數組的對應位置。
- 如果該位置下的元素個數沒有超過8，那么則生成一個鏈表，開將鏈表頭節點添加數組的對應位置。
所有元素轉移完了之后，將新數組賦給HashMap對象的table屬性。
為什么要使用紅黑樹
因為在hash沖突比較頻繁的情況下，生成的鏈表長度會非常長，這樣就會導致查詢的效率會大大降低，為了解決鏈表過長，查詢效率過低的問題，所以使用紅黑樹來優化，有一個閾值8，超過了這個閾值，就會使用紅黑樹。
jdk1.7中HashMap死循環問題
復現代碼如下，注：以下代碼需要指定jdk1.7為運行環境
import java.util.HashMap;
import java.util.Map;
public class HashMapMultiThread {
static Map<String, String> map = new HashMap<>();
public static class AddThread implements Runnable {
int start = 0;
public AddThread(int start) {
this.start = start;
}
@Override
public void run() {
for (int i = start; i < 100000; i += 2) {
map.put(Integer.toString(i), Integer.toBinaryString(i));
}
}
}
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(new HashMapMultiThread.AddThread(0));
Thread t2 = new Thread(new HashMapMultiThread.AddThread(1));
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(map.size());
}
}
運行main方法，發現程序出現死循環，無法停止。這個問題出現在HashMap擴容操作調用的transfer方法中，
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
for (Entry<K,V> e : table) {
while(null != e) {
Entry<K,V> next = e.next;
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
假設HashMap當前狀態如下
現在有兩個線程A和線程B都要執行put操作，線程A和線程B都會看到上面圖的狀態快照
線程A執行到transfer函數中
Entry<K,V> next = e.next;
這行代碼時，此時在線程A的棧中
e = 4節點
next = 5節點
假設此時線程B正在執行transfer函數中的while循環，即會把原來的table變成新一table（線程B自己的棧中），再寫入到內存中。如下圖（假設兩個元素在新的hash函數下也會映射到同一個位置）
線程A繼續執行（看到的仍是舊表），即從transfer代碼
Entry<K,V> next = e.next;
處接着執行，當前的
e = 4號節點,
next = 5號節點
處理元素4 ， 將 4 放入 線程A自己棧的新table中（新table是處於線程A自己棧中，是線程私有的，不受線程2的影響），處理4后的圖如下
線程A再復制元素5，當前 e = 5 ,而next值由於線程 B 修改了它的引用，所以next 為 4 ，處理后的新表如下圖
取5的next值時，由於線程B已經修改了5的next，5的next已經不是null而是4節點，由於取到next=4,線程A繼續循環，所以線程A執行完畢后，形成如下結構：
當操作完成，執行查找時，會陷入死循環！
HashMap中的一些參數
初始容量
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
最大容量
static final int MAXIMUM_CAPACITY = 1 << 30;
擴容因子
達到當前容量的比例為多少時進行擴容。
static final float DEFAULT_LOAD_FACTOR = 0.75f;
問題：為什么HashMap的初始容量為2的n次冪？
以下內容參考jdk1.8 HashMap底層數據結構：深入解析為什么jdk1.8 HashMap的容量一定要是2的n次冪
第一個原因，簡單來講，一個元素放到哪個桶中，是通過hash % capacity取模運算得到的余數來確定的。即調用以下indexFor方法：
static int indexFor(int h, int length) {
// assert Integer.bitCount(length) == 1 : "length must be a non-zero power of 2";
return h & (length-1);
}
hashMap用位運算來替代取模運算(capacity - 1) & hash這種運算方式為什么可以得到跟取模一樣的結果呢？ 答案是capacity是2的N次冪，計算機做位運算的效率遠高於做取模運算的效率，測試見：位運算和取模運算的運算效率對比
證明取模和位運算結果的一致性
第二個原因，將容量設置為2的n次冪關系到擴容后元素在newCap中的放置問題：
擴容后，如何實現將oldCap中的元素重新放到newCap中？我們不難想到的實現方式是：遍歷所有Node，然后重新put到新的table中， 中間會涉及計算新桶位置、處理hash碰撞等處理。這里有個不容忽視的問題——哈希碰撞。如下為resize()方法源碼：
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;
}
如果桶上只有一個節點（后面即沒鏈表也沒樹）：元素直接做hash & (newCap - 1)運算，根據結果將元素節點放到newCap的相應位置；
如果桶上是鏈表：
將鏈表上的所有節點做hash & oldCap運算（注意，這里oldCap沒有-1），會得到一個定位值（“定位值”這個名字是我自己取的，為了更好理解該值的意義）。定位值要么是“0”，要么是“小於capacity的正整數”！這是個規律，之所以能得此規律和capacity取值一定是2的n次冪有直接關系，如果容量不是2的n次冪，那么定位值就不再要么是“0”，要么是“小於capacity的正整數”，它還有可能是其他的數；
根據定位值的不同，會將鏈表一分為二得到兩個子鏈表，這兩個子鏈表根據各自的定位值直接放到newCap中：
子鏈表的定位值 == 0: 則鏈表在oldCap中是什么位置，就將子鏈表的頭節點直接放到newCap的什么位置；
子鏈表的定位值 == 小於capacity的正整數：則將子鏈表的頭節點放到newCap的“oldCap + 定位值”的位置；
這么做的好處：鏈表在被拆分成兩個子鏈表前就已經處理過了元素的哈希碰撞問題，子鏈表不用重新處理哈希碰撞問題，可以直接將頭節點直接放到newCap的合適的位置上，完成 “擴容后將元素放到newCap”這一工作。正因為如此，大大提高了jdk1.8的HashMap的擴容效率。
更詳細的圖例參考：jdk1.8 HashMap底層數據結構：深入解析為什么jdk1.8 HashMap的容量一定要是2的n次冪
一言蔽之：HashMap的容量一定要是2的n次冪，是為了提高“計算元素放哪個桶”的效率，也是為了提高擴容效率（避免了擴容后再重復處理哈希碰撞問題）。