17370845950

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）或其它线程误通知。跳过条件重检会导致逻辑错乱甚至死锁。

错误示范（if 判断）：

synchronized (lock) {
    if (!ready) {
        lock.wait();
    }
    // 此处 ready 不一定为 true
}

正确写法（while 循环）：

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 的对象锁，和业务逻辑中用于保护共享变量的锁，必须是同一个对象——漏掉这点，整个协作机制就失效了。