本文深入剖析 Java 原生 wait()/notify() 实现生产者-消费者模型时常见的死锁式等待问题，指出因调用位置错误、条件判断缺失、锁对象不一致及 notify() 被忽略等核心缺陷导致线程永久 WAITING，并提供符合线程协作语义的修复方案。
本文深入剖析 java 原生 `wait()`/`notify()` 实现生产者-消费者模型时常见的死锁式等待问题，指出因调用位置错误、条件判断缺失、锁对象不一致及 `notify()` 被忽略等核心缺陷导致线程永久 waiting，并提供符合线程协作语义的修复方案。
在 Java 多线程编程中，生产者-消费者模式是经典的线程协作案例，但若对 Object.wait() 和 notify() 的使用机制理解不足，极易陷入虚假唤醒（spurious wakeup）未处理、唤醒丢失（lost notification） 或锁竞争逻辑错位等陷阱——正如示例代码所示：两个线程均成功执行一次生产与消费后，便双双卡在 WAITING (on object monitor) 状态，再无响应。
? 根本原因分析
原始代码存在多个关键性错误：
notify() 调用位置错误且对象不匹配
在 produce 线程中，notify() 写在 synchronized (Shop.LL) 块内部但位于 wait() 之后，而此时线程已释放锁并进入等待态，notify() 实际由当前持有锁的线程（即自己）调用，但此时另一线程（consumer）尚未进入 wait()，或已在不同时间点等待，导致唤醒信号被忽略。更严重的是，notify() 未指定唤醒目标，且未使用 notifyAll() —— 在多线程场景下，仅 notify() 可能唤醒错误线程甚至无可用等待者。wait() 前缺乏循环条件检查（Missing Loop Idiom）
正确模式应为 while (conditionNotMet) { obj.wait(); }，而非 if。JVM 允许线程在未被显式唤醒时“自发”返回（虚假唤醒），if 判断无法防御该情况，易导致逻辑错乱或空指针。同步块粒度过粗 & 业务逻辑混入临界区
Producer.produce() 和 Consumer.buy() 方法本身被 synchronized 修饰，但其内部又操作共享 Shop.LL，而外层 synchronized (Shop.LL) 已加锁，造成冗余同步，且将耗时的 I/O（如 System.out.println）置于临界区内，延长锁持有时间，加剧竞争。
java-api-doc-generator下载分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
wait() 后未重检条件，直接退出
生产者在 wait() 返回后未再次验证 Shop.LL.size() == 0 是否成立，就继续执行；消费者同理。一旦唤醒时机不当，可能操作空/满容器，引发异常或静默失败。notify() 被写在 catch 块外却未保证执行
示例中 notify() 位于 try-catch 之外，看似总会执行，但由于 wait() 后线程被唤醒时，需重新获取锁才能继续执行后续语句，而此时若另一线程正持有锁并阻塞，notify() 将延迟执行，甚至被新进入的 wait() 覆盖。
✅ 正确实现：基于 wait()/notifyAll() 的协作范式
以下是修复后的精简可运行版本，严格遵循《Java Concurrency in Practice》推荐实践：
立即学习“Java免费学习笔记（深入）”；
import java.util.LinkedList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
public class ProducerConsumerFixed {
private static final String[] FRUITS = {"apple", "orange", "pineapple", "banana", "cherry", "kiwi"};
private static final AtomicInteger producerIndex = new AtomicInteger(0);
private static final AtomicInteger consumerIndex = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread producer = new Thread(() -> {
synchronized (Shop.LL) {
// 【关键】循环等待：缓冲区非空时才等待
while (!Shop.LL.isEmpty()) {
try {
System.out.println("Producer waiting: buffer not empty");
Shop.LL.wait(); // 释放锁，进入等待队列
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return;
}
}
// 执行生产（临界区内仅做必要操作）
for (int i = 0; i < FRUITS.length; i++) {
String fruit = FRUITS[producerIndex.getAndIncrement()];
Shop.LL.add(fruit);
System.out.println("Producer → " + fruit);
}
// 【关键】唤醒所有等待者（消费者可能在等，生产者也可能在等腾出空间）
Shop.LL.notifyAll();
}
});
Thread consumer = new Thread(() -> {
synchronized (Shop.LL) {
// 【关键】循环等待：缓冲区为空时才等待
while (Shop.LL.isEmpty()) {
try {
System.out.println("Consumer waiting: buffer empty");
Shop.LL.wait();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return;
}
}
// 执行消费
while (!Shop.LL.isEmpty() && consumerIndex.get() < FRUITS.length) {
String item = Shop.LL.remove(0);
System.out.println("Consumer ← " + item);
consumerIndex.incrementAndGet();
}
Shop.LL.notifyAll(); // 唤醒生产者（可能在等空间）
}
});
consumer.start();
producer.start();
producer.join();
consumer.join();
System.out.println("✅ All done.");
}
static class Shop {
static final List<String> LL = new LinkedList<>();
}
}⚠️ 关键注意事项
- 永远使用 while 而非 if 包裹 wait()：这是防御虚假唤醒的强制约定；
- notify() vs notifyAll()：单生产者-单消费者场景下 notify() 理论可行，但实践中强烈推荐 notifyAll()，避免因 JVM 唤醒策略差异导致的不可预测行为；
- wait()/notify() 必须在 synchronized 块内调用，且锁对象必须是同一实例（此处为 Shop.LL）；
- 业务逻辑尽量移出临界区：如日志打印、网络请求等，避免阻塞其他线程；
- 及时中断响应：捕获 InterruptedException 后应恢复中断状态（Thread.currentThread().interrupt()），而非吞没；
- 考虑现代替代方案：生产环境推荐使用 java.util.concurrent 包中的 BlockingQueue（如 ArrayBlockingQueue），其 put()/take() 方法已内置完备的等待/唤醒逻辑，线程安全且无需手动同步。
通过以上修正，程序将稳定输出全部水果的生产和消费过程，彻底消除无限等待问题。理解并践行这些底层协作契约，是编写健壮并发程序的基石。
