Java HashMap 多線程環境下的死循環隱患與 Rehash 機制深度剖析

引言：淘寶生產事故的教訓

早年淘寶工程師曝光一個經典案例：單線程應用為提升性能改造為多線程後，上線發現 CPU 頻繁飆升 100%。排查發現罪魁禍首是 HashMap 在併發擴容時導致的死循環。這不僅是線程安全問題，更揭示了 HashMap 內部 rehash() 機制在併發下的致命缺陷。

一、單線程改多線程：看似簡單實則暗藏殺機

1.1 線程安全容器 ≠ 絕對安全

許多開發者誤以為使用 Collections.synchronizedList() 或 ConcurrentHashMap 就高枕無憂。實則不然，複合操作的原子性往往被忽視：

// 典型隱患代碼：檢查-然後獲取（Check-Then-Act）
if (list.size() > 0) {      // 線程 A 執行此處
    return list.get(0);     // 線程 B 可能在此刻刪除了唯一元素 → IndexOutOfBoundsException
}

即使底層容器線程安全，業務邏輯的複合操作若無額外同步，依然會出現競態條件。

1.2 郵件系統多線程改造的慘痛教訓

作者曾因郵件收發性能問題大膽引入多線程，卻因任務劃分邏輯缺陷導致重複發送、狀態不一致。核心教訓：多線程不僅是技術疊加，更是業務建模的重構。必須重新審視：共享狀態、臨界區、任務邊界、失敗重試語義。

二、HashMap Rehash 機制：空間與時間的雙重代價

2.1 什麼觸發 Rehash？

當 size > threshold（capacity × loadFactor） 時，HashMap 會調用 resize() 進行擴容：

1. 分配新數組：容量翻倍（newCap = oldCap << 1），JDK 8 後為 2 的冪次。
2. 重新散列：遍歷舊桶位，將每個節點重新計算索引（(n - 1) & hash）並掛接到新數組。
3. 鏈表/紅黑樹遷移：JDK 8 引入樹化，遷移邏輯更複雜。

2.2 為什麼 Rehash 代價高昂？

2.3 併發 Rehash 導致死循環的根因（JDK 7 及之前）

JDK 7 使用頭插法遷移鏈表：

// 簡化版遷移邏輯
Entry next = e.next;
e.next = newTable[index];  // 將 e 插入新桶頭部
newTable[index] = e;
e = next;

併發場景：線程 A、B 同時擴容，對同一鏈表操作。假設鏈表 1 → 2 → null：

1. 線程 A 讀取 e=1, next=2，時間片耗盡。
2. 線程 B 完成遷移，新鏈表變為 2 → 1 → null。
3. 線程 A 恢復，將 1.next = 2（但 2 已指向 1），形成 環狀鏈表：1 ↔ 2。
4. 後續 get() 遍歷陷入無限循環 → CPU 100%。

JDK 8 改為尾插法保持原序，避免了環狀鏈表，但併發下仍會導致數據丟失、鏈表斷裂，本質上HashMap 非線程安全。

三、正確的併發選型建議

3.1 ConcurrentHashMap：生產環境首選

• JDK 7：分段鎖（Segment 數組 + HashEntry 鏈表），理論併發度 16。
• JDK 8+：CAS + synchronized (節點首部) + 紅黑樹，細粒度鎖，性能大幅提升，size() 使用 LongAdder。
• 適用場景：高併發讀寫、緩存、計數器、會話存儲。

3.2 其他線程安全 Map 選項

3.3 避坑清單

1. 絕不在多線程環境共享 HashMap（包括作為類靜態字段、Session 屬性等）。
2. 複合操作必須加鎖：computeIfAbsent、putIfAbsent 等原子方法優於手動同步。
3. 預估容量：new ConcurrentHashMap<>(expectedSize) 減少擴容頻率。
4. 避免在迭代時修改：使用 forEach、reduce 等聚合操作，或加鎖遍歷。

四、總結與反思

HashMap 死循環問題本質上是非線程安全數據結構在併發下的行為未定義。Sun/Oracle 明確表示：HashMap 不支援併發，請用 ConcurrentHashMap。這提醒我們：

• 基礎組件的契約必須遵守，不要嘗試「聰明地」繞過限制。
• 性能優化前先確保正確性，單線程改多線程是架構級重構，而非簡單加鎖。
• 理解底層機制（Rehash、CAS、鎖升級）才能在生產環境做出靠譜選型。

「線程安全的容器並不真正線程安全，會用 ConcurrentHashMap 只是進入初級階段。」—— 這句話依然振聾發聵。