Condition.awaitNanos()需循环重算剩余纳秒数，返回值为剩余时间（≤0表示超时），受系统调度限制实际精度仅毫秒级，亚毫秒等待应改用忙等待。
Condition.awaitNanos() 本身就能提供纳秒级超时控制，但实际精度受 JVM 和操作系统调度限制，通常只能做到毫秒级响应；直接依赖它做“高精度”定时等待容易误判超时或过早唤醒。
awaitNanos() 的超时参数到底怎么算
传入的 nanosTimeout 是**剩余纳秒数**，不是绝对时间戳。每次被虚假唤醒（spurious wakeup）或中断后，必须用当前时间重新计算剩余值，否则会大幅缩短真实等待时间。
- 错误写法：
condition.awaitNanos(100_000_000)—— 一次调用完就结束，没考虑重试 - 正确思路：循环中用
System.nanoTime()动态更新剩余纳秒数，直到返回值 ≤ 0 或条件满足 - 注意：
awaitNanos()返回值是**剩余纳秒数**（可能为负），不是布尔值；返回 ≤ 0 表示超时，> 0 表示被 signal 唤醒且仍有剩余时间
为什么不能只靠 awaitNanos() 实现亚毫秒级等待
JVM 线程调度和 OS 内核的 timer tick 通常在 1–15ms 量级（Linux 默认 HZ=250 即 4ms tick），awaitNanos(100_000)（100μs）大概率会被截断或延迟到下一个 tick 边界才响应。
- 实测常见表现：请求 50μs 超时，实际返回耗时集中在 1–4ms
-
Thread.sleep(1)和awaitNanos(1_000_000)在低负载下行为接近，都受限于系统时钟分辨率 - 若真需微秒级响应（如高频交易、硬件同步），应避免阻塞等待，改用忙等待（busy-wait）+
System.nanoTime()自旋，但代价是 CPU 占用飙升
安全使用 awaitNanos() 的标准模式
必须配合循环、剩余时间重算、中断检查和条件重验，缺一不可。LockSupport.parkNanos() 更底层，但 Condition 封装了锁语义，更适合业务场景。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
long deadline = System.nanoTime() + TimeUnit.MILLISECONDS.toNanos(50);
while (!conditionMet()) {
long remaining = deadline - System.nanoTime();
if (remaining
- 务必在
while条件中调用conditionMet()（即检查业务条件），不能用if - 每次
awaitNanos()返回后都要重新计算remaining，不能复用初始值 - 捕获
InterruptedException后必须恢复中断状态，否则上层无法感知
和 Object.wait(long, int) 的关键区别在哪
Object.wait(long, int) 的纳秒参数只是毫秒的补充（最多 999999 纳秒），本质仍是毫秒级；而 Condition.awaitNanos(long) 接收的是纯纳秒值，语义更清晰，也便于与 System.nanoTime() 直接联动。
-
wait(1, 500000)≈ 等待 1.5ms，但无法表达 1500001ns 这种非整毫秒值 -
awaitNanos(1500001)明确表示 1.500001ms，虽然实际精度达不到，但语义无损 - Condition 方案可无缝对接
Lock.tryLock(long, TimeUnit)的超时逻辑，统一用纳秒计时
真正决定精度的从来不是 API 参数能写多细，而是你是否在循环里每次都用 System.nanoTime() 扣掉已流逝时间——漏掉这一步，纳秒参数就只是个心理安慰。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
