Java Condition精准唤醒实现多条件生产者消费者

本文深入剖析了Java中Condition机制在多条件生产者-消费者场景下的精准唤醒实践，强调其与synchronized.wait()的本质区别——Condition必须依附于ReentrantLock，需严格遵循“先lock.lock()再await()”的顺序，且await会自动释放并重新获取锁；通过为同一锁创建多个Condition（如notEmpty和notFull），实现按需唤醒、避免notifyAll带来的性能损耗；同时警示关键陷阱：必须用while循环防止虚假唤醒、signal()使用需谨慎匹配等待线程数量、中断处理要恢复中断状态、超时等待需校验返回值，并指出常见错误如混用synchronized与Condition、忽略唤醒前提条件等，为高并发有界队列等场景提供健壮、高效、可维护的线程协作方案。

Condition.await() 为什么不能替代 synchronized.wait() 直接用

因为 Condition 必须绑定在 ReentrantLock 上，不是任意对象都能调用——它不依赖对象监视器（monitor），而是靠 lock + condition 的显式配对。直接拿 synchronized 块里的对象去 new Condition？编译都过不去。

常见错误现象：IllegalMonitorStateException 不会出现，但你会卡在 lock.newCondition() 之前就发现没 lock 根本没法建 condition；或者忘了 lock.lock() 就调 condition.await()，结果线程永远阻塞（因为 await 前必须已持有 lock）。

• 必须先 lock.lock()，再 condition.await()，且 await 会自动释放该 lock
• await() 返回前会重新竞争并获取 lock，所以后续代码仍处于临界区
• 别在 synchronized 方法里混用 Condition，语义冲突，JVM 不拦你，但逻辑必乱

多个 Condition 怎么对应不同等待场景（比如 notEmpty / notFull）

一个 ReentrantLock 可以创建多个 Condition 实例，这是精准唤醒的核心：生产者只唤醒等消费的线程，消费者只唤醒等生产的线程，避免 notifyAll() 的“全量惊群”。

使用场景：有界队列（如 ArrayBlockingQueue 内部就是这么干的）。你需要两个独立等待队列——一个存“等数据”的消费者，一个存“等空间”的生产者。

• 定义两个 condition：notEmpty = lock.newCondition()、notFull = lock.newCondition()
• 消费者取数据前 notEmpty.await()，取完后 notFull.signal()（告诉生产者“有空位了”）
• 生产者放数据前 notFull.await()，放完后 notEmpty.signal()（告诉消费者“有数据了”）
• 别用 signal() 代替 signalAll() 除非你确认只有一个线程在等——否则可能漏唤醒

signal() 和 signalAll() 选哪个？什么时候会丢唤醒

signal() 只唤醒一个在该 condition 上等待的线程，signalAll() 唤醒全部。看似 signalAll() 更安全，但它会引发不必要的竞争，尤其在高并发写入时拖慢吞吐。

容易踩的坑：用 signal() 却没检查循环条件，导致虚假唤醒后直接往下跑，读到空/满状态还硬操作。

• 所有 await() 必须写在 while 循环里，不能用 if ——例如 while (queue.isEmpty()) notEmpty.await();
• signal() 安全的前提是：每次状态变更只影响一个等待方，且你确保最多一个线程在等这个条件（比如单消费者模型）
• 如果生产者和消费者都是多线程，又用了 signal()，但多个消费者同时被唤醒后抢同一个元素，就可能出现 IndexOutOfBoundsException 或空指针

中断响应与超时 await 的实际处理方式

Condition 支持响应中断（await() 抛 InterruptedException）和带超时的等待（awaitNanos(long)），比 synchronized + wait() 更灵活，但也更易出错。

性能影响：超时等待本身开销不大，但频繁进出阻塞态会增加线程调度负担；中断则需上层主动管理中断状态，否则可能静默吞掉异常。

• 捕获 InterruptedException 后，通常应恢复中断状态：Thread.currentThread().interrupt();
• 不要在 catch 里只打日志然后继续跑——这会让线程失去“被中断”的语义，上游无法感知
• awaitNanos() 返回值是剩余纳秒数，≤ 0 表示超时，> 0 表示被 signal 唤醒，要结合 while 循环重检条件
• 避免在 finally 里无条件 lock.unlock() ——如果 await 被中断，lock 已释放，再 unlock 会抛 IllegalMonitorStateException

事情说清了就结束。最常被忽略的是：await() 前没加 while 循环，以及 signal() 后没考虑是否真有线程在等那个 condition。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java Condition精准唤醒实现多条件生产者消费者》文章吧，也可关注golang学习网公众号了解相关技术文章。