Java线程等待方法详解与应用

Java中Object.wait(long timeout)并非“超时等待”而是“最多等待指定时长”，其核心在于线程可能因notify、虚假唤醒或中断提前返回，因此必须配合while循环反复验证条件，并手动计算剩余等待时间以确保总等待不超过预期上限——忽视这一点极易导致逻辑错误、死锁或响应延迟，掌握其精确用法是编写健壮多线程协作代码的关键。

wait(long timeout) 的本质不是“超时等待”，而是“最多等这么久”

很多人误以为 Object.wait(long timeout) 是个带超时的“阻塞式等待”，其实它只是在锁对象上挂起当前线程，最多等 timeout 毫秒——但在这期间，只要别的线程调用 notify() 或 notifyAll()，它就会立刻被唤醒，哪怕只过了 1ms。也就是说，它不保证一定等到超时，也不保证一定等到条件成立。

所以想靠它“等某个条件达成，但最多等 5 秒”，必须配合循环检查 + 超时判断，否则极易出现虚假唤醒或过早返回。

常见错误现象：

• 只调一次 wait(5000) 就继续执行后续逻辑，结果条件根本没变，程序出错
• 把 timeout 当成“等待完成的截止时间”，忽略了系统时钟漂移和唤醒延迟，导致实际等待偏长
• 没在 synchronized 块里调用，抛出 IllegalMonitorStateException

正确写法：必须用 while 循环包裹 wait()，并手动管理剩余等待时间

Java 官方文档明确要求：永远在 while 循环中调用 wait()，因为存在虚假唤醒（spurious wakeup）——JVM 可能在没有任何 notify 的情况下唤醒线程。

如果还要支持“总等待不超过 N 毫秒”，就得自己算剩余时间。不能直接传入原始 timeout，因为每次唤醒后，要重新计算还剩多少毫秒可等。

实操建议：

• 记录开始等待的绝对时间（System.nanoTime() 更准，避免 currentTimeMillis() 时钟回拨问题）
• 每次进入 wait() 前，计算已过去时间，得出剩余 remainingNanos，再转成毫秒和纳秒参数传给 wait(long, int)
• 退出循环后，必须再次检查条件是否真正满足，不能只依赖超时与否

示例片段（简化版）：

synchronized (lock) {
    long deadline = System.nanoTime() + TimeUnit.SECONDS.toNanos(5);
    while (!conditionMet()) {
        long remainingNanos = deadline - System.nanoTime();
        if (remainingNanos <h3>notify() 和 notifyAll() 的选择直接影响协同逻辑可靠性</h3><p>多个线程在同一个锁对象上 <code>wait()</code>，你用 <code>notify()</code> 还是 <code>notifyAll()</code>，决定了能否正确唤醒“该醒的那个”。</p><p>如果你的协同逻辑里，不同线程等待的是不同条件（比如 A 等待 flag==1，B 等待 flag==2），那用 <code>notify()</code> 极可能唤醒错人，导致某线程永远卡住；而 <code>notifyAll()</code> 虽然开销略大，但能确保所有等待者都有机会重新检查自己的条件。</p><p>使用场景判断：</p>

• 单一条件、一对一唤醒（如生产者-消费者模型中一个空槽位只唤醒一个消费者）→ 可用 notify()
• 多条件、一对多、或条件之间有依赖 → 必须用 notifyAll()
• 不确定未来是否扩展逻辑 → 默认选 notifyAll()，省去后期排查唤醒遗漏的麻烦

比 wait/notify 更稳的选择：Condition.awaitNanos(long)

如果你用的是 ReentrantLock，强烈建议换成 Condition。它的 awaitNanos(long) 返回值是“剩余等待时间”，可直接用于下一轮循环，比手算 System.nanoTime() 更可靠，且天然规避了 wait() 在中断时不清除中断状态的问题。

关键差异：

• Object.wait() 中断会抛 InterruptedException，但不会自动恢复中断状态
• Condition.awaitNanos() 中断时返回负数，且线程中断状态会被保留，更利于上层统一处理
• Condition 支持多个等待队列，不同条件可绑定不同 Condition，彻底解耦

不过要注意：Condition 不是银弹——它依赖 ReentrantLock，意味着你要主动管理锁的获取与释放，不能像 synchronized 那样隐式保障。

真正容易被忽略的点是：无论用哪种方式，「条件变量的修改」必须和「notify/await」发生在同一把锁的保护下，且修改操作本身不能被重排序（必要时加 volatile 或使用 AtomicBoolean）。否则即使等对了时间，也看不到最新值。

今天关于《Java线程等待方法详解与应用》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！