Java锁机制之park和unpark源码剖析

一、 PlatformEvent 的核心数据结构与状态机
二、 PlatformEvent::park() 源码深度解析

1. 无超时限制的 `park()` 实现
2. 带有超时限制的 `park(jlong millis)` 实现

三、 PlatformEvent::unpark() 源码深度解析
四、核心系统级设计与 Linux Futex 的映射

1. 内存屏障与硬件可见性
2. Linux NPTL 与 Futex 机制的映射
3. 总结：两阶段的核心精髓

前言

本文旨在记录近期研读Java源码的学习心得与疑难问题。由于个人理解水平有限，文中内容难免存在疏漏，恳请读者不吝指正

park和unpark源码剖析

在 OpenJDK 8 的 HotSpot 虚拟机中，PlatformEvent 是一个极其底层的同步原语，主要用于 JVM 内部的线程同步，例如重量级锁（ObjectMonitor）、内核级互斥锁（Mutex）和监视器（Monitor）的实现。

需要特别区分的是，JVM 中有两个非常相似的同步类：

Parker：专门服务于 Java 层的 LockSupport.park() / unpark()，即 java.util.concurrent 包（如 ReentrantLock）的底层支撑。
PlatformEvent：专门服务于 JVM 内部基础设施的同步。

下面将深入剖析 Linux 平台下（hotspot/src/os/linux/vm/os_linux.cpp）PlatformEvent::park() 和 PlatformEvent::unpark() 的源码实现、状态机演变以及底层的系统级设计原理。

一、 PlatformEvent 的核心数据结构与状态机

在了解方法实现之前，必须先理解 PlatformEvent 的核心成员变量及其表示的状态。其在头文件中的定义主要包含：

class PlatformEvent : public CHeapObj<mtInternal> {
private:
volatile int _Event ;          // 核心状态变量：1 表示有信号，0 表示中性，-1 表示有线程正在等待
pthread_mutex_t _mutex[1] ;    // POSIX 互斥锁，用于保护状态变更
pthread_cond_t  _cond[1] ;     // POSIX 条件变量，用于线程的挂起与唤醒
    ...
}

_Event 的状态机流转如下：

0（初始/中性状态）：没有线程在等待，也没有提前释放的信号。
1（有信号状态）：意味着 unpark() 先于 park() 发生。此时若有线程调用 park()，可以免去挂起，直接消费该信号并返回。
-1（等待状态）：意味着当前已有线程因为没有信号而陷入了阻塞，正在条件变量 _cond 上等待被唤醒。

二、 PlatformEvent::park() 源码深度解析

park() 方法的作用是使当前线程挂起，直到被 unpark() 唤醒、或者遭遇伪唤醒（Spurious Wakeup）。HotSpot 在此处采用了精妙的“快路径/慢路径（Fast-path / Slow-path）”检测机制。

1. 无超时限制的 `park()` 实现

void os::PlatformEvent::park() {
// ----------- 【快路径 (Fast-Path) / 用户态无锁优化】 -----------
// 使用原子交换操作（Atomic::xchg）将 _Event 赋值为 0，并返回其旧值。
// 如果旧值大于 0（即 _Event 原本为 1），说明在此之前有其他线程执行过 unpark()。
// 此时当前线程不需要挂起，直接消耗掉这个信号，并立即在用户态返回，避免了后续昂贵的系统调用。
if (Atomic::xchg(0, &_Event) > 0) return;

// ----------- 【慢路径 (Slow-Path) / 准备陷入内核态】 -----------
// 如果进入这里，说明 _Event 旧值为 0 或 -1，没有现成的信号可以消耗，线程可能需要挂起。

// 1. 申请加锁。为了安全地改变 _Event 状态并进入条件变量等待，必须由互斥锁保护。
int status = pthread_mutex_lock(_mutex);
assert_status(status == 0, status, "mutex_lock");

// 2. 双重检查（Double-Check）
// 在当前线程从“快路径原子交换失败”到“成功获取 mutex 锁”的短暂间隙中，
// 可能其他线程恰好执行了 unpark() 将 _Event 置为了 1。
// 因此在锁内必须再次检查，如果 _Event > 0，则重置为 0，释放锁并直接返回。
if (_Event > 0) {
     _Event = 0;
     status = pthread_mutex_unlock(_mutex);
assert_status(status == 0, status, "mutex_unlock");
return;
  }

// 3. 将状态设置为 -1，明确标记当前线程即将进入条件变量的等待队列
  _Event = -1;

// 4. 循环等待，防御 Linux 系统的“伪唤醒”（Spurious Wakeup）
// 根据 POSIX 标准，pthread_cond_wait 可能会在没有任何人 signal 的情况下莫名唤醒（例如被操作系统信号中断 EINTR）。
// 因此必须使用 while 循环检查条件。只要 _Event 依然小于 0，就说明合法的 unpark 信号并未到达。
while (_Event < 0) {
// pthread_cond_wait 会原子性地释放 _mutex 锁，并将当前线程放入 _cond 的等待队列中，
// 随后线程进入阻塞状态（TASK_INTERRUPTIBLE）。
// 当被唤醒时，该函数会在内部重新竞争获取 _mutex 锁，获取成功后才会返回。
     status = pthread_cond_wait(_cond, _mutex);

// 校验系统调用是否成功。Linux 下允许被系统信号中断（返回 EINTR），这属于正常现象。
assert_status(status == 0 || status == EINTR, status, "cond_wait");
  }

// 5. 被成功 unpark 唤醒后，退出循环，释放互斥锁，完成挂起周期的闭环
  status = pthread_mutex_unlock(_mutex);
assert_status(status == 0, status, "mutex_unlock");
}

