嗨，大家好，我是小米，一個熱愛分享技術的老碼農（雖然不老，31歲正當年！）。今天我們來聊聊 Java 面試中一道高頻問題：SynchronizedMap 和 ConcurrentHashMap 有什么區別？

這道題看似簡單，但其實暗藏玄機，一不小心就容易掉坑。今天我們就通過一個故事 + 源碼剖析 + 性能對比，徹底搞清楚它們的區別。

故事開場：面試現場的靈魂拷問

某天，小王（5年Java開發經驗）去參加阿里社招面試。

面試官看著簡歷，笑了笑：“你寫過高并發項目？”

小王點頭：“是的，我們系統日均 QPS 過百萬，主要用 HashMap 處理緩存。”

面試官挑了挑眉：“哦？那你能說說 SynchronizedMap 和 ConcurrentHashMap 的區別嗎？”

小王：“呃……它們都能保證線程安全……”

面試官：“嗯？那如果并發度很高，你會選哪個？”

小王開始緊張了：“這個……它們……嗯……”

面試官一笑：“好吧，我們換個問題……”

小王當場淚目，回去后痛定思痛，決定徹底搞懂這兩個玩意兒！

那么，它們到底有什么區別呢？

SynchronizedMap vs ConcurrentHashMap 的核心區別

我們先來一個總結表格，直觀感受一下兩者的不同：

圖片

看完表格，我們一個個拆解講解。

SynchronizedMap：簡單粗暴的“全局鎖”

首先，SynchronizedMap 其實是 Collections.synchronizedMap() 生成的，它的本質是對 HashMap 進行“全局加鎖”，保證每次訪問都只能有一個線程進入。

我們看看源碼（簡化版）：

圖片

內部實現其實就是給 所有方法都加上 synchronized，讓所有操作串行化：

圖片

這樣雖然保證了線程安全，但也導致每次操作都要獲取整個 Map 的鎖，性能相當低，在高并發環境下會變成性能瓶頸！

適用場景

適用于并發較低，或者讀多寫少的場景，比如：

• 配置緩存
• 線程數不多的 Web 應用
• 需要簡單線程安全的地方（例如同步讀取一小塊數據）

如果是高并發環境，那就該換 ConcurrentHashMap 了！

ConcurrentHashMap：高并發神器

ConcurrentHashMap 是 Java 5 引入的，主要是為了提高并發性能。它的核心優化點有兩個：

• 分段鎖（Segment）（JDK 1.7 之前）
• CAS + 自旋鎖（JDK 1.8 之后）

讓我們看看 JDK 1.8 版本的 ConcurrentHashMap 怎么做到高性能的。

（1）底層結構

在 JDK 1.8 之前，ConcurrentHashMap 采用 分段鎖（Segment），但 JDK 1.8 之后直接用 數組 + 鏈表 + 紅黑樹 代替了分段鎖，提高了效率。

• 存儲結構：類似 HashMap，但每個桶（bucket）都是 鏈表 + 紅黑樹，高并發時可變成紅黑樹加速查詢。
• 鎖機制：不鎖整個 Map，而是只鎖住某個 bucket，這樣多個線程可以同時訪問不同的 bucket，提高并發能力。
• CAS（Compare And Swap）：無鎖操作，提升性能。

（2）put() 方法解析

看源碼（簡化版）：

圖片

可以看到，它不會鎖整個 Map，而是：

• 先用 CAS 嘗試放入數據，避免不必要的鎖競爭。
• 如果 CAS 失敗，再只鎖住當前 bucket，而不是整個 Map，提高了并發性能。

適用場景

• 高并發環境（推薦）
• 大數據量存儲
• 讀寫并重的場景
• 緩存（如 LRU Cache）

性能對比實驗

我們做個小實驗，對比兩者的性能（JMH 基準測試）：

圖片

實驗結果（吞吐量 ops/sec）：

圖片

可以看到，并發越高，SynchronizedMap 退化得越厲害，而 ConcurrentHashMap 能保持高性能。

總結：面試高分回答

如果你在面試中遇到這個問題，你可以這樣答：

“SynchronizedMap 是對整個 HashMap 加鎖，適用于低并發場景。而 ConcurrentHashMap 通過 分段鎖 + CAS 提高并發性能，在高并發環境下比 SynchronizedMap 更優。并且，SynchronizedMap 允許 null 鍵值，而 ConcurrentHashMap 不允許。”

這下，面試官該對你點頭了吧？