notify与notifyAll如何选择｜Java线程唤醒指南

在Java多线程编程中，`notify()`因随机唤醒单一线程而极易引发虚假唤醒、死锁或偶发性并发错误，实际安全可用的场景几乎不存在；相比之下，`notifyAll()`虽看似“激进”，却通过唤醒所有等待线程并强制条件重检，从根本上规避了不可控唤醒带来的隐患，是更可靠、更通用的选择——但真正推荐的做法是彻底摒弃底层`wait/notify`，转而采用`java.util.concurrent`包中语义清晰、封装完善的高级同步工具（如`BlockingQueue`、`Condition`、`CountDownLatch`等），既大幅提升代码健壮性与可维护性，又避免陷入唤醒机制的细节陷阱。

notify 只唤醒一个线程，但不保证唤醒谁

Java 中 notify() 会从等待队列（wait set）中随机选一个线程唤醒，具体选哪个由 JVM 实现决定，**无法预测、不可控**。这意味着：如果多个线程在等同一个条件，而你只调用 notify()，很可能唤醒的是那个条件仍不满足的线程——它醒来后检查条件失败，又调回 wait()，造成虚假唤醒循环或死锁风险。

常见错误现象：

• 程序卡住，部分线程永远不继续执行
• 并发逻辑正确但偶发失败，尤其在高负载或不同 JVM 版本下行为不一致

适用场景极少，仅当满足以下全部条件时才可考虑：

• 等待队列中**最多只有一个线程**在合理状态下等待（例如单生产者-单消费者且严格串行）
• 被唤醒线程**无需重新校验条件**（几乎不存在）
• 你完全掌控所有可能调用 wait() 的路径，且能证明不会出现“唤醒错人”

notifyAll 是更安全、更通用的选择

notifyAll() 唤醒所有在该对象上等待的线程，让它们竞争锁并各自重新判断条件是否成立。虽然看起来“浪费”，但它消除了因唤醒顺序不确定导致的隐藏 bug。

性能影响其实被高估了：

• 现代 JVM 对 notifyAll() 做了优化，未获得锁的线程不会真正“运行”，只是从 wait set 移入 entry set
• 真正开销来自后续的条件重判和可能的再次 wait，而这本来就是正确同步所必需的
• 相比死锁或活锁，这点开销几乎可以忽略

典型正确写法（守卫条件必须用 while 而非 if）：

synchronized (lock) {
    while (!conditionMet) {
        lock.wait();
    }
    // 处理逻辑
}

对应的通知端也应是：

synchronized (lock) {
    conditionMet = true;
    lock.notifyAll(); // 不是 notify()
}

什么时候真该用 notify？几乎没有

文档和教科书常提“notify 用于已知只有一个线程在等”，但现实中这个“已知”极难保证。比如：

• 线程池中复用线程，旧 wait 状态可能残留
• 异常分支没清理等待状态，导致多个线程意外进入 wait
• 子类重写了 wait 相关逻辑，扩大了等待范围

就连 JDK 自身的 java.util.concurrent 包里，也基本不用 notify() —— ArrayBlockingQueue、LinkedBlockingQueue 全部使用 notifyAll()。

唯一勉强算合规的场景：你写了一个私有、封闭、无继承、无异常穿透的工具类，且单元测试穷举了所有线程调度组合，确认永远只有一个线程在 wait。即便如此，换成 notifyAll() 也不影响功能，还更易维护。

替代方案：优先用 java.util.concurrent 工具类

手写 wait/notify 容易出错，JDK 提供了更高层次的抽象：

• 用 Condition 配合 ReentrantLock，支持多条件队列，比 Object.wait 更清晰
• 用 CountDownLatch、CyclicBarrier、Semaphore 表达明确的同步意图
• 用 BlockingQueue 替代手动实现生产者-消费者等待逻辑

例如，替换传统 wait/notify 的阻塞队列操作：

BlockingQueue queue = new LinkedBlockingQueue(10);
// 生产者
queue.put("item"); // 自动阻塞，无需 wait/notify
// 消费者
String item = queue.take(); // 自动阻塞，无需 wait/notify

这些类内部确实用了 notifyAll() 或更精细的唤醒机制，但封装后你不再需要直面选择难题。

真正容易被忽略的点：即使你坚持用 wait/notify，也要始终配合 while 循环检查条件，并确保所有修改条件的代码都在同一把锁下完成——否则 notifyAll() 也救不了逻辑错误。

好了，本文到此结束，带大家了解了《notify与notifyAll如何选择｜Java线程唤醒指南》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！