LockSupport挂起线程原理及unpark/park机制解析

LockSupport 的 park() 和 unpark() 并非传统意义上的“挂起与唤醒”，而是一套基于二值许可（permit）的轻量级线程协作机制：park() 仅在许可为0时阻塞，否则立即返回；unpark() 则提前发放许可，支持“预支”、不依赖调用顺序，且许可不可累积、与线程强绑定；它绕过 JVM 监视器锁，底层依托操作系统原语实现无锁阻塞，但不提供内存可见性保障，需配合 volatile 等使用；正是这种精准控制单个线程、无对象依赖、低开销的特性，使其成为 AQS 等高级同步组件的底层基石——而绝大多数 park() 卡死问题，根源往往只是许可未正确发放：调少了、调早了、或根本漏调了。

LockSupport.park() 为什么线程没反应？

它根本不会“挂起线程”——park() 只是检查当前线程的许可（permit）是否为 1，是就消费掉并立即返回；否则阻塞。没有“主动挂起”的语义，只有“等待许可”。常见错误是调用 park() 前没确保许可可用，结果线程直接卡住。

• 许可是二值的：0 或 1，不可叠加（多次 unpark() 只保留一次效果）
• park() 不响应中断，但会设置线程的中断状态（Thread.interrupted() 为 true）
• 如果线程已中断后调用 park()，它仍会阻塞，只是返回后你得手动处理中断逻辑
• 不要在循环外裸调 park()，典型模式是 while + 条件检查 + park()

unpark() 提前发了，park() 还会阻塞吗？

不会。unpark(Thread) 是“发许可”，只要目标线程还没消费，下次调用 park() 就直接返回。这是它和 Object.wait() 最关键的区别：许可可“预支”，不依赖调用顺序。

• unpark() 对已终止线程无效，但也不会报错
• 对未启动线程调用 unpark() 是安全的，启动后首次 park() 立即返回
• 同一个线程反复 unpark() 多次，等效于只发一次许可（许可无法累积）
• 注意：许可归属线程，不是调用者；unpark(t) 给 t 发，不是给当前线程发

底层怎么做到“无锁挂起”？

HotSpot 里 park()/unpark() 最终走的是 OS 层的线程阻塞原语（如 Linux 的 pthread_cond_wait() / pthread_cond_signal()），但封装了一层 Unsafe.park() —— 它绕过了 JVM 的 monitor 锁机制，不进 ObjectMonitor 队列，也不参与 synchronized 语义。

• 没有竞争时，park() 是轻量级的系统调用（非忙等）
• 被 unpark() 唤醒的线程不保证立刻执行，只是从阻塞态转为就绪态，仍需调度器安排
• 在 GC 安全点附近调用 park() 可能被延迟唤醒（JVM 会等安全点再真正挂起）
• 不能替代 synchronized 或 ReentrantLock 做同步，它只负责阻塞/唤醒，不提供内存可见性保障（需配合 volatile 或 VarHandle）

为什么 LockSupport 被 AQS 当作基石？

因为 park() 和 unpark() 是唯一能精准控制单个线程阻塞/唤醒、且不依赖对象监视器的 JVM 原语。AQS 的 acquire()/release() 流程靠它把线程“按住”或“松开”，而不用管锁对象、条件队列这些上层抽象。

• AQS 中每个节点（Node）对应一个线程，park() 挂起的是节点里存的线程，不是当前线程本身
• unpark() 在释放锁时触发，但只唤醒 head.next，不是广播唤醒所有等待者
• 如果你手写同步器，忘记在合适时机 unpark()，就会永久挂起；多调一次，只是浪费一次许可
• 调试时看到线程状态为 WAITING (parking)，说明它正卡在 park()，此时查谁该发 unpark() 更有效

今天关于《LockSupport挂起线程原理及unpark/park机制解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！