作者：磊哥

來源 | Java面試真題解析（ID：aimianshi666）

轉載請聯系授權（微信ID：GG_Stone）

面試合集：https://gitee.com/mydb/interview

HashMap 死循環(huán)是一個比較常見、比較經典的問題，在日常的面試中出現的頻率比較高，所以接下來咱們通過圖解的方式，帶大家徹底理解死循環(huán)的原因。

前置知識

死循環(huán)問題發(fā)生在 JDK 1.7 版本中，造成這個問題主要是由于 HashMap 自身的運行機制，加上并發(fā)操作，從而導致了死循環(huán)。在 JDK 1.7 中 HashMap 的底層數據實現是數組 + 鏈表的方式，如下圖所示：而 HashMap 在數據添加時使用的是頭插入，如下圖所示：HashMap 正常情況下的擴容實現如下圖所示：舊 HashMap 的節(jié)點會依次轉移到新 HashMap 中，舊 HashMap 轉移的順序是 A、B、C，而新 HashMap 使用的是頭插法，所以最終在新 HashMap 中的順序是 C、B、A，也就是上圖展示的那樣。有了這些前置知識之后，咱們來看死循環(huán)是如何誕生的？

死循環(huán)執(zhí)行步驟1

死循環(huán)是因為并發(fā) HashMap 擴容導致的，并發(fā)擴容的第一步，線程 T1 和線程 T2 要對 HashMap 進行擴容操作，此時 T1 和 T2 指向的是鏈表的頭結點元素 A，而 T1 和 T2 的下一個節(jié)點，也就是 T1.next 和 T2.next 指向的是 B 節(jié)點，如下圖所示：

死循環(huán)執(zhí)行步驟2

死循環(huán)的第二步操作是，線程 T2 時間片用完進入休眠狀態(tài)，而線程 T1 開始執(zhí)行擴容操作，一直到線程 T1 擴容完成后，線程 T2 才被喚醒，擴容之后的場景如下圖所示：從上圖可知線程 T1 執(zhí)行之后，因為是頭插法，所以 HashMap 的順序已經發(fā)生了改變，但線程 T2 對于發(fā)生的一切是不可知的，所以它的指向元素依然沒變，如上圖展示的那樣，T2 指向的是 A 元素，T2.next 指向的節(jié)點是 B 元素。

死循環(huán)執(zhí)行步驟3

當線程 T1 執(zhí)行完，而線程 T2 恢復執(zhí)行時，死循環(huán)就建立了，如下圖所示：因為 T1 執(zhí)行完擴容之后 B 節(jié)點的下一個節(jié)點是 A，而 T2 線程指向的首節(jié)點是 A，第二個節(jié)點是 B，這個順序剛好和 T1 擴完容完之后的節(jié)點順序是相反的。T1 執(zhí)行完之后的順序是 B 到 A，而 T2 的順序是 A 到 B，這樣 A 節(jié)點和 B 節(jié)點就形成死循環(huán)了，這就是 HashMap 死循環(huán)導致的原因。

解決方案

HashMap 死循環(huán)的常用解決方案有以下 3 個：

• 使用線程安全容器 ConcurrentHashMap 替代（推薦使用此方案）。

• 使用線程安全容器 Hashtable 替代（性能低，不建議使用）。

• 使用 synchronized 或 Lock 加鎖 HashMap 之后，再進行操作，相當于多線程排隊執(zhí)行（比較麻煩，也不建議使用）。

總結

HashMap 死循環(huán)發(fā)生在 JDK 1.7 版本中，形成死循環(huán)的原因是 HashMap 在 JDK 1.7 使用的是頭插法，頭插法 + 鏈表 + 多線程并發(fā) + HashMap 擴容，這幾個點加在一起就形成了 HashMap 的死循環(huán)，解決死鎖可以采用線程安全容器 ConcurrentHashMap 替代。

是非審之于己，毀譽聽之于人，得失安之于數。

公眾號：Java面試真題解析

往期推薦

面試突擊15：說一下HashMap底層實現？及元素添加流程？

面試突擊14：方法重寫和方法重載有什么區(qū)別？

面試突擊13：方法優(yōu)先調用可選參數還是固定參數？

面試系列12：為什么不同返回類型不算方法重載？

總結

以上是生活随笔為你收集整理的为什么HashMap会产生死循环？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。