notifyAll() 本身不避免信号丢失，关键在于用 while 循环检查条件、synchronized 块内先更新状态再 notifyAll、wait/notify 使用同一锁对象。
在 Java 中，notifyAll() 本身不会“避免信号丢失”，它只是确保所有在同一个对象监视器上 wait() 的线程都被唤醒；真正避免信号丢失的关键，在于正确配合 synchronized 块、使用 while 循环检查条件、以及确保 notify 逻辑与状态变更严格同步。
必须用 while 而不是 if 检查等待条件
这是防止虚假唤醒和信号丢失最核心的实践。即使被唤醒，线程也必须重新验证业务条件是否真正满足，因为：
-
wait()可能被系统中断或虚假唤醒（spurious wakeup） - 多个线程被
notifyAll()唤醒后，可能只有部分满足条件，其余应继续等待
✅ 正确写法：
synchronized (lock) {
while (!conditionMet()) { // 不是 if
lock.wait();
}
// 执行业务逻辑
}
notifyAll 必须在 synchronized 块内、且状态已更新之后调用
唤醒操作必须和共享状态的修改放在同一个同步块中，否则存在竞态：线程可能在状态还没改完时就执行了 wait，导致错过通知。
立即学习“Java免费学习笔记（深入）”；
✅ 正确顺序：
- 获取锁 → 修改共享状态（如设置 flag = true 或队列 add 元素）→ 调用
notifyAll()→ 释放锁 - 不能先 notify 再改状态，也不能在不同锁中分开操作
例如生产者向缓冲区添加元素后立即 notifyAll：
synchronized (buffer) {
buffer.add(item); // 状态已变更
buffer.notifyAll(); // 紧接着唤醒
}
确保 wait 和 notify 使用同一把锁对象
所有 wait()、notify()、notifyAll() 必须作用于同一个对象实例，否则线程永远收不到通知。
- 不要对 this、String 常量、或自动装箱的 Integer 等不可控对象调用 wait/notify
- 推荐显式声明私有 final 锁对象，避免被外部误用
✅ 推荐方式：
private final Object lock = new Object();
// 等待方
synchronized (lock) {
while (!ready) lock.wait();
}
// 通知方
synchronized (lock) {
ready = true;
lock.notifyAll();
}
避免 notifyAll 在无等待者时“白发”，但无需额外判断
有人担心“没线程在 wait 时调用 notifyAll 是浪费”，其实不必预防——JVM 对空等待集的 notifyAll 开销极小，且加判断反而引入竞态：
- 你判断“当前无人等待”后，另一个线程可能立刻进入 wait，而你的 notifyAll 已跳过
- 只要状态更新和 notifyAll 在同一同步块中，就不会丢信号
所以，只要状态满足唤醒条件，就放心调用 notifyAll()，无需前置检查等待线程数。
不复杂但容易忽略：信号是否丢失，取决于你有没有把状态变更、条件检查、等待/唤醒全部串在同一个锁的原子上下文中。notifyAll 是工具，严谨的协作逻辑才是关键。
