Java中Condition超时等待本质是基于AQS的绝对时间点机制，将超时参数转为System.nanoTime() + nanosTimeout作为截止时刻，每次唤醒后重新计算剩余时间并决定是否继续等待或返回；中断优先于超时，虚假唤醒需循环重检条件。
Java 中 Condition 的超时等待（如 awaitNanos(long nanosTimeout)、await(long time, TimeUnit unit)）本质是基于 AQS（AbstractQueuedSynchronizer）的可中断、可超时的等待队列机制，其核心在于将线程挂起前记录“绝对截止时间”，并在被唤醒或中断时主动检查是否已超时。
超时时间被转换为纳秒级绝对时间点
Condition 不维护相对时长，而是将传入的超时参数（如 5 秒）立即转为系统纳秒时间戳（System.nanoTime() + nanosTimeout），作为该次等待的“到期时刻”。后续所有判断都围绕这个绝对时间点展开，避免因系统时钟漂移或多次重试导致误差累积。
- 例如调用
condition.await(5, TimeUnit.SECONDS)，内部会先计算deadline = System.nanoTime() + 5_000_000_000L - 每次从等待状态被唤醒（被 signal 或虚假唤醒），都会重新计算剩余纳秒数：
remaining = deadline - System.nanoTime() - 若
remaining ，直接返回 <code>false表示超时；否则继续等待
等待过程分阶段：进入条件队列 → 挂起 → 被唤醒后校验剩余时间
线程调用 await() 后，并非直接 park，而是先完成三步原子操作：释放锁 → 加入 Condition 等待队列 → 阻塞自身。超时逻辑介入在最后一步：
- 线程在
LockSupport.parkNanos(this, remaining)前，已确保remaining > 0 - park 可能因 signal、interrupt 或“虚假唤醒”提前返回，此时必须重新计算
remaining - 若仍 > 0，说明未超时，线程需重新尝试获取锁（转入 AQS 同步队列）；若 ≤ 0，则放弃竞争，直接返回
中断与超时共存时以中断优先
如果等待中发生中断，await() 会立即抛出 InterruptedException，不检查是否超时。而带超时的 await(long, TimeUnit) 在检测到中断时，也优先响应中断——即使剩余时间还很长，也会清中断状态并抛异常。
立即学习“Java免费学习笔记（深入）”；
- 中断标志位（
Thread.interrupted()）在进入等待前会被清除，防止干扰上层逻辑 - 超时返回
false是“安静失败”，不改变线程中断状态；中断则强制打断流程 - 二者语义不同：超时是业务层面的等待放弃，中断是外部控制指令
虚假唤醒后必须重检条件和超时
Condition 规范允许虚假唤醒（spurious wakeup），因此所有 await() 调用都应置于循环中。超时机制也依赖这一约定：
- 每次从 park 返回，都要重新计算剩余时间，再决定是继续等待还是退出
- 即使刚被唤醒，只要
remaining > 0，就说明还没到 deadline，应再次 park - 典型写法：
while (!conditionMet && await(...)) { /* 继续等 */ }
不复杂但容易忽略：超时不是定时器驱动，而是由每次唤醒后的主动校验驱动；它依赖高精度纳秒计时，且严格区分中断与超时语义。
