Condition精准通知实现生产者消费者模型

本文深入解析了如何利用 Java 中的 Condition 机制精准实现生产者-消费者模型，强调通过 notFull 和 notEmpty 两个独立条件变量绑定同一 ReentrantLock，配合 while 循环严格校验业务条件以规避虚假唤醒，确保线程只响应真正相关的信号——生产后唤醒等待消费的线程，消费后唤醒等待生产的线程，从而彻底避免 notifyAll 带来的无效竞争与资源浪费；同时明确指出 await 必须在持锁状态下调用，其背后的锁释放与重入均由 Condition 自动管理，任何手动干预锁操作都会破坏语义并引发异常——这不仅提升了并发效率，更赋予了多线程协作前所未有的精确性与可控性。

用 Condition 实现生产者-消费者模型的精准通知，核心在于让不同条件下的线程只响应自己关心的信号，避免无差别唤醒（比如 notifyAll() 带来的无效竞争），从而提升效率和可控性。

用 Condition 区分“有货可取”和“有空可放”两个条件

一个阻塞队列通常需要两个独立等待条件：

• notFull：消费者不关心，只有生产者在缓冲区满时 await，生产成功后 signal 生产者可能继续放；
• notEmpty：生产者不关心，只有消费者在缓冲区空时 await，消费成功后 signal 消费者可能继续取。

这两个 Condition 必须绑定在同一个 ReentrantLock 上，但各自维护独立的等待队列，互不干扰。

必须配合 while 循环做条件检查，防止虚假唤醒

即使被 signal，也不能直接执行操作，因为可能只是被意外唤醒（spurious wakeup）或条件已再次变化。正确写法是：

• 生产者入队前：while (queue.size() == capacity) notFull.await();
• 消费者出队前：while (queue.isEmpty()) notEmpty.await();

用 while 而非 if，确保每次唤醒后都重新验证业务条件是否真正满足。

signal 要用对人：谁该醒，就通知谁的 Condition

每次状态变更后，只唤醒真正可能推进流程的一方：

• 生产一个元素后：notEmpty.signal();（告诉等待取货的消费者可以干活了）；
• 消费一个元素后：notFull.signal();（告诉等待放货的生产者可以继续放了）。

切忌在生产后调用 notFull.signal()，那会唤醒其他生产者做无用等待；同理，消费后唤醒 notEmpty 也没意义。

锁的粒度要准：await 前必须持有锁，await 会自动释放，唤醒后自动重入

典型流程如下：

• 获取 lock → 检查条件 → 不满足则调用 condition.await()（自动释放锁）→ 被 signal 后重新竞争锁 → 拿到锁后从 await 返回 → 再次检查条件 → 满足则执行业务逻辑；
• 整个过程由 Condition 与 Lock 协作完成，无需手动 unlock/lock，否则会抛 IllegalMonitorStateException。

错误做法：先 unlock 再 await，或 await 后忘记在业务逻辑前后加 lock/unlock —— Condition 的语义完全依赖 lock 的上下文。

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