Condition.await()不能替代wait()，因其必须绑定ReentrantLock且需先加锁；一个锁可创建多个Condition实现精准唤醒，如生产者-消费者中notFull和notEmpty分离等待队列，须严格配对await/signal，注意finally解锁与中断处理。
Condition.await() 为什么不能直接替代 wait()
因为 Condition 不是 Object.wait() 的简单翻版——它必须绑定在特定的 ReentrantLock 实例上，且每次 await() 前必须已持有该锁。常见错误是调用 condition.await() 时没先 lock.lock()，会直接抛 IllegalMonitorStateException。
更关键的是：一个 ReentrantLock 可以创建多个 Condition 实例，每个 Condition 独立维护自己的等待队列。这是实现“精准唤醒”的前提。
- 必须显式配对：用哪个
Conditionawait()，就用同一个Conditionsignal()或signalAll() -
lock.newCondition()每次都返回新实例，两个看似一样的条件对象实际互不感知 - 不能跨锁使用：A 锁的
Condition无法被 B 锁的signal()唤醒
如何为不同等待逻辑分配独立 Condition
比如生产者-消费者场景中，“等有空间”和“等有数据”是两种完全独立的阻塞原因，必须拆成两个 Condition：
private final ReentrantLock lock = new ReentrantLock(); private final Condition notFull = lock.newCondition(); // 空间满时用 private final Condition notEmpty = lock.newCondition(); // 数据空时用
这样当生产者写完一个元素后，只需 notEmpty.signal()，只唤醒正在等数据的消费者线程；同理，消费者取走一个后调 notFull.signal()，只唤醒等空间的生产者。
- 命名要体现语义（如
canRead、canWrite），避免用cond1、cond2这类无意义名 - 不要复用同一个
Condition处理多种等待条件，否则signal()会误唤醒 - 如果业务里有“等某个具体值出现”，仍需配合 while 循环 + 条件判断（即所谓的“虚假唤醒防护”）
signal() 和 signalAll() 的选择依据
signal() 随机唤醒一个在该 Condition 上等待的线程，signalAll() 唤醒全部。选哪个不看“要不要快”，而看“唤醒后是否所有线程都能立即继续执行”。
- 若等待条件是互斥的（例如：只有一个缓冲槽位空闲），用
signal()更高效，避免唤醒多个线程争抢同一资源 - 若条件变化可能让多个等待者同时满足（例如：批量插入后，多个消费者都能读到新数据），必须用
signalAll()，否则部分线程永远卡在await() - 注意：
signal()不保证唤醒“最先等待的那个”，JVM 不保证 FIFO，别依赖唤醒顺序
容易被忽略的 finally 释放锁和中断处理
很多人只记得 lock()，却忘了 await() 返回后必须手动 unlock()，而且必须放在 finally 块里。否则一旦 await() 被中断或异常退出，锁就泄露了。
lock.lock();
try {
while (!canProceed()) {
condition.await();
}
// 执行业务逻辑
} finally {
lock.unlock(); // 必须！
}
- 如果业务逻辑允许响应中断，应捕获
InterruptedException并恢复中断状态：Thread.currentThread().interrupt() -
awaitNanos()、awaitUntil()等带超时的方法返回false表示超时未唤醒，此时也要确保解锁 - 别在
await()后加lock.lock()—— 它返回时已经自动重新获取了锁
精准唤醒的本质不是魔法，而是把不同等待意图映射到不同的等待队列，并严格遵守“谁 await、谁 signal”的契约。最常出问题的地方，往往不是逻辑设计，而是漏掉 finally unlock() 或者误用了同一个 Condition 实例。
