在多線程編程的江湖中，鎖機制就是維護秩序的金科玉律。今天我們就來聊聊Java中兩大鎖界頂流——Synchronized與ReentrantLock的恩怨情仇，以及為什么江湖傳聞"公平鎖是性能殺手"。

1.兩位鎖界大佬的身世之謎

血統差異

• Synchronized：根正苗紅的Java元老（JDK1.0），以關鍵字形式直接嵌入語言體系
• ReentrantLock：JUC包（java.util.concurrent）新貴（JDK5.0），基于AQS實現的API式鎖

使用姿勢對比

// Synchronized的儀式感
synchronized(obj) {
    // 臨界區代碼
}
// ReentrantLock的儀式感
Lock lock = new ReentrantLock();
lock.lock();
try {
    // 臨界區代碼
} finally {
    lock.unlock();
}

2.Synchronized VS ReentrantLock

功能對決表

隱藏技能解析

• 鎖粒度：ReentrantLock可實現更細粒度的控制（如不同條件變量）
• 性能差異：JDK6后synchronized優化后旗鼓相當，但在高并發場景下ReentrantLock更勝一籌
• 死鎖逃生：tryLock可設置超時時間，避免永久等待

3.公平鎖的潘多拉魔盒

公平鎖的代價（示例代碼）

// 公平鎖版（性能殺手）
ReentrantLock fairLock = new ReentrantLock(true);
// 非公平鎖版（推薦姿勢）
ReentrantLock unfairLock = new ReentrantLock();

為什么慎用公平鎖？

• 性能陷阱：維護FIFO隊列導致吞吐量下降30%-50%
• 線程喚醒開銷：每次喚醒都要進行上下文切換
• 偽公平現象：非公平鎖實際也能保證基本公平性
• 饑餓假象：現代操作系統調度機制已有效避免長期饑餓

公平鎖存活指南（適用場景）

• 任務執行時間差異巨大（毫秒級 vs 秒級）
• 必須嚴格保證先到先得（如證券交易系統）
• 防止資源饑餓的極端場景

4.選鎖心法口訣

默認選擇：能用synchronized就不用ReentrantLock

升級條件：遇到鎖分離、鎖投票等高級需求時再切換

公平警訓：非公平鎖能滿足90%場景，使用公平鎖需書面審批

防死守則：使用try-finally保證鎖釋放，避免鎖泄漏

5.小結

江湖傳言："過早優化是萬惡之源"。選擇鎖機制時要遵循KISS原則（Keep It Simple, Stupid），在簡潔與功能之間找到最佳平衡點，方能在多線程的江湖中立于不敗之地。