wait方法不返回唤醒原因，需用while循环+时间戳+条件变量判断是否真超时；每次唤醒后须重新检查守卫条件，并计算剩余等待时间决定继续等待或超时处理。
Java 中 wait 方法本身不返回状态，也无法直接区分是被 notify 唤醒还是超时唤醒。所以在业务超时场景中，不能依赖 wait 的返回值做判断，而必须结合外部条件变量 + 时间戳计算，主动判断是否真正超时。
核心逻辑：用循环 + 时间差判定真实超时
调用 wait(timeout) 后，线程可能因三种原因返回：被 notify/notifyAll 唤醒、被中断、或自然超时。JVM 不提供区分机制，因此业务层需自行维护“等待前提是否成立”这一条件，并在每次唤醒后重新检查。
- 始终在
synchronized块内使用while循环判断守卫条件（如队列非空、任务完成标志为 true） - 进入等待前记录起始时间，每次
wait返回后计算已耗时 - 若剩余等待时间 ≤ 0，说明已超时，跳出循环并执行超时分支
- 若守卫条件满足，说明是正常唤醒，可继续后续逻辑
典型业务场景：带超时的资源获取
例如消费者从共享队列取数据，最多等 3 秒。即使 wait(3000) 返回，也不能直接认为有数据——必须再次检查 queue.isEmpty()：
synchronized (queue) {
long start = System.currentTimeMillis();
long timeout = 3000;
while (queue.isEmpty()) {
long elapsed = System.currentTimeMillis() - start;
long remaining = timeout - elapsed;
if (remaining <h3>避免常见陷阱</h3><p>很多开发者误以为 <code>wait(1000)</code> 返回就代表“等了 1 秒”，其实它可能 10 毫秒后就被 <code>notify</code> 唤醒——这属于正常协作，不是超时。关键在于：业务是否达成预期目标。</p>
- 不要用
try-catch InterruptedException当作超时信号（中断和超时是两回事） - 不要在
if中调用wait，必须用while防止虚假唤醒 - 不要传固定超时值反复调用
wait，应递减剩余时间，否则可能总等待时长远超预期 - 守卫条件必须是 volatile 或受同一锁保护的变量，确保可见性
更现代的替代方案
对于复杂业务超时控制，wait/notify 易出错且难以调试。推荐优先考虑：
-
java.util.concurrent工具类：如BlockingQueue.poll(timeout, unit)、CountDownLatch.await(timeout, unit) -
Future.get(timeout, unit)配合ExecutorService执行异步任务 - 使用
LockSupport.parkNanos()+ 自定义状态机（适合高性能场景）
这些 API 均明确返回布尔值或抛出 TimeoutException，语义清晰，不易出错。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
