Java线程通信：wait与notify实现生产者消费者

本文深入剖析了Java中wait与notify机制在生产者消费者模型中的关键实践要点：强调wait必须置于synchronized块内以避免IllegalMonitorStateException，解释notify的随机唤醒特性及notifyAll在多线程场景下的必要性，揭示虚假唤醒的真实风险并强制推荐while循环而非if检查等待条件，同时指出缓冲区动态变化时状态与通知解耦带来的隐蔽性能陷阱——真正难点不在于语法正确，而在于精准建模线程间的状态依赖与信号契约，稍有疏漏便可能导致死锁、丢失通知或吞吐骤降。

为什么 wait() 必须在 synchronized 块里调用

因为 wait() 会释放当前线程持有的锁，而 JVM 要求这个锁必须是它正在等待的那个对象的监视器锁。没加锁就调用，直接抛 IllegalMonitorStateException。

常见错误现象：代码看起来“逻辑对”，但一运行就崩在 wait() 那行，堆栈里清清楚楚写着 IllegalMonitorStateException。

• 必须用 synchronized(obj) { obj.wait(); }，不能写成 obj.wait() 单独一行
• 如果锁的是 this，那 wait() 前后都得在 synchronized(this) 块内
• 别用字符串字面量或常量池对象当锁（比如 synchronized("lock")），不同类加载器或模块可能拿到不同实例，导致锁失效

notify() 和 notifyAll() 的实际唤醒行为差异

notify() 只随机唤醒一个在该对象上 wait() 的线程；notifyAll() 唤醒所有。但注意：唤醒 ≠ 立即执行 —— 被唤醒线程还得重新竞争锁，拿到锁后才从 wait() 返回。

生产者消费者模型里，如果只用 notify()，容易卡死：比如缓冲区满时生产者 wait()，消费者消费完后只 notify() 一个生产者，但此时另一个消费者也刚消费完、顺手又 notify() 了同一线程，剩下那个生产者永远没人叫。

• 缓冲区有多个生产者/消费者时，优先用 notifyAll()，避免信号丢失
• notify() 仅适合严格一对一协作（如单生产者单消费者 + 明确状态机），且需确保每次 notify 都对应一个确定等待者
• 不要假设唤醒顺序 —— JVM 不保证 FIFO，也不按等待时间排序

为什么 wait() 要放在 while 循环里，而不是 if

虚假唤醒（spurious wakeup）是真实存在的：线程可能没被 notify() 就自己醒了。JVM 规范允许这么做，Linux 的 futex 和 HotSpot 实现都可能触发。

典型症状：消费者发现缓冲区空，进入 wait()；醒来后直接取数据，结果 IndexOutOfBoundsException 或 NullPointerException。

• 永远用 while (conditionNotMet) { obj.wait(); }，别用 if
• 检查条件必须和 wait() 所依赖的状态完全一致，比如 while (queue.isEmpty())，不能简化为 while (queue.size() == 0)（虽然等价，但可读性差、易错）
• 条件变量要 volatile 或受同一把锁保护，否则可能读到过期值

生产者消费者中缓冲区容量变化时的边界处理

缓冲区大小不是固定值时（比如动态扩容队列），wait()/notify() 的触发点容易错位。例如扩容后消费者还在等“非空”，但生产者刚写完就 notify()，而此时缓冲区其实已满，下一个生产者立刻阻塞 —— 表面看没问题，实则吞吐骤降。

根本问题在于：状态判断和通知没有原子绑定。一个操作改了多个状态（如 size + capacity），但只基于其中一个发通知。

• 用 LinkedBlockingQueue 这类 JDK 原生线程安全队列，内部已处理好所有边界
• 手写时，所有影响等待条件的修改（add/remove/capacity change）必须在同一个 synchronized 块里完成，并在末尾统一 notifyAll()
• 避免在 wait() 前做耗时操作（如 IO、复杂计算），否则会拉长锁持有时间，拖慢其他线程

真正难的不是写对 wait 和 notify，而是想清楚“谁在等什么、谁该什么时候喊一声、喊完别人会不会听错”。状态耦合越紧，越容易漏掉某个 notify 场景。

本篇关于《Java线程通信：wait与notify实现生产者消费者》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！