HashMap 在多線程環境下可能引發哪些問題？
答案：
在多線程同時操作 HashMap 時，可能引發 死循環、數據丟失、臟數據讀取 等問題。
根本原因：
HashMap 的設計是非線程安全的，多線程并發修改其結構（如擴容、插入、刪除）會導致內部鏈表或紅黑樹結構損壞。
具體問題分析：
1. 死循環（JDK 1.7 及之前版本的經典問題）
- 觸發場景： 多個線程同時觸發擴容（
resize）。 - 原因：
JDK 1.7 的擴容采用“頭插法”遷移鏈表，多線程并發操作可能導致鏈表形成環狀結構（循環鏈表）。
舉例：
想象兩個搬運工（線程）同時把書從一個舊書架搬到新書架，但搬運時不小心把書的順序弄反了，結果某些書被循環引用，再也找不到正確的順序了。
2. 數據丟失
- 觸發場景： 多個線程同時插入新數據。
- 原因：
兩個線程同時計算哈希并定位到同一個桶（數組位置），后插入的線程可能覆蓋前一個線程寫入的值。
舉例：
兩個人（線程）同時往同一個抽屜里放文件，后放的人直接把自己的文件蓋在別人的文件上，導致別人的文件丟失。
3. 臟數據讀取
- 觸發場景： 一個線程正在擴容，另一個線程嘗試讀取數據。
- 原因：
擴容過程中鏈表可能被臨時拆分成兩部分，此時讀取的數據可能不完整或為舊數據。
類比：
搬家時（擴容），你一邊搬箱子一邊查字典（讀數據），可能查到的詞條是已經搬走的舊箱子里的內容。
如何解決？
方案 1：使用線程安全的替代類
-
推薦方法：
ConcurrentHashMap
原理：- JDK 1.7 采用分段鎖（每個段獨立加鎖，提高并發度）。
- JDK 1.8 改為基于
CAS和synchronized鎖單個桶（更細粒度）。
舉例：
把倉庫分成多個小房間（分段），每個房間有獨立的鎖，搬運工可以同時操作不同房間，互不干擾。
-
其他方法（不推薦）：
Hashtable：全表鎖，性能差（類似整個倉庫只有一把鎖，所有人排隊操作）。Collections.synchronizedMap(new HashMap())：包裝類，同樣全表鎖。
方案 2：手動加鎖（僅限特殊場景）
- 方法： 使用
synchronized或ReentrantLock包裹所有 HashMap 操作。
缺點： 完全串行化，性能極低，不如直接使用ConcurrentHashMap。
舉個栗子 🌰
問題復現（死循環）：
// JDK 1.7 環境下運行以下代碼
HashMap<Integer, Integer> map = new HashMap<>(2); // 容量2，閾值1.5
// 線程1和線程2同時執行 put 操作觸發擴容
map.put(5, 5); // 哈希沖突可能導致鏈表成環
此時調用 map.get(5) 可能陷入死循環（CPU 100%）。
解決方案：
直接替換為 ConcurrentHashMap：
ConcurrentHashMap<Integer, Integer> safeMap = new ConcurrentHashMap<>();
// 多線程操作安全
總結
| 問題 | 觸發場景 | 解決方案 |
|---|---|---|
| 死循環 | 多線程并發擴容（JDK1.7） | 使用 ConcurrentHashMap |
| 數據丟失 | 多線程同時插入同一位置 | 使用線程安全的容器 |
| 臟數據讀取 | 擴容與讀操作并發 | 避免并發讀寫非線程安全容器 |
關鍵點：
- JDK 1.8 的 HashMap 仍非線程安全（尾插法解決死循環，但其他問題仍存在）。
- 永遠不要在多線程中直接使用 HashMap，優先選擇
ConcurrentHashMap。
)
