LockSupport线程挂起与unpark机制详解

LockSupport 的 park() 和 unpark() 并非传统意义上的“挂起/唤醒”，而是一套基于二值许可（permit）的轻量级线程协作机制：park() 仅消费许可并可能阻塞，unpark() 则提前发放许可且可“预支”，彻底摆脱了 wait/notify 的严格时序依赖；它绕过 JVM 监视器锁，直接调用操作系统原语实现无锁阻塞，是 AQS 等高级同步器的底层基石——但正因许可不可累积、不响应中断、无内存可见性保障，稍有不慎（如漏发、早发、错发 unpark）就会导致线程永久假死，理解其隐式、一次性、线程绑定的本质，才是驾驭并发编程底层逻辑的关键。

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机制详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！