2. 带有超时限制的 `park(jlong millis)` 实现

带超时的版本需要计算绝对时间戳，并调用 POSIX 的定时阻塞函数。

int os::PlatformEvent::park(jlong millis) {
// 如果传入的超时时间小于等于 0，则直接当作不消耗时间的快路径处理，直接返回
if (millis <= 0) return OS_OK;

// 同样先走原子交换的快路径优化
if (Atomic::xchg(0, &_Event) > 0) return OS_OK;

// 获取互斥锁
int status = pthread_mutex_lock(_mutex);
assert_status(status == 0, status, "mutex_lock");

// 锁内双重检查
if (_Event > 0) {
     _Event = 0;
     status = pthread_mutex_unlock(_mutex);
assert_status(status == 0, status, "mutex_unlock");
return OS_OK;
  }

// 标记为等待状态
  _Event = -1;

struct timespec ts;
// os::Linux::supports_monotonic_clock() 在现代 Linux 系统上基本都返回 true。
// 计算绝对超时时间（当前单调时钟时间 + 传入的毫秒数）。
// 采用单调时钟（CLOCK_MONOTONIC）是为了规避系统时间被人工修改（如 NTP 同步、手动改时间）导致的定时器错乱风险。
if (os::Linux::supports_monotonic_clock()) {
struct timespec now;
clock_gettime(CLOCK_MONOTONIC, &now);
    ts.tv_sec = now.tv_sec + (millis / 1000);
    ts.tv_nsec = now.tv_nsec + ((millis % 1000) * 1000000);
  } else {
// 若系统不支持单调时钟，则降级使用墙上时钟（CLOCK_REALTIME）
struct timeval now;
gettimeofday(&now, NULL);
    ts.tv_sec = now.tv_sec + (millis / 1000);
    ts.tv_nsec = (now.tv_usec + ((millis % 1000) * 1000)) * 1000;
  }

// 边界校正：如果纳秒部分超过 1 秒，需要向秒位进位
if (ts.tv_nsec >= 1000000000) {
    ts.tv_sec++;
    ts.tv_nsec -= 1000000000;
  }

int ret = OS_OK;

// 限时循环等待
while (_Event < 0) {
// 调用封装好的 safe_cond_timedwait。
// 该函数底层调用 pthread_cond_timedwait，在到达 ts 指定的绝对时间后会自动唤醒并返回 ETIMEDOUT。
    status = os::Linux::safe_cond_timedwait(_cond, _mutex, &ts);

// 如果返回 ETIMEDOUT，说明超时时间已到，需要主动跳出循环结束挂起
if (status == ETIMEDOUT) {
      ret = OS_TIMEOUT;
break;
    }
assert_status(status == 0 || status == EINTR, status, "cond_timedwait");
  }

// 无论是正常唤醒还是超时退出，最终都要重置状态为 0（中性），并释放锁
  _Event = 0;
  status = pthread_mutex_unlock(_mutex);
assert_status(status == 0, status, "mutex_unlock");

return ret;
}

三、 PlatformEvent::unpark() 源码深度解析

unpark() 的职责是释放一个信号去唤醒正在挂起的线程。如果没有线程在挂起，则将信号记录在 _Event 中，允许下一次 park() 直接通过。

