Object.wait(long timeout) 本质是“最多等待 timeout 毫秒”，而非超时等待；必须用 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，因为每次唤醒后，要重新计算还剩多少毫秒可等。
实操建议：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 记录开始等待的绝对时间（
System.nanoTime()更准，避免currentTimeMillis()时钟回拨问题） - 每次进入
wait()前，计算已过去时间，得出剩余remainingNanos，再转成毫秒和纳秒参数传给wait(long, int) - 退出循环后，必须再次检查条件是否真正满足，不能只依赖超时与否
示例片段（简化版）：
wait()
- 单一条件、一对一唤醒（如生产者-消费者模型中一个空槽位只唤醒一个消费者）→ 可用
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）。否则即使等对了时间，也看不到最新值。
