JavaCondition等待通知机制全解析

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Java Condition与等待通知机制详解》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

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 变量：

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 配对，就可能卡死或数据错乱。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~