condition是java.util.concurrent.locks中需配合reentrantlock使用的多条件等待工具，区别于object的wait/notify在于：一个锁可绑定多个condition实现语义分离，而synchronized仅有一个隐式队列；await/signal必须在lock后unlock前调用，且需用while防虚假唤醒。
Condition 是什么，和 Object 的 wait/notify 有什么区别
Condition 是 java.util.concurrent.locks 包中用于替代 Object.wait() / Object.notify() 的协作工具，必须配合 ReentrantLock 使用。它不是独立存在的，也不能在 synchronized 块里用 —— 这是第一个容易踩的坑。
核心区别在于：一个 ReentrantLock 可以绑定多个 Condition 实例，而 synchronized 块里的每个对象只有一个隐式等待队列。这意味着你可以按业务语义拆分等待逻辑，比如生产者用 notFull、消费者用 notEmpty，互不干扰。
-
wait()/notify()必须在 synchronized 方法或块中调用，否则抛IllegalMonitorStateException -
Condition.await()/signal()必须在lock.lock()之后、lock.unlock()之前调用，否则抛IllegalMonitorStateException -
notifyAll()是“唤醒全部”，但无法指定唤醒哪类线程；Condition.signalAll()只唤醒该 Condition 上等待的线程，更精准
如何正确创建和使用 Condition 实例
不能直接 new Condition，必须通过 Lock.newCondition() 获取。常见错误是把同一个 Condition 实例混用于不同条件判断，或者在未持有锁时调用 await()。
典型写法是为每种等待场景定义独立的 Condition 变量：
立即学习“Java免费学习笔记（深入）”；
private final ReentrantLock lock = new ReentrantLock();
private final Condition notEmpty = lock.newCondition();
private final Condition notFull = lock.newCondition();
// 消费者等待非空
public void take() throws InterruptedException {
lock.lock();
try {
while (queue.isEmpty()) {
notEmpty.await(); // 释放锁并进入等待
}
// ...取元素
notFull.signal(); // 通知生产者可以继续放了
} finally {
lock.unlock();
}
}
- 一定要用
while判断条件，而不是if—— 防止虚假唤醒（spurious wakeup） -
await()会自动释放锁，被唤醒后需重新竞争锁；signal()不释放锁，只唤醒一个线程 - 如果想唤醒所有等待该条件的线程，用
signalAll()，比如广播中断或重置状态时
await() 被中断时会发生什么
Condition.await() 是响应中断的：如果线程在等待中被 interrupt()，会立即抛出 InterruptedException 并清除中断状态。这点和 Object.wait() 一致，但比 LockSupport.park() 更明确。
关键点在于：异常抛出后，当前线程**不会自动重新获取锁**，而是直接退出 try 块，由 finally 中的 unlock() 保证锁释放。所以你不需要、也不应该在 catch 块里手动 unlock。
- 不要吞掉
InterruptedException，除非你明确要忽略中断（极少见） - 若需恢复中断状态，可在 catch 块末尾调用
Thread.currentThread().interrupt() -
awaitUninterruptibly()是不响应中断的版本，但用得少，因为会丢失协作控制能力
Condition 在线程池或异步任务中能不能用
能用，但要格外小心生命周期。Condition 本身没有线程绑定，但它依赖的 ReentrantLock 和共享状态（比如队列、计数器）必须是线程安全且长期有效的。
常见陷阱是：在线程池中启动一个任务去 await，但该任务被取消或超时后，对应的 Condition 等待线程可能滞留，甚至因未 signal 导致其他线程永久阻塞。
- 避免在
CompletableFuture或@Async方法里直接 await，除非你能确保 signal 一定发生 - 考虑用
awaitNanos(long)或awaitUntil(Date)带超时的版本，防止无限等待 - 如果底层是 Netty 或 Vert.x 这类事件驱动框架，优先用它们自己的通知机制（如 Promise / Handler），而非 Condition
Condition 的价值在于精细控制多条件等待，但它要求你对锁的持有、唤醒时机和线程状态有清晰把握 —— 少一个 while、漏一次 signal、错一次 lock/unlock 配对，就可能卡死或数据错乱。
