wait和notify必须在synchronized块中调用，否则抛IllegalMonitorStateException；需用同一锁对象、while循环检测条件、volatile或锁保护条件变量，优先用notifyAll()，禁用sleep轮询。
wait 和 notify 必须在 synchronized 块中调用
直接调用 wait() 或 notify() 会抛出 IllegalMonitorStateException，因为这两个方法要求当前线程必须持有对象的监视器锁。JVM 不允许在未加锁状态下唤醒或挂起线程。
常见错误写法：
obj.wait(); // 抛异常：java.lang.IllegalMonitorStateException
正确写法要点：
- 必须用
synchronized(obj) { ... }包裹调用 - 不能用
synchronized(this)混淆锁对象——wait()和notify()的锁对象必须是同一个实例 - 推荐显式使用共享对象（如
private final Object lock = new Object();），避免锁粒度失控
wait 调用后要配合 while 循环判断条件
wait() 返回不等于“条件已满足”，它只表示被唤醒，可能是虚假唤醒（spurious wakeup）或其它线程误通知。跳过条件重检会导致逻辑错乱甚至死锁。
立即学习“Java免费学习笔记（深入）”；
错误示范（if 判断）：
synchronized (lock) {
if (!ready) {
lock.wait();
}
// 此处 ready 不一定为 true
}
正确写法（while 循环）：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
synchronized (lock) {
while (!ready) {
lock.wait();
}
// 此时 ready 一定为 true（假设其他线程只在设置 ready=true 后 notify）
}
关键点：
- 条件变量（如
ready）必须是volatile或由同一把锁保护，否则可能读到过期值 - 所有修改该条件的地方，都必须在
synchronized(lock)块内，并配对调用notify()或notifyAll()
notify 和 notifyAll 的选择取决于等待者是否等价
notify() 只唤醒一个等待线程，notifyAll() 唤醒所有。选错会导致线程饥饿或逻辑阻塞。
适用场景：
- 用
notify()：多个线程等待**同一条件**，且唤醒任意一个都能推进系统（例如线程池取任务） - 用
notifyAll()：等待线程关心**不同子条件**，或无法保证被唤醒者恰好满足其需求（例如生产者-消费者中，有多个消费者和多个生产者共用同一锁） - 绝大多数业务场景建议优先用
notifyAll()—— 它更安全，性能差异在现代 JVM 中可忽略
注意：notify() 不保证唤醒“最先 wait 的线程”，JVM 调度无序；也不保证唤醒后立即执行——它只是从等待队列移出，仍需重新竞争锁。
不要用 Thread.sleep 替代 wait/notify 实现线程协作
轮询 + Thread.sleep() 看似简单，但问题明显：
- 浪费 CPU（即使 sleep，唤醒时机不可控，常需保守设长间隔）
- 响应延迟高（比如 sleep(100ms)，条件就绪后最多再等 100ms 才发现）
- 无法实现精确的“某事件发生即响应”，只能近似“定期检查”
- 无法与锁机制协同，易引发竞态（如检查条件和后续操作之间被抢占）
真正需要等待某个状态变化时，wait/notify 是唯一能兼顾效率与准确性的原生方案。如果觉得难用，应考虑 java.util.concurrent 中更高阶的工具（如 BlockingQueue、CountDownLatch、Phaser），而不是退回到忙等。
最常被忽略的一点：wait/notify 的对象锁，和业务逻辑中用于保护共享变量的锁，必须是同一个对象——漏掉这点，整个协作机制就失效了。
