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 文档，而是真实运行时的线程调度脉搏。
不复杂但容易忽略
