notify只唤醒一个等待线程，notifyall唤醒所有；二者均需在synchronized中调用且锁对象一致；wait必须置于while循环中防虚假唤醒；notify适用于单线程处理场景，notifyall更安全，推荐优先使用。
notify只唤醒一个等待该对象锁的线程，而notifyAll唤醒所有在该对象上wait的线程。
唤醒范围不同
notify从等待队列中随机选择一个线程解除阻塞，其余线程继续等待；notifyAll则让所有处于wait状态的线程都进入锁竞争队列，重新参与锁获取。这决定了它们适用的场景差异：当多个线程等待同一条件、且条件满足后只需一个线程处理时（如线程池取任务），notify更轻量；当条件变化可能影响多个等待者（如生产者-消费者中多个消费者都在等数据）时，必须用notifyAll，否则可能遗漏唤醒，导致死锁或假死。
与wait配对使用的正确姿势
wait、notify、notifyAll都必须在synchronized同步块中调用，且锁对象要一致。常见错误是用不同对象调用wait和notify，或在非同步上下文中调用，会抛IllegalMonitorStateException。另外，wait应始终放在while循环中检查条件，而非if——因为即使被唤醒，条件也可能不成立（虚假唤醒或条件已被其他线程消耗），循环校验可确保安全性。
- ✅ 正确写法：while (!condition) { obj.wait(); }
- ❌ 错误写法：if (!condition) { obj.wait(); }
notify容易引发的隐蔽问题
notify的“随机性”不是问题本身，但若设计时未考虑等待线程的逻辑一致性，就容易出错。例如多个线程等待不同子条件（如“余额充足”和“库存足够”），共用一个锁和一个wait队列，仅用notify可能唤醒了不满足其自身条件的线程，它醒来后发现条件仍不满足，又调回wait——而真正需要唤醒的线程却一直没被选中，造成资源浪费甚至活锁。这种情况下，要么拆分锁对象，要么统一用notifyAll并依赖循环判断来过滤。
立即学习“Java免费学习笔记（深入）”；
性能与安全的权衡
notify开销小，适合高并发、低等待线程数、条件互斥明确的场景；notifyAll虽多唤醒几个线程，带来额外的锁竞争，但在多数实际业务中（如Web请求处理、消息队列消费），线程数量可控，这点开销远小于因漏唤醒导致的系统停滞。JDK官方文档也建议：除非你确切知道只有一个线程能从通知中受益，否则优先使用notifyAll。
