notify只唤醒一个线程且不可控，易导致虚假唤醒或死锁；notifyAll唤醒所有等待线程并重检条件，更安全通用；实际开发中应优先使用java.util.concurrent工具类。
notify 只唤醒一个线程，但不保证唤醒谁
Java 中 notify() 会从等待队列（wait set）中随机选一个线程唤醒，具体选哪个由 JVM 实现决定，**无法预测、不可控**。这意味着：如果多个线程在等同一个条件，而你只调用 notify()，很可能唤醒的是那个条件仍不满足的线程——它醒来后检查条件失败，又调回 wait()，造成虚假唤醒循环或死锁风险。
常见错误现象：
- 程序卡住，部分线程永远不继续执行
- 并发逻辑正确但偶发失败，尤其在高负载或不同 JVM 版本下行为不一致
适用场景极少，仅当满足以下全部条件时才可考虑：
- 等待队列中**最多只有一个线程**在合理状态下等待（例如单生产者-单消费者且严格串行）
- 被唤醒线程**无需重新校验条件**（几乎不存在）
- 你完全掌控所有可能调用
wait()的路径，且能证明不会出现“唤醒错人”
notifyAll 是更安全、更通用的选择
notifyAll() 唤醒所有在该对象上等待的线程，让它们竞争锁并各自重新判断条件是否成立。虽然看起来“浪费”，但它消除了因唤醒顺序不确定导致的隐藏 bug。
立即学习“Java免费学习笔记（深入）”；
性能影响其实被高估了：
- 现代 JVM 对
notifyAll()做了优化，未获得锁的线程不会真正“运行”，只是从 wait set 移入 entry set - 真正开销来自后续的条件重判和可能的再次 wait，而这本来就是正确同步所必需的
- 相比死锁或活锁，这点开销几乎可以忽略
典型正确写法（守卫条件必须用 while 而非 if）：
synchronized (lock) {
while (!conditionMet) {
lock.wait();
}
// 处理逻辑
}
对应的通知端也应是：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
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<String> queue = new LinkedBlockingQueue<>(10);
// 生产者
queue.put("item"); // 自动阻塞，无需 wait/notify
// 消费者
String item = queue.take(); // 自动阻塞，无需 wait/notify
这些类内部确实用了 notifyAll() 或更精细的唤醒机制，但封装后你不再需要直面选择难题。
真正容易被忽略的点：即使你坚持用 wait/notify，也要始终配合 while 循环检查条件，并确保所有修改条件的代码都在同一把锁下完成——否则 notifyAll() 也救不了逻辑错误。
