Java Monitor 同步机制

Java 中的 synchronized 关键字是实现线程安全与同步的核心手段，其底层依赖于 JVM 提供的 Monitor（管程 / 监视器锁） 机制。

Monitor 不仅在语义层保证了并发访问的互斥性与可见性，更在底层的 Java 内存模型（JMM）与现代 CPU 硬件指令集上建立了严密的内存屏障与 Happens-Before 关联。

⤢

qtopie.github.io

JMM 内存模型与 Happens-Before 规则

Java 内存模型（JMM）通过 Happens-Before 原则定义了多线程环境下的内存可见性与有序性保障。Monitor 机制是 JMM Happens-Before 规则的核心载体之一。

监视器锁规则 (Monitor Lock Rule)

JMM 明确规定：对一个监视器锁的解锁（Unlock）Happens-Before 于后续对同一个监视器锁的加锁（Lock）。

⤢

qtopie.github.io

内存屏障与硬件级指令映射 (Memory Barriers)

为了实现 Monitor 锁的 Happens-Before 语义，JVM 在编译与字节码执行时会在 Monitor 的临界区边界插入硬件级内存屏障 (Memory Barrier)：

• 获取锁 (monitorenter)：
  • JVM 会插入 LoadLoad + LoadStore 屏障。
  • 功效：清空线程本地工作内存（L1/L2 Cache），强制后续所有共享变量的读写操作必须直接从主内存（Main Memory）重新加载，保证读到的总是最新值。
• 释放锁 (monitorexit)：
  • JVM 会插入 StoreStore + StoreLoad 屏障。
  • 功效：强制将线程工作内存中对共享变量的所有修改（Write Buffer / Store Buffer 积压刷新）立即刷回主内存，确保这些修改对后续抢锁线程绝对可见。

Monitor 内部底层结构与锁膨胀机制

在 HotSpot JVM 中，每个对象都可以充当 Monitor 锁。对象的Mark Word（对象头） 在不同锁状态下指向不同的物理结构。

HotSpot ObjectMonitor C++ 结构解析

当锁膨胀为重量级锁（Heavyweight Lock）时，Mark Word 会指针关联到一个 C++ ObjectMonitor 结构体：

// HotSpot 源码 hotspot/src/share/vm/runtime/objectMonitor.hpp
ObjectMonitor() {
    _header       = NULL;
    _count        = 0;       // 重入计数器
    _waiters      = 0;
    _recursions   = 0;       // 锁重入次数
    _object       = NULL;    // 指向被锁的对象
    _owner        = NULL;    // 指向当前持有 Monitor 的 Thread 指针
    _WaitSet      = NULL;    // 处于 wait() 状态的线程单向链表
    _WaitSetLock  = 0;
    _Responsible  = NULL;
    _succ         = NULL;
    _cxq          = NULL;    // 竞争锁失败的单向 LIFO 栈 (_cxq)
    FreeNext      = NULL;
    _EntryList    = NULL;    // 准备竞争锁的双向等待队列
    _spinFreq     = 0;
    _spinClock    = 0;
    OwnerIsThread = 0;
}

Java Monitor 如何支持锁队列与 Condition 队列？

与 Java AQS（依赖 state + 双向 CLH 队列 + 单向 Condition 队列）的架构思想高度契合，JVM 底层的 ObjectMonitor（C++ 实现） 本质上也维护了两类物理队列来实现锁竞争（锁队列）与线程协同（Condition 队列）：

⤢

qtopie.github.io

1. 核心封装节点：ObjectWaiter

在 C++ 内部，JVM 并不是直接把原生 Thread 指针放入队列，而是把线程封装为一个 ObjectWaiter 结构体（类似于 AQS 的 Node）：

class ObjectWaiter : public StackObj {
  public:
    enum TStates { TS_UNDEF, TS_READY, TS_RUN, TS_WAIT, TS_ENTER, TS_CXQ };
    ObjectWaiter* _next;
    ObjectWaiter* _prev;
    Thread*       _thread;
    volatile TStates TState;
    bool          _active;
    // ...
};

2. 锁队列机制：_cxq 与 _EntryList

Java Monitor 的锁队列由 _cxq 和 _EntryList 配合组成：

• _cxq（Contention Queue，单向 LIFO 栈）：
  • 入队：当线程执行 monitorenter 抢锁失败时，JVM 会创建一个 ObjectWaiter，通过 CAS 争抢将节点压入 _cxq 的栈头。由于使用了 CAS 栈顶更新，多线程并发入队无需加锁。