void os::PlatformEvent::unpark() {
// ----------- 【快路径 (Fast-Path) / 无锁优化】 -----------
// 使用原子交换将 _Event 设置为 1。
// 如果旧值 >= 0（即旧值为 0 或 1），意味着当前【没有任何线程】在 _cond 上挂起等待。
// 此时，仅仅将 _Event 设置为 1（表示信号已提前备好）即可直接返回。
// 这极大地减少了高并发下不必要的锁竞争（Mutex Lock）和上下文切换（Context Switch）。
if (Atomic::xchg(1, &_Event) >= 0) return;

// ----------- 【慢路径 (Slow-Path) / 存在挂起线程】 -----------
// 如果 Atomic::xchg 返回的旧值是 -1，说明当前有线程正在挂起等待唤醒。

// 1. 申请加锁，进入临界区
int status = pthread_mutex_lock(_mutex);
assert_status(status == 0, status, "mutex_lock");

// 2. 再次确认是否有等待者
// 因为在上面原子操作到加锁之间，可能挂起线程由于超时或者伪唤醒已经自己退出了。
int anyWaiters = (_Event < 0);

// 3. 将状态显式设置为 1（有信号）
  _Event = 1;

// 4. 释放互斥锁
// 注意：HotSpot 故意在释放锁之后才调用 pthread_cond_signal。
  status = pthread_mutex_unlock(_mutex);
assert_status(status == 0, status, "mutex_unlock");

// 5. 触发唤醒信号
// 如果确认有等待线程（anyWaiters == true），则调用 pthread_cond_signal 唤醒条件变量队列中的首个线程。
// 为什么要在释放锁（unlock）之后才调用 signal？
// 这是为了实践 Mesa 派系的管程设计（Mesa-style Monitor）：
// 如果在锁内 signal，被唤醒的线程会立刻试图去获取 _mutex，但此时锁还在 unpark 线程手里，
// 这会导致被唤醒的线程立即发生二次阻塞（Convoy Effect，护航现象）。
// 在锁外 signal 可以让被唤醒的线程直接顺利拿到锁，减少上下文切换。
if (anyWaiters) {
    status = pthread_cond_signal(_cond);
assert_status(status == 0, status, "cond_signal");
  }
}

四、核心系统级设计与 Linux Futex 的映射

从 Java 系统工程师以及 Linux 内核的角度来看，PlatformEvent 的设计蕴含了深厚的底层性能考量：

1. 内存屏障与硬件可见性

在 park() 和 unpark() 的第一步都使用了 Atomic::xchg。

硬件层面：在 x86/x64 架构下，Atomic::xchg 底层会被编译为带有 LOCK 前缀的指令（如 lock xchg）。
语义层面：LOCK 前缀指令不仅保证了操作的原子性，还自带全内存屏障（Full Memory Barrier）的效果。它会强制刷新处理器的写缓冲区（Store Buffer），并使得其他核心的 CPU 缓存行（Cache Line）失效。这确保了多核架构下 _Event 变量在不同线程之间的极端可见性。

2. Linux NPTL 与 Futex 机制的映射

在 Linux 上，POSIX 线程库（NPTL）的 pthread_mutex 和 pthread_cond 并不是纯粹的用户态结构，也不是完全的内核态死锁，而是基于 Futex（Fast Userspace Mutex，快速用户空间互斥体） 实现的：

无竞争时：无论是加锁还是条件变量检测，都完全在用户态（User Space）通过原子指令完成（即快路径），性能极高。
有竞争时：当 park() 确认需要挂起并走到 pthread_cond_wait 内部时，NPTL 会发起一个 Linux 系统调用：

syscall(__NR_futex, &cond_futex_word, FUTEX_WAIT_PRIVATE, ..., NULL);

此时 Linux 内核会将当前线程的状态从 TASK_RUNNING 修改为 TASK_INTERRUPTIBLE，剥夺其 CPU 时间片，并放入到 Futex 的内核哈希等待队列中。

唤醒时：当 unpark() 走到 pthread_cond_signal 时，内核会执行：

syscall(__NR_futex, &cond_futex_word, FUTEX_WAKE_PRIVATE, 1);

内核查找到对应的等待队列，将挂起线程的 task_struct 重新移入操作系统的运行队列（Run Queue）中，等待 CPU 调度。

3. 总结：两阶段的核心精髓

HotSpot 的 PlatformEvent 实现精髓在于通过用户态的原子变量状态，去拦截不必要的内核态切换。只有当中性条件不满足、且经过双重锁定确认后，才真正降级使用 Linux 系统的 Futex 机制挂起线程。这种高低结合的设计，是整个 JVM 高并发吞吐量的基石之一。

前言