notifyAll()仅将等待线程移入锁竞争队列，不直接执行；线程需重新竞争锁，且wait必须用while循环检查条件，配合同一volatile或同步保护的条件变量，并在synchronized块中对同一对象调用。
notifyAll 为什么不能直接“唤醒并执行”
notifyAll 的作用只是把所有在该对象上调用 wait() 而进入等待集（wait set）的线程，从等待状态移到**锁竞争队列**，而不是直接让它们继续执行。这些线程仍需重新竞争对象监视器（即 synchronized 锁），只有抢到锁的线程才能真正往下走；没抢到的会阻塞在 entry set，等锁释放后再次尝试。
常见误解是调用 notifyAll() 后所有线程立刻并发执行 —— 实际上它们仍被同步块/方法串行化约束，除非你显式设计成无锁或使用其他并发工具。
必须配合 while 循环检查条件，不能用 if
被 notifyAll() 唤醒的线程可能面临“虚假唤醒”（spurious wakeup），也可能因竞争失败而延迟获得锁，导致共享条件早已被其他线程修改。所以 wait() 必须放在 while 循环里，每次醒来都重新验证业务条件是否满足。
错误写法：
if (count == 0) { wait(); }
正确写法：while (count == 0) { wait(); }
- 用
if可能跳过条件检查，直接执行后续逻辑，引发IllegalStateException或数据错乱 - 即使只唤醒一个线程（
notify()），也推荐用while；notifyAll()场景下更是强制要求 - 条件变量（如
count）必须是volatile或受同一锁保护，否则可见性无法保证
notifyAll 必须在 synchronized 块内调用，且锁对象要一致
notifyAll() 是 Object 的 final 方法，但它的语义依赖于当前线程持有该对象的监视器。如果不在 synchronized(obj) 块中调用，会抛出 IllegalMonitorStateException。
典型错误：
synchronized(otherObj) {
// 错误：this 和 otherObj 不是同一个锁
this.notifyAll(); // 抛异常
}
正确做法：
synchronized (sharedLock) {
count++;
sharedLock.notifyAll(); // 必须和 wait() 使用同一个对象
}
- wait / notifyAll 必须在同一个对象上配对使用，否则线程永远等不到唤醒
- 避免用
this作锁（易被外部误操作），优先用私有 final 对象，例如private final Object lock = new Object(); - 不要在循环体内部反复新建锁对象，会导致 notifyAll 失效
notifyAll 的实际适用场景和替代建议
notifyAll() 真正必要的场景其实不多：比如多个消费者等待不同类型的资源就绪、或生产者更新了多个条件变量、又或者你无法精确判断哪些线程该被唤醒（例如使用单一条件队列管理多种等待逻辑）。
多数情况下，更推荐：
- 用
java.util.concurrent包下的高级工具，如Condition（可绑定多个等待队列）、BlockingQueue、Semaphore，它们语义清晰、不易出错 - 若仅需唤醒一个等待者（如经典生产者-消费者单槽模型），
notify()更轻量，减少无谓竞争 - 高并发下频繁
notifyAll()可能引发“惊群效应”，大量线程争锁失败再挂起，徒增上下文切换开销
真正需要 notifyAll() 时，记得它不解决竞态，只负责“通知+重入竞争”，所有同步逻辑、条件检查、锁粒度控制，还得靠你自己兜底。
