Object.notifyAll()必须在synchronized(obj)块内调用，否则抛IllegalMonitorStateException；需配合while循环重检条件以防虚假唤醒和信号丢失；多条件场景应改用Condition而非Object。
Object.notifyAll() 不能直接调用，必须在 synchronized 块内使用
Java 中 Object.notifyAll() 是实例方法，不是静态工具，也不能脱离锁上下文调用。常见错误是写成 obj.notifyAll() 却没对 obj 加锁，结果抛出 IllegalMonitorStateException。这看似是语法问题，实则暴露了根本误解：notifyAll 不是“发个信号就完事”，而是“唤醒所有正在该对象监视器上 wait 的线程”，前提是当前线程必须持有该对象的 monitor。
正确做法只有这一种：
synchronized (obj) {
obj.notifyAll();
}
漏掉 synchronized 或锁对象不一致（比如 wait 时锁的是 a，notify 时锁的是 b），都会导致唤醒失效或异常。
wait/notifyAll 必须配合 while 循环检查条件，不能用 if
信号丢失风险真正来源不是 notifyAll 本身，而是线程被唤醒后直接执行后续逻辑，却忽略了“唤醒不等于条件已满足”。比如多个线程 wait 在缓冲区非空条件上，生产者调用 notifyAll() 后，所有消费者被唤醒，但只有一个能取走元素，其余再执行就会触发空指针或非法状态。
必须用 while 而非 if 重检条件：
synchronized (queue) {
while (queue.isEmpty()) {
queue.wait();
}
// 此时 queue 一定非空
item = queue.poll();
}
- 虚假唤醒（spurious wakeup）可能发生，JVM 不保证 wait 只因 notify 才返回
- 多消费者竞争下，notifyAll 唤醒全部，但条件只被其中一个线程消费，其余必须继续 wait
- 用
if会导致线程跳过条件检查，直接操作空队列
notifyAll 不解决“谁该被唤醒”的业务逻辑问题
notifyAll() 是粗粒度唤醒，它把所有 wait 线程都推入锁竞争队列，但不区分它们等待的具体子条件。例如一个对象上同时有“数据就绪”和“配置加载完成”两种 wait，调用一次 notifyAll() 会唤醒全部，造成无谓竞争和 CPU 浪费。
这不是 bug，而是设计约束：
- Java 没有内置的条件变量（像
ReentrantLock.newCondition()那样），所以单个 Object 天然不支持多条件隔离 - 若需精确唤醒，应改用
java.util.concurrent.locks.Condition，每个条件独占一个Condition实例 - 强行用 Object 实现多条件，只能靠额外状态字段 + 更复杂的 while 条件判断，可读性和维护性陡降
性能开销：notifyAll 在大量等待线程时可能引发惊群效应
当数百个线程在同一个对象上 wait，notifyAll() 会让它们全部从阻塞态转为可运行态，争抢同一把锁。哪怕最终只有一个线程能进入临界区，其余线程仍要经历调度、锁竞争、再次 wait 的完整流程，带来明显上下文切换开销。
这不是理论风险，线上曾有案例：1000 个 worker 线程 wait 在一个共享锁上，每秒一次 notifyAll()，CPU sys 时间飙升至 40%+。缓解方式很实际：
- 优先考虑是否真的需要全部唤醒 —— 很多场景其实只需
notify()（比如生产者-消费者中每次只生成一个元素） - 拆分锁粒度：把大对象 wait 拆成多个小对象，让不同业务线程 wait 在不同实例上
- 改用并发集合（如
BlockingQueue）或Phaser/CountDownLatch等更高层同步工具，它们内部做了优化
最常被忽略的一点：notifyAll 解决不了条件竞态本身，它只是协作机制的一环；真正防止信号丢失，靠的是“wait 前检查条件 + wait 中循环重检 + notify 前更新条件并 notifyAll”这个闭环，缺一不可。
