locksupport.parknanos不挂起线程是因为前置unpark消耗了许可或线程已被中断；参数单位为纳秒，误用毫秒值会导致等待时间远短于预期；它不释放锁、不抛interruptedexception，仅响应中断状态且不自动清除。
LockSupport.parkNanos 为什么挂不起线程？
它不是“挂起失败”，而是根本没触发挂起——parkNanos 只在当前线程没有被中断、且未被 unpark 过的前提下才真正阻塞。一旦线程之前被 unpark 过，这次调用直接返回，不等、不阻塞、不报错。
- 常见错误现象：
parkNanos(1000_000_000)看似等 1 秒，实际瞬间返回，CPU 占用飙高 - 原因：前置逻辑中误调了
LockSupport.unpark(thread)，或该线程刚被其他地方唤醒过 - 验证方法：调用前加一句
System.out.println(Thread.currentThread().isInterrupted() + ", " + Thread.interrupted());，再观察是否已被中断或消费过许可 - 正确前提：确保线程状态干净（无 pending interrupt、无未消费的 unpark 许可）
纳秒参数传错单位导致等待远超预期
parkNanos 的参数是纳秒，不是毫秒，也不是微秒——传 1000 表示 1000 纳秒（1 微秒），传 1000_000_000 才是 1 秒。但 Java 没有类型约束，编译器不会提醒你单位错了。
- 典型误用：
LockSupport.parkNanos(500)想等 500ms，结果只等了 0.5μs，几乎不可察觉 - 更隐蔽的坑：从
System.currentTimeMillis()或Instant.now()推算超时时，容易混淆毫秒和纳秒（比如用Duration.ofMillis(x).toNanos()是对的，但手写x * 1_000_000就容易漏掉一个 0） - 建议统一用
TimeUnit转换：LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(500)) - 注意：
Long.MAX_VALUE纳秒 ≈ 292 年，但 JVM 实际会截断为“无限等待”，行为等价于park()
和 Object.wait / Thread.sleep 的关键区别在哪
别把它当增强版 sleep 用。parkNanos 是 LockSupport 的底层原语，不释放锁、不关联 monitor、不抛 InterruptedException（只响应中断状态，不主动清中断标志）。
- 使用场景：AQS 类库内部、自定义同步器、高性能无锁/半锁结构；不适合替代业务层定时等待
- 中断处理差异：
Thread.sleep遇中断会清中断状态并抛异常；parkNanos遇中断只是立即返回，Thread.interrupted()仍为true，需手动处理 - 性能影响：比
sleep更轻量（无系统调用开销），但要求调用者严格管理许可（unpark）与中断协作，否则极易死锁 - 兼容性：JDK 6+ 全支持，但在某些嵌入式 JVM 或 GraalVM native image 中，若未显式保留
Unsafe相关反射，可能抛NoClassDefFoundError
为什么 unpark 必须在 park 之前调用也可能生效？
因为 park 和 unpark 操作的是一个隐式的“许可计数器”，初始为 0；unpark 把它设为 1，park 把它减回 0 并返回——所以只要计数器 > 0，park 就不阻塞。
立即学习“Java免费学习笔记（深入）”；
- 这就是“许可可累积”的本质：连续两次
unpark，后续一次park仍不阻塞；但第三次park就会挂起（因计数器已归零） - 容易踩的坑：在条件不满足时反复
unpark，导致后续本该挂起的线程直接跳过等待，引发竞态或忙等 - 正确模式：通常配合 while 循环检查条件，
park前不假设许可状态，靠循环体外的条件判断兜底 - 示例节选：
while (!conditionMet()) { LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(10)); }—— 条件由其他线程通过unpark+ 修改共享变量共同驱动
真正难的不是怎么调用 parkNanos，而是搞清“谁负责 unpark”“何时清除中断”“许可是否被意外消耗”。这些逻辑一旦出错，问题往往在线程调度层面暴露，堆栈里看不到明显异常，只能靠状态日志和许可计数推演。
