condition是reentrantlock配套的接口，支持多等待队列；而wait/notify仅绑定对象单一监视器队列，无法实现精准唤醒。
Condition 是什么，和 wait/notify 有什么区别
Condition 是 java.util.concurrent.locks 包下的接口，必须配合 ReentrantLock 使用。它不是 Object.wait() / notify() 的简单替代，而是提供了更精细的等待队列控制能力。
关键区别在于：一个 ReentrantLock 可以绑定多个 Condition 实例，每个 Condition 维护独立的等待队列；而 wait() 只能操作对象内置的单个监视器队列。
这在生产者-消费者、读写锁、状态机等场景中特别有用——比如你希望“有数据时唤醒消费者，有空位时唤醒生产者”，用两个 Condition（notFull 和 notEmpty）比用同一个锁+notifyAll() 更精准、更少虚假唤醒。
基本用法：lock + await + signal 的三步闭环
使用 Condition 必须严格遵循“加锁 → 判断条件 → 不满足则 await → 满足则操作 → signal 或 signalAll”的流程，漏掉任意一环都可能死锁或丢失通知。
常见错误现象包括：
- 在未持有锁的情况下调用
await()，抛出IllegalMonitorStateException -
await()后没重检条件，导致虚假唤醒后直接执行逻辑（比如队列仍为空却尝试取元素） -
signal()放在 unlock() 之后，通知失效（因为线程已不在等待队列中）
正确写法示例（简化版阻塞队列的 take）：
<pre class="brush:php;toolbar:false;">final ReentrantLock lock = new ReentrantLock();
final Condition notEmpty = lock.newCondition();
private E[] items;
private int takeIndex;
<p>public E take() throws InterruptedException {
lock.lock();
try {
while (items[takeIndex] == null) { // 必须用 while，不能用 if
notEmpty.await();
}
E item = items[takeIndex];
items[takeIndex] = null;
takeIndex = (takeIndex + 1) % items.length;
return item;
} finally {
lock.unlock();
}
}</p>signal() 和 signalAll() 怎么选
选哪个不取决于“要不要唤醒所有”，而取决于条件谓词是否互斥。
- 如果多个等待线程等待的是同一类条件（例如多个消费者都在等“非空”），且唤醒任意一个就能推进系统（比如取走一个元素后队列仍可能非空），用
signal() 即可，性能更好、避免惊群。 - 如果唤醒一个后，其余线程的条件依然不成立（比如你用
signal()唤醒一个消费者，但它取完发现队列又空了，而其实还有另一个生产者刚 put 完但还没 signal），那这些线程会再次 await——没问题，这是设计使然。 - 但如果你的条件之间存在依赖或覆盖（比如“缓冲区满”和“缓冲区空”共享同一把锁，但用了不同
Condition），signalAll()并不推荐——应确保每个Condition只被对应角色 await，再按需signal()。
真正该用 signalAll() 的典型场景是：所有等待线程都在等同一个全局状态变更（如“全部任务完成”），且无法预判哪一个该被唤醒。
容易被忽略的中断与超时处理
await() 有三个常用变体：await()、awaitUninterruptibly()、await(long time, TimeUnit unit)。实际工程中几乎不会用第二个。
-
await()响应中断，抛出InterruptedException，调用方必须处理（通常向上抛或恢复中断状态）； -
await(long, TimeUnit)超时后返回false，不抛异常，适合做兜底重试或降级； - 忽略中断会导致线程无法被优雅关闭，尤其在容器或框架管理的线程池中很危险。
示例中若要支持中断：
try {
if (!notEmpty.await(5, TimeUnit.SECONDS)) {
// 超时，可记录日志、触发告警或返回 null
return null;
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
throw e;
}
多线程等待唤醒真正的复杂点不在语法，而在于条件谓词的定义是否完备、是否与 signal 时机严格匹配——稍有错位，就会出现线程永远 await，或者 signal 了但没人 waiting。
