notify与notifyAll区别详解

本文深入剖析了Java中notify与notifyAll的核心区别与使用陷阱：notify仅随机唤醒一个等待线程，轻量但易引发漏唤醒、活锁甚至死锁；notifyAll则唤醒所有等待线程，虽带来轻微竞争开销，却能确保条件变化被充分响应，显著提升程序健壮性。文章强调二者必须在synchronized块中配合同一锁对象调用，且wait必须置于while循环中防范虚假唤醒——这些看似细微的细节，实则是避免并发bug的关键防线。无论你是调试诡异的线程假死，还是设计高可靠的生产者-消费者系统，理解并优先选用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并依赖循环判断来过滤。

性能与安全的权衡

notify开销小，适合高并发、低等待线程数、条件互斥明确的场景；notifyAll虽多唤醒几个线程，带来额外的锁竞争，但在多数实际业务中（如Web请求处理、消息队列消费），线程数量可控，这点开销远小于因漏唤醒导致的系统停滞。JDK官方文档也建议：除非你确切知道只有一个线程能从通知中受益，否则优先使用notifyAll。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。