疫苗：JAVA HASHMAP的死迴圈
在淘寶內網裡看到同事發了貼說了一個CPU被100%的線上故障，並且這個事發生了很多次，原因是在Java語言在併發情況下使用HashMap造成Race Condition，從而導致死迴圈。這個事情我4、5年前也經歷過，本來覺得沒什麼好寫的，因為Java的HashMap是非執行緒安全的，所以在併發下必然出現問題。但是，我發現近幾年，很多人都經歷過這個事（在網上查“HashMap Infinite Loop”可以看到很多人都在說這個事）所以，覺得這個是個普遍問題，需要寫篇疫苗文章說一下這個事，並且給大家看看一個完美的“Race Condition”是怎麼形成的。
問題的症狀
從前我們的Java程式碼因為一些原因使用了HashMap這個東西，但是當時的程式是單執行緒的，一切都沒有問題。後來，我們的程式效能有問題，所以需要變成多執行緒的，於是，變成多執行緒後到了線上，發現程式經常佔了100%的CPU，檢視堆疊，你會發現程式都Hang在了HashMap.get()這個方法上了，重啟程式後問題消失。但是過段時間又會來。而且，這個問題在測試環境裡可能很難重現。
我們簡單的看一下我們自己的程式碼，我們就知道HashMap被多個執行緒操作。而Java的文件說HashMap是非執行緒安全的，應該用ConcurrentHashMap。
但是在這裡我們可以來研究一下原因。
Hash表資料結構
我需要簡單地說一下HashMap這個經典的資料結構。
HashMap通常會用一個指標陣列（假設為table[]）來做分散所有的key，當一個key被加入時，會通過Hash演算法通過key算出這個陣列的下標i，然後就把這個<key, value>插到table[i]中，如果有兩個不同的key被算在了同一個i，那麼就叫衝突，又叫碰撞，這樣會在table[i]上形成一個連結串列。
我們知道，如果table[]的尺寸很小，比如只有2個，如果要放進10個keys的話，那麼碰撞非常頻繁，於是一個O(1)的查詢演算法，就變成了連結串列遍歷，效能變成了O(n)，這是Hash表的缺陷（可參看《 Hash Collision DoS 問題 》）。
所以，Hash表的尺寸和容量非常的重要。一般來說，Hash表這個容器當有資料要插入時，都會檢查容量有沒有超過設定的thredhold，如果超過，需要增大Hash表的尺寸，但是這樣一來，整個Hash表裡的無素都需要被重算一遍。這叫rehash，這個成本相當的大。
相信大家對這個基礎知識已經很熟悉了。
HashMap的rehash原始碼
下面，我們來看一下Java的HashMap的原始碼。
Put一個Key,Value對到Hash表中：
publicV put(K key, V value)
{
......
//算Hash值
inthash = hash(key.hashCode());
inti = indexFor(hash, table.length);
//如果該key已被插入，則替換掉舊的value （連結操作）
for(Entry<K,V> e = table[i]; e != null; e = e.next) {
Object k;
if(e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
returnoldValue;
}
}
modCount++;
//該key不存在，需要增加一個結點
addEntry(hash, key, value, i);
returnnull;
}
檢查容量是否超標
voidaddEntry(inthash, K key, V value, intbucketIndex)
{
Entry<K,V> e = table[bucketIndex];
table[bucketIndex] = newEntry<K,V>(hash, key, value, e);
//檢視當前的size是否超過了我們設定的閾值threshold，如果超過，需要resize
if(size++ >= threshold)
resize(2* table.length);
}
新建一個更大尺寸的hash表，然後把資料從老的Hash表中遷移到新的Hash表中。
voidresize(intnewCapacity)
{
Entry[] oldTable = table;
intoldCapacity = oldTable.length;
......
//建立一個新的Hash Table
Entry[] newTable = newEntry[newCapacity];
//將Old Hash Table上的資料遷移到New Hash Table上
transfer(newTable);
table = newTable;
threshold = (int)(newCapacity * loadFactor);
}
遷移的原始碼，注意高亮處：
voidtransfer(Entry[] newTable)
{
Entry[] src = table;
intnewCapacity = newTable.length;
//下面這段程式碼的意思是：
// 從OldTable裡摘一個元素出來，然後放到NewTable中
for(intj = 0; j < src.length; j++) {
Entry<K,V> e = src[j];
if(e != null) {
src[j] = null;
do{
Entry<K,V> next = e.next;
inti = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while(e != null);
}
}
}
好了，這個程式碼算是比較正常的。而且沒有什麼問題。
正常的ReHash的過程
畫了個圖做了個演示。
我假設了我們的hash演算法就是簡單的用key mod 一下表的大小（也就是陣列的長度）。
最上面的是old hash 表，其中的Hash表的size=2, 所以key = 3, 7, 5，在mod 2以後都衝突在table[1]這裡了。
接下來的三個步驟是Hash表 resize成4，然後所有的<key,value> 重新rehash的過程
併發下的Rehash
1）假設我們有兩個執行緒。 我用紅色和淺藍色標註了一下。
我們再回頭看一下我們的 transfer程式碼中的這個細節：
do{
Entry<K,V> next = e.next; // <--假設執行緒一執行到這裡就被排程掛起了
inti = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while(e != null);
而我們的執行緒二執行完成了。於是我們有下面的這個樣子。
注意， 因為Thread1的 e 指向了key(3)，而next指向了key(7)，其線上程二rehash後，指向了執行緒二重組後的連結串列 。我們可以看到連結串列的順序被反轉後。
2）執行緒一被排程回來執行。
先是執行 newTalbe[i] = e;
然後是e = next，導致了e指向了key(7)，
而下一次迴圈的next = e.next導致了next指向了key(3)
3）一切安好。
執行緒一接著工作。 把key(7)摘下來，放到newTable[i]的第一個，然後把e和next往下移 。
4）環形連結出現。
e.next = newTable[i] 導致 key(3).next 指向了 key(7)
注意：此時的key(7).next 已經指向了key(3)， 環形連結串列就這樣出現了。
於是，當我們的執行緒一呼叫到，HashTable.get(11)時，悲劇就出現了——Infinite Loop。
其它
有人把這個問題報給了Sun，不過Sun不認為這個是一個問題。因為HashMap本來就不支援併發。要併發就用ConcurrentHashmap
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457
我在這裡把這個事情記錄下來，只是為了讓大家瞭解並體會一下併發環境下的危險。