虚假唤醒是线程未被显式通知却从wait()返回的合法现象，须用while循环重检条件、synchronized同步块和notifyAll()组合防御，确保条件满足才执行业务逻辑。
虚假唤醒是指线程在没有被显式调用 notify() 或 notifyAll() 的情况下，从 wait() 中意外返回的现象。它不是 bug，而是 JVM 和操作系统允许的合法行为，必须在代码层面主动防御。
为什么会出现虚假唤醒
底层调度机制无法完全保证“只唤醒该通知的目标线程”。比如：
- 多核 CPU 上信号传递存在竞态，内核可能批量唤醒多个等待线程
- JVM 为优化性能，在某些中断、超时或系统资源抖动时提前恢复线程
- notifyAll() 唤醒全部等待者，但只有一个能抢到锁，其余线程醒来后发现条件仍不满足——这属于逻辑上的“假唤醒”
if 判断是最大陷阱
用 if 检查条件再 wait，一旦发生虚假唤醒，线程会直接跳过条件重检，继续执行后续逻辑，导致状态错乱。例如：
多个消费者同时 wait 在 num == 0 条件上，notifyAll() 后全部唤醒，但只有第一个抢到锁的能消费成功；其余线程若用 if，会误以为还有面可吃，接着执行 num--，造成负数。
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
标准解法：永远用 while 循环包裹 wait
每次被唤醒后，都重新判断条件是否真正成立，不成立就继续 wait：
synchronized(lock) {
while (!conditionMet) {
lock.wait();
}
// 安全执行业务逻辑
}
- 这是 JDK 官方文档明确推荐的写法（Object.wait() 注释里直接给出）
- 无论单生产者/单消费者，还是多对多场景，都必须遵守
- 配合 notifyAll() 使用更稳妥（notify() 可能漏唤醒）
配套关键点不能少
光用 while 不够，还需确保：
- 所有共享变量读写都在同步块内，避免可见性问题
- 修改条件后必须调用 notify()/notifyAll()，且要在同步块中
- 避免在循环体外做业务操作，防止条件变化后未重检就被执行
基本上就这些。不复杂但容易忽略，只要坚持 while + synchronized + notifyAll 组合，就能稳住生产者-消费者这类经典模型。
