Timed_Waiting 状态的线程由系统按调用方法自动唤醒：sleep纯时间驱动；wait需超时、notify或中断任一条件；park可被unpark、超时或中断唤醒；并发工具类封装二者语义；须用while循环验证条件，警惕虚假唤醒。

线程处于 Timed_Waiting 状态时，唤醒时机由它当初调用的阻塞方法及其参数决定，不是由外部“触发”，而是由系统在满足特定条件后自动恢复线程调度。

看线程阻塞时调用的是哪个方法

不同方法进入 Timed_Waiting 的逻辑不同，唤醒机制也不同：

• Thread.sleep(long millis)：纯时间驱动。线程会在指定毫秒数（或纳秒补正后）到期时自动唤醒，不依赖其他线程操作；即使被中断，也会提前抛出 InterruptedException 并退出该状态。
• Object.wait(long timeout)：双条件唤醒。满足任一条件即唤醒：
    – 超过 timeout 毫秒（计时到期）；
    – 其他线程在**同一对象上调用 notify() 或 notifyAll()**（且本线程被选中）；
    – 当前线程被中断（抛出异常）。
• LockSupport.parkNanos(long nanos) 或 parkUntil(long deadline)：类似 sleep，但可被 unpark() 提前唤醒。唤醒条件包括：
    – 时间到期；
    – 其他线程对本线程调用 LockSupport.unpark()；
    – 线程被中断。
• java.util.concurrent 工具类中的带超时方法（如 BlockingQueue.poll(timeout, unit)、Future.get(timeout, unit)）：底层通常封装了 parkNanos 或 wait，唤醒逻辑遵循其封装的语义——超时、条件满足（如队列有数据、任务完成）、中断三者之一即可唤醒。

通过线程堆栈确认具体等待目标

JVM 能准确反映线程当前阻塞点。使用 jstack 或 JVisualVM 查看线程栈，重点关注栈顶帧：

• 看到 java.lang.Thread.sleep(Native Method) → 是 sleep，只看时间。
• 看到 java.lang.Object.wait(long) → 是 wait，需结合锁对象和是否有 notify 发生来判断是否被信号唤醒。
• 看到 sun.misc.Unsafe.park(boolean, long) → 大概率是 parkNanos 或并发工具类，需查代码上下文确认是否可能被 unpark 或超时唤醒。

注意“虚假唤醒”与唤醒后的检查义务

尤其对 wait() 和 park() 类方法，JVM 不保证唤醒一定对应真实事件（例如 wait 可能无通知就返回）。因此：

• 必须在 while 循环中检查等待的条件是否真正成立，不能用 if；
• 不要假设唤醒 = 条件已满足，比如 queue.isEmpty() == false 必须重新验证；
• 超时唤醒也不代表操作成功，只是“等够了”，后续仍要处理失败路径（如返回 null、抛异常、重试等）。

调试建议：结合日志与监控

单纯靠状态判断不够，实际开发中可辅助以下手段：

• 在调用 wait/sleep/park 前打日志，记录预期超时值、等待条件、时间戳；
• 在唤醒后立刻记录实际耗时、唤醒原因（是否超时？是否收到 notify/unpark？是否中断？）；
• 用 java.lang.management.ThreadInfo.getWaitedTime()（需开启 VM 监控）获取累计等待时间，辅助分析是否频繁超时或异常延迟。