LockSupport.parkNanos 是响应式阻塞原语，非纳秒级定时器；它最多等待指定纳秒数，但受系统调度限制，精度远低于纳秒，且可被 unpark 提前唤醒，不响应中断。
LockSupport.parkNanos 并不用于“精准到纳秒级别的线程休眠挂起”，它本质是线程阻塞原语，不是高精度定时器，也不能替代 Thread.sleep 或 TimeUnit.NANOSECONDS.sleep 的语义。
parkNanos 的真实用途：响应式阻塞，不是定时休眠
它让当前线程在指定纳秒数内“等待被唤醒”，但实际阻塞时长受 JVM 实现、操作系统调度器和硬件时钟精度限制，无法保证纳秒级精度。Linux 下通常最小调度粒度是 1–10 毫秒（取决于内核配置），JVM 对 parkNanos 的实现也常向下取整或直接忽略极小值（如小于 1000 纳秒可能立即返回）。
- 调用 parkNanos(1000) 不代表线程一定停 1 微秒，很可能是“几乎不阻塞”或直接返回
- 它只在没有被其他线程 unpark 前，最多等待指定时间；一旦被 unpark，立刻唤醒，不管是否到期
- 它不抛出 InterruptedException，也不响应中断标志 —— 这与 sleep 有根本区别
多线程协作中正确使用 parkNanos 的典型场景
它适合做“轻量级、非公平、无锁协作”的阻塞点，比如自旋 + park 的混合等待策略：
- 先自旋若干次（检查共享状态），避免上下文切换开销
- 自旋失败后调用 parkNanos(短时长)，短暂让出 CPU，同时保持对 unpark 的响应能力
- 被 unpark 后立即恢复执行，无需处理中断异常，逻辑更简洁
例如，在一个简单的无锁队列消费者中：
立即学习“Java免费学习笔记（深入）”；
while (!queue.isEmpty() || !shutdown) {
Node node = queue.poll();
if (node != null) {
process(node);
} else {
// 自旋几次再 park，避免忙等
for (int i = 0; i < SPIN_COUNT && queue.isEmpty(); i++) {
Thread.onSpinWait();
}
if (queue.isEmpty()) {
LockSupport.parkNanos(this, 100_000); // 等 100 微秒，可被生产者 unpark 唤醒
}
}
}
想实现“纳秒级可控休眠”？别用 parkNanos
Java 中没有真正纳秒级精度的休眠 API。若需更高精度的等待（仍达不到纳秒，但比 sleep 更细粒度），可考虑：
-
Thread.sleep(0, 1)：纳秒参数是“补充毫秒”，实际最小分辨率仍是毫秒级 - 结合
System.nanoTime()自旋等待：适用于极短且确定的等待（如几十纳秒），但会消耗 CPU - 依赖底层库（如 JNA 调用
nanosleep）：跨平台难、风险高，一般不推荐
真正需要亚毫秒级调度的场景，通常应交由实时操作系统或专用硬件处理，而非通用 JVM。
注意事项和常见误区
- parkNanos 的 nanos 参数为负数时，行为等同于
park()（无限期等待） - 多次 unpark 只生效一次，park 不会累计“未消费的 unpark”
- 必须确保目标线程已启动且能接收 unpark；对未启动或已终止线程调用无效
- 不要把它当作“更精确的 sleep”来用，否则会因精度预期错位导致逻辑错误或性能反效果
