為什麼 Java 的 wait/notify 逐漸被新 API 取代？
在 Java 的演進過程中，雖然 Object.wait() 與 Object.notify() 仍存在於核心庫中，但在現代開發場景，java.util.concurrent (JUC) 提供的 Lock 與 Condition 已成為主流。以下是三大核心取代原因：
1. 靈活性與精確控制 (Multiple Conditions)
這是最關鍵的進步。舊有機制中，每個物件僅有一個「等待集」。
- 舊機制： 生產者與消費者共用同一個等待隊列。呼叫
notify()無法指定喚醒誰，常被迫改用notifyAll()，導致驚群效應 (Thundering Herd)。 - 新機制 (Condition)： 一個鎖可建立多個條件物件（如
notFull,notEmpty）。生產者只需喚醒消費者，反之亦然，效能大幅提升。
2. 安全性與健壯性 (Robustness)
新 API 解決了許多語法上的僵化問題：
| 特性 | Object.wait/notify | JUC Condition |
|---|---|---|
| 鎖的依賴 | 強烈耦合 synchronized | 配合 ReentrantLock，更靈活 |
| 中斷響應 | 僅支援基本中斷 | 支援不可中斷的等待 (awaitUninterruptibly) |
| 超時控制 | 毫秒級 | 精確至奈米級 (nanoseconds) |
3. 功能擴展性 (Advanced Features)
ReentrantLock 提供了舊機制無法達成的進階功能：
公平性 (Fairness)： 新 API 支援公平鎖設定，確保等待最久的執行緒優先獲取資源。
非阻塞嘗試： 透過tryLock()，執行緒可以在拿不到鎖時立即返回，避免死等。
總結：除非是極簡的同步邏輯，否則在現代 Java 開發中，ReentrantLock + Condition 是更安全、高效的選擇。
沒有留言:
張貼留言