JAVA hashmap死循環問題的出現緣由(引用自 酷殼):html
若是一個程序以前使用的是單線程,當程序有單線程編程了多線程後,就會出現這個程序佔用了100%的CPU,查看堆棧,你會發現程序都Hang在了HashMap.get()這個方法上了。咱們簡單的看一下咱們本身的代碼,咱們就知道HashMap被多個線程操做。而Java的文檔說HashMap是非線程安全的,應該用ConcurrentHashMap。java
Hash表數據結構 git
HashMap一般會用一個指針數組(假設爲table[])來作分散全部的key,當一個key被加入時,會經過Hash算法經過key算出這個數組的下標i,而後就把這個<key, value>插到table[i]中,若是有兩個不一樣的key被算在了同一個i,那麼就叫衝突,又叫碰撞,這樣會在table[i]上造成一個鏈表。github
咱們知道,若是table[]的尺寸很小,好比只有2個,若是要放進10個keys的話,那麼碰撞很是頻繁,因而一個O(1)的查找算法,就變成了鏈表遍歷,性能變成了O(n),這是Hash表的缺陷(可參看《Hash Collision DoS 問題》)。算法
因此,Hash表的尺寸和容量很是的重要。通常來講,Hash表這個容器當有數據要插入時,都會檢查容量有沒有超過設定的thredhold,若是超過,須要增大Hash表的尺寸,可是這樣一來,整個Hash表裏的無素都須要被重算一遍。這叫rehash,這個成本至關的大。shell
查看源代碼 HashMap的rehash源代碼:編程
下面,咱們來看一下Java的HashMap的源代碼。Put一個Key,Value對到Hash表中:數組
public V put(K key, V value) { ...... //算Hash值 int hash = hash(key.hashCode()); int i = 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); return oldValue; } } modCount++; //該key不存在,須要增長一個結點 addEntry(hash, key, value, i); return null; }
檢查容量是否超標:安全
void addEntry(int hash, K key, V value, int bucketIndex) { Entry<K,V> e = table[bucketIndex]; table[bucketIndex] = new Entry<K,V>(hash, key, value, e); //查看當前的size是否超過了咱們設定的閾值threshold,若是超過,須要resize if (size++ >= threshold) resize(2 * table.length); }
新建一個更大尺寸的hash表,而後把數據從老的Hash表中遷移到新的Hash表中。數據結構
void resize(int newCapacity) { Entry[] oldTable = table; int oldCapacity = oldTable.length; ...... //建立一個新的Hash Table Entry[] newTable = new Entry[newCapacity]; //將Old Hash Table上的數據遷移到New Hash Table上 transfer(newTable); table = newTable; threshold = (int)(newCapacity * loadFactor); }
遷移的源代碼,注意高亮處:
void transfer(Entry[] newTable) { Entry[] src = table; int newCapacity = newTable.length; //下面這段代碼的意思是: // 從OldTable裏摘一個元素出來,而後放到NewTable中 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); } } }
畫了個圖作了個演示。
1)假設咱們有兩個線程。我用紅色和淺藍色標註了一下。
咱們再回頭看一下咱們的 transfer代碼中的這個細節:
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);
而咱們的線程二執行完成了。因而咱們有下面的這個樣子。
注意,由於Thread1的 e 指向了key(3),而next指向了key(7),其在線程二rehash後,指向了線程二重組後的鏈表。咱們能夠看到鏈表的順序被反轉後。
2)線程一被調度回來執行。
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。
Demo類com.oldratlee.fucking.concurrency.HashMapHangDemo
,能夠復現這個問題:
主線程中開啓2個任務線程執行HashMap
的put
操做。主線程作get
操做。
經過沒有持續的輸出斷定主線程Block
,即HashMap
的出現死循環。
mvn compile exec:java -Dexec.mainClass=com.oldratlee.fucking.concurrency.HashMapHangDemo
具體demo以下:
public class HashMapHangDemo { final Map<Integer, Object> holder = new HashMap<Integer, Object>(); public static void main(String[] args) { HashMapHangDemo demo = new HashMapHangDemo(); for (int i = 0; i < 100; i++) { demo.holder.put(i, null); } Thread thread = new Thread(demo.getConcurrencyCheckTask()); thread.start(); thread = new Thread(demo.getConcurrencyCheckTask()); thread.start(); System.out.println("Start get in main!"); for (int i = 0; ; ++i) { for (int j = 0; j < 10000; ++j) { demo.holder.get(j); // 若是出現hashmap的get hang住問題,則下面的輸出就不會再出現了。 // 在個人開發機上,很容易在第一輪就觀察到這個問題。 System.out.printf("Got key %s in round %s\n", j, i); } } } ConcurrencyTask getConcurrencyCheckTask() { return new ConcurrencyTask(); } private class ConcurrencyTask implements Runnable { Random random = new Random(); @Override public void run() { System.out.println("Add loop started in task!"); while (true) { holder.put(random.nextInt() % (1024 * 1024 * 100), null); } } } }