LockSupport：线程挂起唤醒的底层机制解析

LockSupport 的核心奥秘在于每个线程私有的、由 JVM 在 native 层隐式维护的二值 permit（0 或 1），它不依赖任何用户可见变量，却能安全实现“预发唤醒”——unpark 可提前生效、避免信号丢失，而 park 仅在 permit 为 0 时真正阻塞；这种轻量级机制绕过了 synchronized 和 monitor 锁的复杂开销，底层直连操作系统线程原语，但需注意：permit 自身原子可见，却不保证共享变量同步，业务中仍须配合 volatile 或内存屏障确保状态一致性——理解它，就握住了 Java 并发底层唤醒逻辑的钥匙。

LockSupport 的线程挂起与唤醒，底层不依赖任何用户可见的“变量”，而是靠每个线程内部隐式关联的一个 许可（permit）状态。这个 permit 是一个二值信号量：取值只能是 0 或 1，不可累加，也不可负值。

permit 是怎么工作的

每个 Java 线程在创建时，JVM 就为其初始化了一个 permit，初始值为 0。

• unpark(Thread t)：将目标线程 t 的 permit 设为 1。如果 t 此时正 park 着，就立刻唤醒；如果 t 还没 park，这个 1 就“存着”，等下一次 park 时直接消耗并返回。
• park()：检查当前线程的 permit。如果是 1，就清零并立即返回（不挂起）；如果是 0，才真正调用底层 unsafe.park() 进入阻塞状态。
• 连续两次 unpark(t) 和只调用一次效果完全一样——permit 不会变成 2，它始终最多为 1。

为什么没有显式变量，却能跨线程生效

permit 并非存在某个 public 字段或静态变量里，而是由 JVM 在线程对象（java.lang.Thread 实例）的 native 层面维护的一块私有状态。LockSupport 只是通过 Unsafe 提供的接口去读写它。

• 这种设计避免了锁竞争和内存可见性问题——permit 修改本身是原子的，且对调用 park 的线程天然可见。
• 但注意：unpark() 不保证其前置的共享变量修改对被唤醒线程可见。例如你改了 volatile boolean ready = true，再 unpark(t)，t 唤醒后仍需重新读 ready，不能假设 ready 已同步。
• 若需确保状态可见，应在 unpark 前用 volatile 写、或加内存屏障（如 VarHandle.fullFence）。

常见误解：permit 是不是像 CountDownLatch 那样的计数器

不是。CountDownLatch 的 count 是可减、可等待、可重置的整型变量；permit 是线程私有的、仅用于控制 park 行为的单比特开关。

• 它不参与条件判断逻辑，不暴露给业务代码，也不能被用户直接读取或修改。
• 它的存在只为解决 wait/notify 最头疼的问题：信号丢失。因为 permit 可“预发”，所以 unpark 先于 park 完全合法且安全。
• 调试时看不到 permit 值，只能通过 Thread.getState() 辅助判断：WAITING/TIMED_WAITING 说明真挂起了；RUNNABLE 则可能 permit 已就绪。

底层真正干活的是 Unsafe.park()

LockSupport 所有 park/unpark 的实际阻塞与唤醒动作，都委托给了 sun.misc.Unsafe 类的 native 方法：

• Unsafe.park(boolean isAbsolute, long time)：最终调用操作系统级的线程挂起原语（如 Linux 的 futex_wait 或 pthread_cond_wait）。
• Unsafe.unpark(Thread t)：触发对应线程的唤醒事件，通知内核调度器恢复该线程运行。
• 这些操作绕过了 Java 对象监视器（monitor），因此无需 synchronized，也没有锁升级、偏向锁等开销。

以上就是《LockSupport：线程挂起唤醒的底层机制解析》的详细内容，更多关于的资料请关注golang学习网公众号！