Java线程通信：wait与notify原理解析

本文深入剖析了Java中经典的线程通信机制wait与notify的核心原理与实践陷阱：它们必须在synchronized块中调用，否则抛出IllegalMonitorStateException；wait会释放锁并挂起线程，而notify仅标记唤醒、不释放锁；为防范虚假唤醒，必须用while循环而非if反复校验条件；notify随机唤醒单个线程，notifyAll则广播唤醒全部，选择不当易致死锁或性能浪费；更重要的是，原生方案存在对象绑定强、缺乏灵活性等局限，LockSupport和Condition才是现代并发编程中更安全、可控的替代选择——真正考验开发者的，从来不是语法调用，而是对线程状态、通知时机与协作契约的精准建模与严谨验证。

wait 和 notify 必须在 synchronized 块里调用

否则会抛出 IllegalMonitorStateException。这是因为 wait 和 notify 操作依赖当前线程是否持有对象的 monitor 锁——只有进入 synchronized 块（或方法）后，线程才真正“拥有”该锁，才能安全地释放（wait）或唤醒（notify）其他等待者。

常见错误写法：

obj.wait(); // ❌ 没有同步上下文

正确写法：

synchronized (obj) {
    obj.wait();
}

• wait() 会释放锁并挂起当前线程，直到被 notify() 或 notifyAll() 唤醒，或超时（如果带参数）
• notify() 不会立即释放锁，只是标记一个等待线程为“可唤醒”，它仍需等当前 synchronized 块退出后，被唤醒线程才能重新竞争锁
• 不要假设 notify() 一定唤醒“最久等待”的线程——JVM 不保证唤醒顺序，也不保证唤醒哪个

为什么 wait 要放在 while 循环里而不是 if

虚假唤醒（spurious wakeup）是真实存在的：线程可能在没有被 notify 的情况下自行醒来。如果不检查条件，就会跳过本该等待的状态，导致逻辑错误。

典型模式：

synchronized (lock) {
    while (!conditionMet) {
        lock.wait();
    }
    // 执行业务逻辑
}

• 用 while 而不是 if，确保每次醒来都重新校验条件
• 条件变量（如队列是否为空、资源是否就绪）必须是共享且 volatile 或受同一锁保护的，否则可能读到过期值
• notify() 后不重置条件？那被唤醒的线程一进循环就又 wait() 回去了——这是正常行为，不是 bug

notify 和 notifyAll 的选择取决于等待者语义

二者都只在 synchronized 块内有效，区别在于唤醒范围：

• notify() 随机唤醒**一个**在该对象上 wait 的线程；适合“点对点”场景，比如生产者-消费者中，一个产品入队后只需唤醒一个消费者
• notifyAll() 唤醒**所有**等待线程；适合“广播”场景，比如状态变更影响多个监听者（如关闭标志位、配置重载）
• 误用 notify() 可能导致死锁：若唤醒的线程发现条件不满足又回去 wait，而真正需要唤醒的线程一直没被选中
• 性能上 notifyAll() 开销略大，但现代 JVM 对空等待集做了优化，不必过度担心

wait/notify 无法跨对象协作，替代方案要考虑 LockSupport

wait 和 notify 是对象级别的，只能用于同一 Object 实例上的线程通信。如果你需要更灵活的控制（比如指定唤醒某个线程、支持中断、无锁等待），LockSupport 是底层更直接的选择。

• LockSupport.park() 和 unpark(Thread) 不要求锁，也不抛 IllegalMonitorStateException
• 但 park 不自动释放任何锁，需手动管理同步；也缺乏内置条件判断机制，容易写错唤醒时机
• java.util.concurrent 中的 Condition（配合 ReentrantLock）才是高级封装：它把“等待条件”和“唤醒策略”解耦，支持多个 Condition 实例对应同一锁，比原生 wait/notify 更安全可控

真正难的不是调用这两个方法，而是设计清楚谁负责通知、何时通知、被通知者是否一定能收到且不漏判——这些靠 API 本身不解决，得靠状态建模和边界测试来兜住。

本篇关于《Java线程通信：wait与notify原理解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！