LockSupport.park()和unpark()本质是基于JVM中每个线程私有的Parker对象的_counter许可机制,通过Unsafe调用JVM层park/unpark,最终映射到OS原语(如pthread_cond_wait/signal)。

LockSupport.park() 和 unpark() 看似简单,但它们是 Java 并发基石的“隐形引擎”。要真正读懂 JDK 源码里的实现,不能只看 Java 层的封装,得顺着调用链一路下钻到 JVM 内部 —— 从 LockSupport → Unsafe → Parker → OS 原语。
Java 层:LockSupport 是个“薄包装”
LockSupport 所有方法都是静态的,不维护状态,也不依赖锁。核心就两行:
public static void park() {
UNSAFE.park(false, 0L); // false 表示相对时间,0L 表示无限等待
}
public static void unpark(Thread thread) {
if (thread != null) UNSAFE.unpark(thread);
}
这里的 UNSAFE 是 sun.misc.Unsafe(或 jdk.internal.misc.Unsafe,JDK 9+ 模块化后路径变化),它提供直接操作内存和线程调度的 native 能力。park/unpark 对应的就是它的两个 native 方法。
✅ 关键点:
LockSupport本身无逻辑,纯代理;真正的阻塞/唤醒发生在Unsafe.park和Unsafe.unpark。
JNI 层:Unsafe.park → HotSpot 的 Parker
Unsafe.park 是一个 native 方法,在 hotspot/src/share/vm/prims/unsafe.cpp 中实现:
// unsafe.cpp UNSAFE_ENTRY(void, Unsafe_Park(JNIEnv *env, jobject unsafe, jboolean isAbsolute, jlong time)) ... JavaThread* thread = JavaThread::current(); thread->parker()->park(isAbsolute, time); UNSAFE_END
它拿到当前 Java 线程对象,再取出其专属的 Parker 实例,调用 parker->park(...)。
同理,Unsafe_Unpark 最终调用 thread->parker()->unpark()。
✅ 关键点:每个 Java 线程在创建时,JVM 都会为其分配一个
Parker对象(懒加载,首次 park 时初始化),它是线程私有的。
JVM 层:Parker 类 —— 许可(Permit)机制的载体
Parker 定义在 hotspot/src/os/linux/vm/os_linux.cpp(Linux)或对应平台文件中,核心成员只有三个:
class Parker : public os::PlatformParker {
private:
volatile int _counter; // ✅ 就是那个“许可”:0 或 1
os::PlatformParker::Mutex _mutex;
os::PlatformParker::Condition _cond;
...
};
-
_counter是 volatile 整型,不是 boolean,但语义上只取 0 或 1; -
park()逻辑本质是:- 原子地将
_counter从 1 → 0,若成功(说明有许可),立即返回; - 若原值为 0,则进入
os::PlatformParker::park(),实际调用系统级阻塞原语(如 Linux 上的pthread_cond_wait);
- 原子地将
-
unpark()逻辑本质是:- 原子地将
_counter从 0 → 1(仅当原值为 0 时才改); - 若此时线程正在
park中等待,则唤醒其关联的条件变量_cond,使其退出阻塞。
- 原子地将
✅ 关键点:
_counter是许可的唯一表示,不可累加、不可重入、最多为 1。连续两次unpark(t)和一次效果完全相同。
操作系统层:最终落地靠 pthread / Windows Event
以 Linux 为例,PlatformParker::park() 最终会:
- 加锁(
_mutex.lock()); - 检查
_counter > 0,若成立则--_counter后直接返回; - 否则调用
pthread_cond_wait(&_cond, &_mutex),挂起线程并释放锁; - 被唤醒后重新持锁,再检查
_counter(防虚假唤醒),决定是否继续等待。
而 unpark() 则:
- 加锁;
- 若
_counter == 0,则++_counter,并调用pthread_cond_signal(&_cond)唤醒一个等待线程; - 解锁。
✅ 关键点:底层依赖的是标准 POSIX 线程原语,保证了跨平台一致性与可靠性。
为什么能“先 unpark 后 park”?
因为 unpark() 修改的是 _counter —— 它是一个状态标记,不是“唤醒动作”本身。只要 _counter == 1,后续 park() 就不会阻塞,而是直接消费掉这个 1,变成 0。
这和 Object.wait()/notify() 的“队列+信号丢失”模型根本不同:后者 notify 若发生在 wait 前,信号就丢了;而 unpark 是“预存许可”,天然支持时序松耦合。
调试建议:想真看清,得用 HotSpot 调试
- 编译带 debug info 的 OpenJDK(如
make images DEBUG=true); - 在
Parker::park()和Parker::unpark()打断点; - 结合 Java 代码(比如启动一个
Thread并LockSupport.park()),用 IDE 远程 attach JVM; - 观察
_counter变化、线程状态切换(RUNNABLE↔WAITING)、以及_cond是否被 signal。
这样你看到的,就不是 API 文档,而是真实运行时的线程调度脉搏。
不复杂但容易忽略











