Wait/Notify+While实现线程安全协作

本文深入剖析了Java中Wait/Notify机制实现线程安全协作的核心原则：必须使用while循环而非if语句进行条件检查，以应对虚假唤醒、唤醒延迟、状态被其他线程篡改等并发风险；通过生产者-消费者这一典型场景，系统揭示了notifyAll()的必要性、锁一致性要求及常见致命错误（如notify写在同步块外、多锁错配、状态检查与wait不同步），并指出这些错误往往导致难以复现的卡死、数据丢失或高CPU空转；最后强调，尽管java.util.concurrent提供了更安全的高级抽象，但深刻理解while+wait/notify背后“状态验证与等待必须原子化”的本质约束，才是写出可维护、可测试并发代码的关键所在。

为什么不能用 if 而必须用 while 检查条件

因为 notify() 只唤醒一个线程，但无法保证被唤醒的线程立刻获得锁；更关键的是，wait() 返回后，条件可能已被其他线程再次修改。用 if 会导致“虚假唤醒”（spurious wakeup）或竞态丢失——线程醒来直接执行后续逻辑，而此时条件其实不成立。

正确做法是始终用 while 循环包裹 wait()，每次唤醒后重新验证状态：

synchronized (lock) {
    while (!conditionMet()) {
        lock.wait();
    }
    // 此时 conditionMet() 一定为 true
}

• conditionMet() 必须是可重入、无副作用的纯状态判断（例如 queue.isEmpty()）
• 不要在循环体内做状态变更操作，否则可能死锁或跳过唤醒
• JVM 和操作系统都允许虚假唤醒，这不是 bug，而是设计契约

Wait/Notify 配合 while 的典型协作模式：生产者-消费者

这是最常出错的场景。错误写法常把 notifyAll() 放在同步块外，或漏掉对空队列/满队列的双重检查。

健壮实现的关键点：

// 生产者
synchronized (queue) {
    while (queue.size() == MAX_SIZE) {
        queue.wait();
    }
    queue.add(item);
    queue.notifyAll(); // 用 notifyAll()，避免信号丢失
}

// 消费者
synchronized (queue) {
    while (queue.isEmpty()) {
        queue.wait();
    }
    item = queue.remove();
    queue.notifyAll();
}

• 必须用 notifyAll()：若只用 notify()，多个等待线程中可能唤醒了错误类型（比如唤醒另一个消费者而非生产者），导致永久阻塞
• 所有共享状态读写（size()、isEmpty()、add()、remove()）必须在同一个锁下完成
• 不要假设“我刚 notify 就一定有线程醒”，唤醒和调度存在延迟，状态可能再次变化

常见错误现象与调试线索

遇到线程卡死、CPU 占用高但无进展、偶尔丢数据，大概率是 Wait/Notify 使用不当。

典型错误模式：

• 在 wait() 前没加 while，只用 if → 表现为偶发逻辑错乱，难复现
• notify() / notifyAll() 写在同步块外 → 抛 IllegalMonitorStateException
• 用了不同对象做锁（如生产者锁 queue，消费者锁 this）→ 完全无法通信
• 状态检查和 wait 不在同一个同步块内 → 出现竞态：检查完条件为 true，但 wait 前条件被改回 false

调试时优先检查：所有 wait() 是否都在 while 中？所有 notifyX() 是否在对应锁的同步块内？所有状态访问是否被同一把锁保护？

替代方案与现实取舍

原生 wait()/notify() 易错，Java 并发包提供了更安全的抽象，但理解底层机制仍必要。

实际项目中建议：

• 新代码优先使用 java.util.concurrent 工具类（如 BlockingQueue、Condition）——它们内部已正确封装了 while + wait/notify
• 维护老代码时，若看到裸 wait()，第一反应不是“它可能有问题”，而是“它几乎肯定有问题”，重点审查循环条件和锁粒度
• Condition 比原生 wait() 更清晰（可命名等待队列、支持多条件），但本质仍是 while + await()/signal()，逻辑不变

真正容易被忽略的，不是语法细节，而是“状态检查必须和 wait 在同一原子上下文中完成”这一约束——它迫使你把业务逻辑和线程协作逻辑耦合在同一个 synchronized 块里，而这恰恰是最难做单元测试和重构的部分。

理论要掌握，实操不能落！以上关于《Wait/Notify+While实现线程安全协作》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！