• _EntryList（准备获锁的 FIFO 队列）：
  • 转移与唤醒：当持有锁的线程执行 monitorexit 释放锁时，如果 _EntryList 为空，持锁线程会将 _cxq 中的所有节点一次性转移到 _EntryList 中，然后再唤醒 _EntryList 头的线程去抢锁。
  • 分流设计的意义：将高并发 CAS 入队的 _cxq 与顺序唤醒出队的 _EntryList 解耦，极大地降低了锁释放时的队列头尾竞争。

3. Condition 队列机制：_WaitSet

_WaitSet 是 JVM 用来实现 Object.wait() 和 Object.notify() 的物理条件队列：

• Object.wait() 过程（挂入 Condition 队列）：

  1. 线程持锁期间调用 obj.wait()。
  2. 线程创建或复用 ObjectWaiter 节点，将其标记为 TS_WAIT 状态。
  3. 将节点插入到 _WaitSet 链表的尾部。
  4. 完全释放当前持有 Monitor 锁的所有权（_owner = NULL，重入计数器 _recursions 清零）。
  5. 唤醒 _EntryList 或 _cxq 中的线程来接管锁。
  6. 当前线程调用 os::PlatformEvent::park() 挂起休眠。

• Object.notify() 过程（节点转移到锁队列）：

  1. 持锁线程调用 obj.notify()。
  2. JVM 遍历 _WaitSet，弹出队首的第一个有效 ObjectWaiter 节点。
  3. 节点转移（Transfer）：JVM 根据策略（由 Knob_Knock 配置决定），将该节点从 _WaitSet 移出，并重新插入到 _EntryList 或 _cxq 锁队列中。
  4. 节点的状态从 TS_WAIT 变为 TS_ENTER 或 TS_CXQ。
  5. 被唤醒的线程并不会立即执行，而是必须等待当前线程释放锁后，在锁队列中重新竞争到锁，才能从 wait() 代码处返回！

4. Monitor 队列 vs AQS 队列对比

锁膨胀与升级机制 (Lock Escalation)

为了在低竞争场景下避免重量级锁昂贵的内核态切换（pthread_mutex / futex），HotSpot JVM 设计了锁膨胀升级机制：

⤢

qtopie.github.io

1. 偏向锁（Biased Locking）：
   • 假设“锁总是由同一个线程多次获得”。
   • 首次获取锁时，在 Mark Word 中记录 ThreadID；后续该线程再次进入时，仅需比对 ThreadID，完全无需 CAS 操作。
2. 轻量级锁（Lightweight Locking）：
   • 当有第二个线程尝试获取锁时，偏向锁撤销并升级为轻量级锁。
   • 线程在各自的线程栈帧中创建 Lock Record，通过 CAS 将 Mark Word 指向 Lock Record。抢锁失败时采用适应性自旋等待，避免让出 CPU。
3. 重量级锁（Heavyweight Locking）：
   • 当自旋达到一定次数，或竞争过于激烈时，轻量级锁膨胀为重量级锁。
   • JVM 申请分配底层 C++ ObjectMonitor，争抢失败的线程由内核态调用 pthread_mutex / futex 挂起（park），进入阻塞休眠状态。

Monitor 在 Java 中的主要应用场景

1. 语言级同步块与同步方法 (synchronized)

• 同步代码块：编译器生成 monitorenter 和 monitorexit 字节码指令。为了保证异常情况下锁依然被释放，编译器会自动生成隐式的 try-finally 异常处理块，在异常路径上追加 monitorexit。
• 同步方法：静态或实例方法修饰 synchronized 时，字节码 flags 中会标注 ACC_SYNCHRONIZED 标志位，JVM 在调用方法时自动隐式执行 monitorenter 与 monitorexit。

2. 传统线程间协作 (Object.wait() / Object.notify())

• 配合要求：调用 wait()、notify() 或 notifyAll() 前，线程必须首先持有该对象的 Monitor 锁（即位于 synchronized 块内），否则抛出 IllegalMonitorStateException。
• 协作原理：
  • wait()：线程释放当前 Monitor 锁的所有权（_owner 归零，重入计数器 _recursions 暂存），线程被封装放入 _WaitSet 并休眠。
  • notify()：从 _WaitSet 中挑选一个等待节点，将其转移到 _EntryList 或 _cxq 中，使其重新获得竞争 Monitor 锁的资格。

3. Java 基础并发容器实现

• Vector / Hashtable：所有核心读写方法均使用 synchronized 修饰，依赖 Monitor 保障线程安全。
• Collections.synchronizedList() / synchronizedMap()：包装器模式，内部维护一个 final Object mutex 对象，所有读写方法均在 synchronized(mutex) 块中完成。
• Early JDK ConcurrentHashMap：JDK 1.7 之前的 Segment 锁，以及 JDK 1.8 中在哈希桶首节点上的 synchronized 细粒度锁定。

Monitor 锁 vs AQS (ReentrantLock) 对比