Java 多線程同步問題探究（三、下）：ReentrantLock 公平與非公平鎖

公平鎖 vs 非公平鎖

ReentrantLock 建構子接受可選布林參數 fair：

• true (公平鎖)：多線程爭用時傾向授予等待最久線程
• false (非公平鎖，預設)：不保證特定存取順序，允許「插隊」

JDK 文檔：公平鎖程式在多線程訪問時總體吞吐量較低（速度慢、常極慢），但獲得鎖和分配均衡性差異較小。非公平鎖吞吐量較高。公平鎖不保證線程調度公平性，某線程可能獲得多倍成功機會（其他活動線程未被處理且未持有鎖時）。tryLock 未使用公平設定。

執行順序對比

非公平鎖：線程釋放第一鎖後，剛釋放的鎖馬上被下一線程佔有。
公平鎖：傾向授予等待最久線程，第一鎖釋放後，第二鎖授予第一線程，第一鎖授予第二線程。公平鎖平衡分配耗時，導致第一線程獲得第二鎖優先於第二線程獲得第一鎖。

效能基準測試 (IBM 開發者社區數據)

4 CPU 環境

單 CPU 環境

同步和公平鎖吞吐量最低，公平鎖更低。同步內建監視器鎖是非公平的且永遠非公平。JVM 保證所有線程最終獲得所等待鎖，確保統計公平性，成本遠低於絕對公平保證。

Lock 的代價

雖 Lock 在激烈爭用下提供更好並發性，但有代價：

1. 必須手動在 finally 塊釋放鎖，獲取/釋放不受 JVM 控制，要求程式設計師更細心
2. JVM 用 synchronized 管理鎖時，線程轉儲包含鎖資訊，對除錯極有價值（識別死鎖/異常行為來源）。Lock 只是普通類，JVM 不知道哪線程擁有 Lock 物件

結論：大量線程爭用時，Lock 來了，大家都讓開；但犧牲一定可維護性。