locksupport.parknanos无法提供纳秒级精度，仅保证“至少等待”指定时长，实际唤醒受linux内核hz配置（1–15ms粒度）、cpu负载及调度延迟影响，p99偏差常超1.2ms。
LockSupport.parkNanos 不能提供纳秒级挂起精度——它接受纳秒参数，但实际唤醒时间完全由操作系统底层时钟机制决定，Java 层无权干预或补偿。
Linux 内核时钟粒度是硬限制
主流 Linux 发行版默认使用 CONFIG_HZ=250 或 1000 的内核配置，对应调度周期为 4ms 或 1ms。即使调用 parkNanos(1000)（1 微秒），内核也必须对齐到下一个 tick 边界，常见表现是：立刻返回、阻塞约 1ms、或延迟至 2–15ms 不等。实测中，P99 唤醒偏差在普通服务器上常超 1.2ms，与“纳秒”毫无关系。
- clock_nanosleep(CLOCK_MONOTONIC, ...) 是 JVM 底层最终调用的系统调用，其最小分辨率受 HZ 和 timer slack 影响
- 启用 NO_HZ_FULL（全动态滴答）可改善，但需内核 ≥ 3.10 且严格配置 CPU 隔离、禁用 CFS 带宽控制
- 未隔离 CPU 或存在突发负载时，调度延迟可能叠加中断延迟、TLB miss、频率缩放等额外抖动
JVM 不做精度增强，只做语义封装
JVM 对 parkNanos 的处理是直通式封装：将纳秒值向下取整或对齐后交由 OS 处理，不插值、不轮询、不忙等。它遵守 Java 规范中“至少等待指定时长”的语义，而非“精确等待”。传入负数直接返回；传入 0 等价于 park()；小于 100_000（100 微秒）的值在多数场景下被忽略或截断为 0。
- Unsafe.park(false, nanos) 是最终入口，JVM 不维护高精度定时器线程，也不启动辅助计时逻辑
- 不同 JVM 实现（HotSpot / OpenJ9 / GraalVM）在 nanos 参数截断策略上略有差异，但都不突破 OS 层限制
- Windows 平台基于 WaitForSingleObject，超时行为更保守，短时 park 更易被拉长
虚假唤醒与中断响应进一步削弱可控性
parkNanos 可能因系统信号、调度器抢占、甚至 JVM 内部 GC 暂停而提前返回（虚假唤醒），也可能因中断状态已置位而几乎不休眠。它不抛 InterruptedException，仅通过 Thread.interrupted() 返回 false 来间接反映中断发生，开发者必须主动检查并退出循环，否则会陷入不可预测的等待状态。
- unpark 提前调用会导致许可“透支”，parkNanos 可能瞬间返回，使预期休眠完全失效
- Thread.getState() 显示 TIMED_WAITING，但实际挂起时长无法从该状态反推
- 高频调用短 parkNanos（如循环中 parkNanos(1)）会引发大量上下文切换和时钟中断，CPU 使用率飙升且精度更差
真正需要亚毫秒调度时该怎么做
若业务场景确实要求确定性延迟（如车载 CAN 周期采样、金融行情快照、音频帧同步），应绕过 parkNanos，转向系统级协同方案：
- 用 JNI 调用 clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts)，跳过 JVM 封装层
- 将关键线程绑定到隔离 CPU 核（echo 0-1 > /sys/devices/system/cpu/isolated），并设为 SCHED_FIFO 最高优先级
- 采用“粗调 + 忙等”混合策略：先 parkNanos 到距目标时间约 50–100μs 处，再用 System.nanoTime() 自旋微调
- 避免依赖任何 Java 层 sleep/park 做 deadline 控制，改用硬件定时器或 RTOS 协同
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
