JavaCondition线程协调详解

本文深入解析了Java中Condition接口的核心机制与实战要点，揭示其作为Lock体系下精细化线程协调工具的独特价值：相比synchronized单一隐式等待队列的局限，Condition支持同一锁绑定多个条件对象，实现生产者-消费者等场景中的精准分组唤醒，显著减少无效唤醒开销；同时强调关键实践规范——必须通过lock.newCondition()获取、await/signal严格嵌套于lock/unlock块内、坚持用while循环校验条件以抵御虚假唤醒，并详解中断处理、信号丢失风险及常见误用陷阱，帮你避开那些隐蔽却致命的并发bug。

Condition 是什么，和 synchronized 有什么区别

Condition 是 java.util.concurrent.locks 包下的接口，必须配合 Lock（如 ReentrantLock）使用，不能替代 synchronized。它提供比 wait()/notify() 更精细的线程等待/唤醒控制——比如一个锁可以绑定多个 Condition 实例，实现「按条件分组唤醒」，而 synchronized 下每个对象只有一个隐式等待队列。

常见误用是直接 new Condition()，但它是接口，必须通过 lock.newCondition() 获取；也有人试图在 synchronized 块里调用 condition.await()，这会抛 IllegalMonitorStateException，因为 await() 要求当前线程持有对应 Lock，而非内置锁。

await() / signal() 必须成对出现在 lock() / unlock() 之间

所有 await()、signal()、signalAll() 调用都必须发生在 lock.lock() 之后、lock.unlock() 之前。否则运行时会报 IllegalMonitorStateException。

典型安全写法：

lock.lock();
try {
    while (!ready) {
        condition.await(); // 等待条件成立
    }
    // 执行业务逻辑
} finally {
    lock.unlock();
}

注意：必须用 while 判断条件，不能用 if——因为虚假唤醒（spurious wakeup）可能发生，await() 返回不保证条件真成立。

• await() 会自动释放锁，并挂起当前线程
• 被 signal() 唤醒后，线程需重新竞争锁；获得锁后才从 await() 返回
• signal() 不释放锁，也不影响当前锁持有状态

多个 Condition 实现精准唤醒（比如生产者-消费者分离）

一个 ReentrantLock 可创建多个 Condition，例如生产者等「有空位」，消费者等「有数据」，两者互不干扰：

private final Lock lock = new ReentrantLock();
private final Condition notFull  = lock.newCondition();
private final Condition notEmpty = lock.newCondition();

当生产者发现队列满时调用 notFull.await()，消费者消费后调用 notFull.signal()；消费者发现空时调用 notEmpty.await()，生产者插入后调用 notEmpty.signal()。这样避免了 notifyAll() 带来的无差别唤醒开销。

容易忽略的点：signal() 并不保证立即唤醒——如果此时没有线程在该 Condition 上等待，这次调用就静默丢失；所以业务逻辑中不能依赖「发 signal 就一定有响应」，仍要靠循环检查条件变量。

中断敏感性：await() 可被 interrupt，signal() 不可中断

await() 有两种常用变体：await() 和 awaitUninterruptibly()。前者响应线程中断，抛 InterruptedException 并清除中断状态；后者忽略中断，直到被 signal 或虚假唤醒。

如果你的线程需要支持优雅中断（比如任务取消），应该捕获 InterruptedException 并在 finally 块中恢复中断状态或退出循环：

try {
    condition.await();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt(); // 恢复中断标记
    return; // 或抛出 RuntimeException 包装
}

signal() 和 signalAll() 本身不会抛异常，也不响应中断；它们只是向等待队列投递唤醒信号，真正处理中断的是被唤醒后重新竞争锁并返回的线程。

真正难调试的点往往不在语法，而在「谁在等、谁在唤、条件变量是否及时更新、有没有漏掉 signal」——这些错位不会立刻崩溃，而是导致死锁或线程永远挂起。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《JavaCondition线程协调详解》文章吧，也可关注golang学习网公众号了解相关技术文章。