notify 随机唤醒一个等待线程，无法指定目标，易导致生产者消费者等角色错乱；仅适用于单一线程等待或角色完全等价场景，且需用 while 重检条件；notifyAll 虽唤醒所有线程但实际开销可控，是安全兜底选择。
notify 会随机唤醒一个等待线程，但不保证是你要的那个
当多个线程在同一个 Object 上调用 wait()（比如共享队列、生产者消费者共用同一把锁），notify() 只唤醒其中一个——JVM 自由选择，无法控制。如果你的业务逻辑依赖“唤醒特定类型线程”（例如只该唤醒消费者，结果唤醒了另一个生产者），就会卡死或逻辑错乱。
常见错误现象：IllegalMonitorStateException 不常出现，但更隐蔽的是“程序看似运行却不再推进”，比如生产者发了信号，消费者没醒，而另一个本不该响应的线程醒了又立刻 wait() 回去。
- 仅适用于：明确知道只有一个线程在等，或多个线程行为完全等价（如线程池中任意空闲 worker 都能处理任务）
- 不能用于：有不同角色/状态的等待者（如生产者 vs 消费者、读线程 vs 写线程）
- 注意：即使你写了
if (condition) wait();，被唤醒后也必须用while重检条件，因为存在虚假唤醒
notifyAll 是安全兜底，但不是性能杀手
很多人怕 notifyAll() 效率低，觉得“唤醒所有线程再竞争锁太浪费”。实际上，在绝大多数实际场景中，等待线程数很少（notifyAll() 做了优化（如 Linux 下使用 futex，不会真让全部线程走完整调度流程）。真正影响性能的是锁竞争本身，而不是唤醒动作。
使用场景：只要等待者角色不同、条件复杂、或你不确定有多少线程在等，就该无脑选 notifyAll()。
立即学习“Java免费学习笔记（深入）”；
- 必须用
notifyAll()的典型例子：读写锁实现、有界阻塞队列（ArrayBlockingQueue内部就用它）、状态机驱动的协作线程 - 参数上无差异——它不需要传任何参数，就是对当前对象监视器上的所有等待线程广播
- 副作用：所有被唤醒线程会重新进入锁竞争队列，但只有拿到锁的那个能继续执行；其余再次阻塞（不是立刻回到 wait set）
别忘了 while + wait 的固定写法
wait() 前的条件检查和唤醒后的重检，不是可选项。用 if 就可能跳过条件变化，导致线程在不满足条件时继续执行。
synchronized (lock) {
while (!ready) { // 必须用 while，不是 if
lock.wait();
}
// 处理逻辑
}
这个模式和 notify()/notifyAll() 选择强相关：哪怕你用了 notifyAll()，如果里面是 if，仍可能漏判；反过来，就算你误用了 notify()，while 至少能防止直接出错。
- 虚假唤醒（spurious wakeup）是 JVM 规范允许的，不依赖操作系统信号也能发生
- 条件变量应始终是 volatile 或被 synchronized 保护，避免可见性问题
- 不要在循环里做耗时操作，否则会拖慢整个等待队列的响应
现代 Java 更推荐 Condition + Lock 替代 wait/notify
原生 wait/notify 绑死在 Object 上，无法区分不同等待条件（比如“队列非空”和“队列未满”只能共用一个锁对象）。而 ReentrantLock.newCondition() 允许为每种逻辑建独立 Condition，配合 signal()/signalAll() 精准唤醒。
示例：ArrayBlockingQueue 内部就用了两个 Condition：一个叫 notEmpty，一个叫 notFull，生产者只 signal(notEmpty)，消费者只 signal(notFull)，彻底避免误唤醒。
-
signal()≈notify()，signalAll()≈notifyAll()，但语义更清晰、可读性更强 - 必须搭配
Lock使用，不能和synchronized混用 - 忘记
unlock()会导致死锁，比synchronized更容易出错——所以建议用 try-finally 或 try-with-resources（配合Lock的封装工具类）
