locksupport.parknanos 不提供纳秒级精度，仅接受纳秒参数，实际受操作系统时钟粒度限制（如 linux 为1–15ms），只能保证“至少等待”，无法保证“恰好等待”，且不响应中断异常但会提前返回。
LockSupport.parkNanos 不能真正提供“纳秒级精度”的阻塞，它只接受纳秒单位的参数，但底层调度受操作系统时钟粒度限制（Linux 通常为 1–15ms），实际唤醒时间可能显著延迟。
为什么 parkNanos(long nanos) 的纳秒参数不等于纳秒精度
调用 LockSupport.parkNanos(1000) 并不意味着线程会精确休眠 1 微秒——它只是把纳秒值传给 JVM 底层的 Unsafe.park(false, nanos)，最终交由 OS 线程调度器处理。而大多数通用操作系统（如 Linux）的定时器分辨率在毫秒级，parkNanos 只能保证「至少等待」该时长，无法保证「恰好等待」。
- 实测中，
parkNanos(1000)（1 微秒）常被拉长到 1–2ms 甚至更久 - 小于 100000（100 微秒）的值基本等效于无等待，线程可能立即返回
- JVM 不做额外插值或轮询补偿，也不保证单调性或实时性
在自定义调度器中安全使用 parkNanos 的关键约束
如果你正在写一个轻量级任务调度器（比如基于时间轮或延迟队列的线程池），parkNanos 适合作为“主循环休眠”手段，但必须配合时间校准逻辑，不能直接用于 deadline 敏感的单次调度。
- 永远用
System.nanoTime()计算剩余等待时间，而不是固定值：先算出下次任务到期的绝对时间，再减去当前时间得到nanosRemaining - 每次
parkNanos(nanosRemaining)返回后，必须重新检查是否已到执行点——因为虚假唤醒、中断或系统延迟都可能导致提前返回 - 若
nanosRemaining ，跳过 park，直接执行；若 <code>nanosRemaining > 1_000_000（即 1ms），才值得 park；太小的值建议直接 yield 或短 sleep - 务必捕获
Thread.interrupted()状态，避免中断丢失：parkNanos 不抛InterruptedException，但会响应中断并提前返回
常见误用：把 parkNanos 当作高精度 sleep 替代品
有人试图用 parkNanos(500_000) 实现 0.5ms 定时采样，结果发现线程频繁“飘移”甚至卡死——这不是 bug，而是设计使然。它不是为微秒级周期任务设计的。
-
Thread.sleep(1)和parkNanos(1_000_000)在行为上接近，但前者语义明确（放弃 CPU）、后者更底层（依赖 permit） - 不要在循环里反复调用
parkNanos(1)做 busy-wait 补偿——这既浪费 CPU，又因上下文切换开销反而更不准 - 如果真需要 sub-millisecond 调度（如金融交易、音频同步），应考虑 real-time JVM、内核 bypass（e.g., DPDK）、或硬件 timer + signal handler 方案
真正容易被忽略的是：parkNanos 的“纳秒”只是接口单位，不是能力承诺。它的价值在于与 unpark 配合实现无锁协作，而非计时精度。在调度器中，它只是休眠工具，不是时钟源。
