Java 多線程性能優化實戰（二）：同步機制深度解析與死鎖避坑指南

多線程程序若缺乏正確的同步控制，極易產生數據不一致、競態條件等「怪異行為」。本文深入剖析 Java 同步機制的底層原理（監視器與鎖）、synchronized 關鍵字的兩種用法、以及兩大經典同步陷阱——不同步與死鎖的成因、表現與解決方案，助你構建線程安全且高性能的併發應用。

一、為什麼必須同步？—— 競態條件的根源

當多線程並發訪問共享變量（實例字段、靜態字段）且至少一個線程進行寫入時，若無同步措施，線程調度的不確定性會導致操作交錯，產生競態條件。典型場景：存款線程與取款線程並發修改賬戶餘額與交易類型，導致「取款額顯示為存款金額」等邏輯錯誤。

本質上，單核 CPU 通過時間片輪轉模擬併發，多核 CPU 真並行；兩者下線程進入關鍵代碼區的時間順序均不可控。若關鍵區包含非原子操作（如先寫 name 再寫 amount，中間穿插 sleep/IO），極易被打斷導致數據不一致。

特別提示：long 和 double 這兩種 64 位類型在 32 位 JVM 上非原子讀寫，甚至單純的讀取也可能得到「半舊半新」的值，必須同步訪問。

二、Java 同步機制：監視器與鎖

Java 採用監視器模型：每個對象關聯一把鎖。線程進入同步代碼區前必須獲得該鎖；鎖被佔用時，請求線程進入等待集；持有鎖的線程退出同步區（正常或異常）時自動釋放鎖，JVM 喚醒等待線程競爭。

JVM 提供 monitorenter/monitorexit 字節碼指令實現此機制，開發者通過 synchronized 關鍵字聲明式使用。

1. 同步語句塊

synchronized(lockObject) {
    // 關鍵代碼區：訪問共享變量
}

lockObject 可為任意對象引用。所有線程必須競爭同一把鎖才能實現互斥。推薦使用 final 修飾鎖對象，防止引用變更導致同步失效。

2. 同步方法

• 實例同步方法：synchronized void method()，隱式鎖為 this。
• 靜態同步方法：static synchronized void method()，隱式鎖為當前類的 Class 對象。

同步方法等價於「整個方法體被 synchronized(this/class) 包裹」。慎用同步 run() 方法，否則會導致多線程串行化，喪失併發優勢。

3. 對象鎖與類鎖的獨立性

對象鎖（非 static 同步）與類鎖（static 同步）互不干擾。同一線程可同時持有兩者；不同線程分別持有兩者時可並行。但同步方法調用另一同步方法時會重入獲取兩把鎖，需注意鎖獲取順序一致性以防死鎖。

三、同步優化：細粒度鎖

將同步範圍縮小到僅覆蓋共享變量訪問代碼，而非整個方法。例如：

// 優化前：整個 run() 同步，sleep 期間也持有鎖
public synchronized void run() { for(...) { shared++; sleep(); } }

// 優化後：僅同步 shared++，sleep 釋放鎖
public void run() { for(...) { synchronized(this) { shared++; } sleep(); } }

細粒度鎖能大幅降低鎖爭用，提升併發吞吐量。

四、陷阱一：偽同步（不同步）

現象：代碼使用了 synchronized 但無實際互斥效果，輸出仍錯誤。
原因：不同線程同步於不同的鎖對象。典型錯誤：synchronized(this) 但 this 指向不同的 Thread 實例（每個線程一個 Task 實例）。
修正：所有相關線程必須共享同一個鎖對象（如傳入共享的 Task 實例、static 字段、或單例鎖）。

五、陷阱二：死鎖

現象：程序運行一段時間後凍結，無任何輸出，CPU 佔用極低。
成因：兩個或多個線程循環等待彼此持有的鎖，形成環路等待。經典案例：線程 A 持有鎖 1 等待鎖 2，線程 B 持有鎖 2 等待鎖 1。
核心條件（Coffman 條件）：互斥、持有並等待、不可搶佔、循環等待——同時滿足必發生死鎖。

避免死鎖的鐵律

1. 固定鎖獲取順序：所有線程按相同全局順序獲取多把鎖（如按 hashCode、內存地址、業務 ID 排序）。
2. 合併粗粒度鎖：將多把細粒度鎖封裝為一把粗粒度鎖，犧牲部分併發換取安全性。
3. 嘗試性獲取鎖：使用 Lock.tryLock(timeout) 替代內置鎖，超時則釋放已持有鎖並重試，打破「持有並等待」。
4. 設計階段審查：繪製鎖依賴圖，靜態分析潛在環路。

六、性能考量：鎖開銷與 JVM 優化

早期 JVM 鎖開銷大，現代 HotSpot JVM（偏向鎖、輕量級鎖、鎖消除、鎖粗化等優化）已將無競爭同步開銷降至極低。但高競爭下的內核態切換仍是性能殺手，故優先優化算法降低競爭，而非依賴 JVM 鎖優化。

七、總結與最佳實踐

• 共享可變數據必須同步，long/double 更是鐵律。
• 優先使用同步塊 + final 鎖對象，明確鎖語義，便於細粒度控制。
• 嚴禁 synchronized(this) 於多實例場景；嚴禁同步 run()。
• 死鎖預防核心：全局統一鎖獲取順序。
• 善用 Thread.holdsLock(obj) 調試鎖持有狀態。

同步是多線程正確性的基石，亦是性能調優的關鍵點。深諳其理、謹守其則，方能馴服併發之獸。