LockSupport.park()不响应中断是因为它仅设置中断状态而不抛异常或自动返回，需手动检查Thread.currentThread().isInterrupted()；unpark()提前调用会导致许可丢失；parkNanos()精度受限于系统调度；不应绕过LockSupport直接调用Unsafe.park()。
LockSupport.park() 为什么线程不响应中断
因为 park() 本身不抛出 InterruptedException，也不在被中断时自动返回——它只是把当前线程的中断状态设为 true，然后继续挂起。你得自己轮询 Thread.interrupted() 或检查 Thread.currentThread().isInterrupted() 才能退出。
常见错误现象：park() 后调用 thread.interrupt()，但线程卡死不动；或者用 while (!Thread.interrupted()) { LockSupport.park(); }，结果中断后仍 park 一次（因 interrupted() 清除了状态，第二次 park 就没机会再检查）。
- 正确做法：用
Thread.currentThread().isInterrupted()判断，避免状态被清空 - 典型场景：自定义锁、AQS 队列节点等待、协程调度器中的线程阻塞点
- 注意
park()的「许可」机制：如果之前调用过unpark()，这次park()会直接返回，不挂起
LockSupport.unpark() 调用时机错位导致失效
unpark() 只对指定线程生效一次，且只发一个「许可」；如果目标线程还没 park()，许可就提前发了，那后续 park() 会直接消耗掉它并立即返回——表面看“唤醒成功”，实则可能跳过关键同步逻辑。
使用场景：生产者往队列写数据后唤醒消费者线程；或 AQS 中 acquire 失败入队，release 时唤醒头结点。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 容易踩的坑：
unpark()在park()前调用，且中间无其他 park，等于白发 - 调试技巧：配合
Thread.getState()看是否真处于WAITING或TIMED_WAITING - 没有跨线程内存可见性保证：
unpark()不隐含 volatile 写，需额外同步手段确保前置操作对被唤醒线程可见
LockSupport.parkNanos() 的超时精度和系统时钟依赖
parkNanos(long nanos) 并不精确，尤其在低负载或高精度要求下。Linux 上底层依赖 clock_nanosleep(CLOCK_MONOTONIC)，但 JVM 实现会做粗粒度对齐（如按毫秒切片），且受系统调度延迟影响，实际唤醒可能晚于预期几十毫秒甚至更久。
参数差异：parkNanos(0) 等价于 park()；负数会立即返回，不挂起。
- 性能影响：频繁调用短超时（如
parkNanos(1)）会导致大量系统调用和上下文切换，CPU 使用率飙升 - 兼容性注意：Windows 上基于
WaitForSingleObject，超时行为与 Linux 略有不同，测试时别只盯 Linux 结果 - 替代思路：需要精准定时建议用
java.util.concurrent.ScheduledThreadPoolExecutor，而非靠 parkNanos 拼精度
Unsafe.park vs LockSupport.park：为什么不该绕过 LockSupport
LockSupport 是对 Unsafe.park() 的封装，加了中断检测、许可计数管理、线程安全包装。直接调 Unsafe.park() 不仅要处理 SecurityManager 权限问题，还会丢失 unpark() 和 park() 的配对语义，比如多次 unpark() 只保留最后一次许可，而 LockSupport 保证许可最多为 1。
真实搜索需求：有人想“绕过 LockSupport 做更底层控制”，结果发现唤醒失败、JVM Crash 或 GC 时线程状态异常。
- 根本原因：
Unsafe.park()不参与 JVM 线程状态机维护，Thread.getState()可能返回RUNNABLE却实际已挂起 - JDK 9+ 进一步限制
Unsafe访问，反射调用会触发IllegalAccessError - 唯一合理绕过场景：极少数 JVM 内部模块（如 ZGC 的并发线程协调），普通业务代码毫无必要
真正难的不是调用 park/unpark，而是理解它们和线程状态、中断标志、许可计数三者之间的时序耦合——少查一次 isInterrupted()，或多发一次 unpark()，都可能让线程永远卡在 WAITING 状态里，还查不出日志。
