LockSupport 是线程“开关”，通过 park() 挂起线程、unpark() 发送许可唤醒，许可最多为1且不丢失，无锁、轻量、线程安全，是 AQS 等底层同步机制的基础。
LockSupport 是什么：不是锁，是线程“开关”
LockSupport 不是锁，也不是同步器，它就是一个极轻量的线程阻塞/唤醒原语。它的核心就两件事：park() 让当前线程挂起，unpark(Thread) 给指定线程发一个“许可证”，让它能从 park() 中醒来。每个线程内部都关联一个隐式的许可（permit），初始为 0；unpark() 把它设成 1，park() 检查到是 1 就直接返回、不挂起，同时把 permit 清零；如果已经是 0，就真正阻塞等待。
- 许可是“累积但只存一个”：连续调用两次
unpark(t)，效果和一次一样——permit 最多就是 1 - 没有竞争条件：
unpark()可以在park()之前调用，不会丢失，这是它比wait()/notify()更可靠的关键 - 不依赖 synchronized：不需要持有任何对象锁，调用自由，也正因如此，它不能替代 wait/notify 的“条件等待”语义
为什么不用 wait/notify？park/unpark 的真实优势场景
当你需要跨线程精准控制单个线程的挂起与唤醒，且不想被锁对象生命周期或调用顺序卡住时，park()/unpark() 才是更底层、更可控的选择。典型如 AQS 内部实现——线程入队后挂起，释放锁时唤醒后继节点，整个过程不涉及任何 monitor 锁。
- 常见错误现象：
wait()前没synchronized抛IllegalMonitorStateException；notify()提前调用导致线程永远等不到信号 - 使用场景举例：自定义无锁队列的消费者等待、协程调度器中挂起恢复 Java 线程、测试线程状态机时做精确控制
-
park()可带超时参数：parkNanos(long)或parkUntil(long)，而wait()超时后仍需重新检查条件，容易漏判
容易踩的坑：permit 机制带来的“静默失败”
最常被忽略的是 permit 的“一次性消费”特性：如果线程 A 已经 unpark() 过线程 B，B 后续第一次 park() 会立刻返回，根本不会挂起——你以为它在等，其实它早被“预唤醒”了。这种行为在调试时极难察觉，尤其在线程复用或测试 case 顺序变化时。
- 调试技巧：用
Thread.getState()检查是否真处于WAITING或TIMED_WAITING，而不是只看逻辑流程 - 不要依赖 “park 一定阻塞”：始终把
park()当作“可能立即返回”的操作，业务逻辑必须自带重试或状态校验 - 避免在同一线程反复
park()而不配对unpark()：permit 清零后第二次park()才真正阻塞，容易造成时序错乱
底层靠 Unsafe，但你几乎不需要关心
LockSupport 内部通过 Unsafe.park() 和 Unsafe.unpark() 实现，确实依赖 JVM 的 native 层支持。但这层封装已经足够稳定——从 Java 6 到 Java 21，接口语义未变，JVM 实现细节（比如是否用 futex、如何映射到 OS 线程状态）完全隔离。你只需记住：它快、低开销、无锁、线程安全，且所有方法都是静态的。
立即学习“Java免费学习笔记（深入）”；
- 性能影响：相比
Object.wait()，park()上下文切换更轻，AQS 大量使用正是因为它避免了 monitor 锁的膨胀和竞争开销 - 兼容性：所有主流 JDK（HotSpot、OpenJ9、Zing）均完整支持，无需额外配置或 flag
- 别试图绕过它去调
Unsafe：不仅破坏封装，还可能触发 JVM 未来版本的限制（如 JDK 17+ 对Unsafe的进一步封禁）
真正复杂的地方在于：permit 是线程私有、不可见、不可重入的状态。它不像变量能打印或断点观察，只能靠设计时的严格配对和运行时状态检查来兜底。
