Java锁机制之Java对象重量级锁源码剖析

Java对象重量级锁源码剖析

前言
Java对象重量级锁源码剖析
- [一、 `ObjectMonitor::EnterI` 核心源码分析](#一、 ObjectMonitor::EnterI 核心源码分析)
- [二、多线程并发"挤压" `_cxq` 的演进全过程](#二、多线程并发“挤压” _cxq 的演进全过程)
- - [1. 第一阶段：并发乐观读取](#1. 第一阶段：并发乐观读取)
  - [2. 第二阶段：硬件级 CAS 决胜](#2. 第二阶段：硬件级 CAS 决胜)
  - [3. 第三阶段：冲突缓解与分支重试（Retry & Mitigate）](#3. 第三阶段：冲突缓解与分支重试（Retry & Mitigate）)
- 三、深度架构思考：为什么要这样设计？
- 四、关键技术点深度总结

前言

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

Java对象重量级锁源码剖析

在 HotSpot 虚拟机中，当多个线程同时竞争 Java 对象的重量级锁（ObjectMonitor）失败时，它们会被驱逐到慢速路径（Slow Path）中。ObjectMonitor::EnterI 就是处理线程因锁饱和而需要封装、排队并挂起的核心方法。

在这里，涉及到一个关键的无锁低开销数据结构：_cxq（Contention Queue，竞争队列） 。它是一个无锁的、单向的 LIFO（后进先出） 链表。所有刚进入慢速路径、还未获得锁的线程（称为 Recently Arrived Threads，简称 RATs），都会并发地通过 CAS 指令"挤入"这个队列的头部。

一、 `ObjectMonitor::EnterI` 核心源码分析

以下是 OpenJDK 8 中 ObjectMonitor::EnterI 方法中关于线程封装并挤压进入 _cxq 链表的核心代码片段，已为你高度还原并补充了底层系统级工程师视角的详尽注释：

cpp 复制代码

void ATTR ObjectMonitor::EnterI (TRAPS) {
    Thread * Self = THREAD ;
    
    // 检查并尝试获取锁，如果成功则直接返回
    if (TryLock (Self) > 0) return ;
    
    // 延迟初始化管程的相关数据
    DeferredInitialize () ;
    
    // 再次尝试自旋获取锁，万一这时候锁被释放了呢
    if (TrySpin (Self) > 0) return ;

    // ==========================================
    // 【核心排队逻辑：多线程并发挤压进入 _cxq 队列】
    // ==========================================

    // 1. 栈上分配 ObjectWaiter 节点，将当前线程（Self）包装其中
    // 这样做非常巧妙！因为当前线程抢不到锁即将被挂起，其栈帧（Stack Frame）在整个挂起期间都是绝对安全的，
    // 这完美免去了在堆内存（Heap）中申请节点的巨大吞吐开销和垃圾回收压力。
    ObjectWaiter node(Self) ; 
    
    // 初始化当前线程的 ParkEvent（管程挂起与唤醒的核心系统级内核事件对象）
    Self->_ParkEvent->reset() ; 
    
    // 由于 _cxq 是单向链表，只需要使用 next 指针。
    // 这里故意将 prev 指针设为一个非法死地址（0xBAD），用于 Debug 阶段防御性断言。
    node._prev = (ObjectWaiter *) 0xBAD ; 
    
    // 显式标记该节点当前所处的锁状态：TS_CXQ，代表其正在 _cxq 队列中等待
    node.TState = ObjectWaiter::TS_CXQ ; 

    ObjectWaiter * nxt ;
    
    // 2. 进入无锁死循环（CAS 自旋），直到成功将自己"挤压"进 _cxq 单向链表的头部
    for (;;) {
        // 【步骤 A：乐观读取】
        // 获取当前最新的 _cxq 链表头节点，并将其赋值给当前临时变量 nxt，同时让当前节点的 _next 指向它。
        // 这相当于让当前节点在本地做好准备：隐式地成为新的头节点，并指向老头节点。
        node._next = nxt = _cxq ; 

        // 【步骤 B：硬件级原子 CAS 替换】
        // 调用 Atomic::cmpxchg_ptr 进行原子替换。在 OpenJDK 8 中，其参数含义依次为：
        // 参数 1: &node          -> 准备写入的新值（即当前线程节点在栈上的地址）
        // 参数 2: &_cxq           -> 要修改的目标内存地址（ObjectMonitor 对象中的 _cxq 指针）
        // 参数 3: nxt            -> 预期中的旧值（我们在【步骤 A】中乐观读取到的老头节点地址）
        // 
        // 底层行为：CPU 会拦截并验证当前内存中的 *_cxq 是否仍然等于 nxt。
        // 如果等于（未变）：说明期间没有其他线程干扰，成功将 _cxq 指向 &node，并返回旧值 nxt。
        // 如果不等于（已变）：说明有其他并发线程捷足先登"挤"了进来，此时不修改内存，返回实际的最新的 _cxq 值。
        if (Atomic::cmpxchg_ptr (&node, &_cxq, nxt) == nxt) {
            // 返回值等于预期旧值，说明 CAS 成功！当前节点顺利成为 _cxq 的新头部，安全破出死循环。
            break ; 
        }

        // 【步骤 C：并发冲突缓解与"贪婪"抢锁优化】
        // 如果走到这里，说明上述 CAS 失败了（即 Atomic::cmpxchg_ptr 返回的值 != nxt）。
        // 这代表刚才发生了多线程"挤压"冲突。在重新回到循环顶部进行下一次 CAS 冲锋前，
        // HotSpot 引入了一个极其强悍的启发式优化：再次调用 TryLock 尝试偷锁。
        if (TryLock (Self) > 0) {
            // 如果运气爆棚，在这里抢锁成功，则直接退出 EnterI 方法！
            // 此时该线程连队列都不用进了，更不需要调用昂贵的系统调用去挂起（park），极大地提升了吞吐量。
            return ; 
        }
        
        // 偷锁失败，继续循环，重新读取最新的 _cxq 头部，发起下一次排队冲锋。
    }
    
    // 后续逻辑：进入等待被唤醒的阻塞状态...
}

二、多线程并发"挤压" `_cxq` 的演进全过程

为了更直观地理解多线程是如何通过 Atomic::cmpxchg_ptr 挤压该单向链表的，我们假设一个具体的并发场景：

当前 _cxq 队列中已经有一个老节点 Node_Old。
此时，有三个线程（Thread_A 、Thread_B 、Thread_C ）同时由于抢锁失败，并发进入了 EnterI 的无锁死循环中。

1. 第一阶段：并发乐观读取

三个线程在各自的 CPU 核心上并行执行到 node._next = nxt = _cxq;。

此时它们都在各自核心的寄存器/局部变量 nxt 中存下了当前的队列头 Node_Old。并且它们各自栈上的节点指针也都指向了 Node_Old：

nodeA._next = Node_Old;
nodeB._next = Node_Old;
nodeC._next = Node_Old;

2. 第二阶段：硬件级 CAS 决胜

三个线程几乎同时发起了 Atomic::cmpxchg_ptr 汇编指令（在 x86 架构下，底层会转换为带有 lock cmpxchg 前缀的单条硬件指令，该指令会触发 MESI 缓存一致性协议的独占锁或锁住总线）。

Thread_A 动作最快 ：它的 CPU 核心率先抢占了对 _cxq 内存行的修改权。CPU 发现此时内存里的 _cxq 的确等于 Node_Old，于是成功将 _cxq 的值修改为 &nodeA。Thread_A 的 CAS 宣告成功，它顺利 break 调出循环。
Thread_B 紧随其后发起 CAS ：它的指令去比对 _cxq 是否等于它预期的 Node_Old。然而此时内存中的 _cxq 已经被 Thread_A 改成了 &nodeA。CPU 判定 &nodeA != Node_Old，因此 Thread_B 的 CAS 宣告失败，内存不作修改。
Thread_C 同样发起 CAS ：它预期的旧值也是 Node_Old，与现在的真实值 &nodeA 不符，Thread_C 的 CAS 也宣告失败。

3. 第三阶段：冲突缓解与分支重试（Retry & Mitigate）

Thread_B 和 Thread_C 由于 CAS 失败，不会立刻死板地重新排队，而是先去执行 TryLock 探测锁是否恰好空闲。
假设锁依然被别人占用，TryLock 失败。Thread_B 和 Thread_C 重新回到 for(;;) 循环的顶部。
此时它们重新读取 _cxq：
nodeB._next = nxt = _cxq; -> 此时读取到的 nxt 变成了 &nodeA。
接下来，Thread_B 和 Thread_C 将在新一轮的 &nodeA 头节点基础上，重复上述的挤压竞争，直到成功将自己变为新的全局 _cxq 头部。

三、深度架构思考：为什么要这样设计？

从系统和架构的角度来看，HotSpot 在这段"挤压"逻辑中展现了极致的性能调优哲学：

栈上分配（Stack Allocation）免去 GC 开销
传统的链表队列通常需要在堆上 new ObjectWaiter()。而 HotSpot 直接在线程的 执行栈（Execution Stack） 上创建局部变量 ObjectWaiter node(Self)。由于当前线程抢不到锁即将被挂起，它的当前栈帧（Stack Frame）处于冰冻状态，绝对不会被销毁。这完美利用了线程生命周期，避免了频繁分配和回收节点的开销。
LIFO 结构完美契合单指针 CAS
为什么 _cxq 设计成后进先出（LIFO）而不是先进先出（FIFO）？因为将节点插入到单向链表的头部（Head Push），只需要变更一个 _cxq 全局指针。如果实现无锁的 FIFO，通常需要同时维护 Head 和 Tail 两个指针，在并发环境下会引发复杂的双指针同步与 ABA 问题，其算法复杂度和硬件锁竞争会呈指数级上升。
"贪婪"的临门一脚（Greedy TryLock）
在无锁编程中，CAS 失败意味着高密度的并发冲突。传统的教科书做法通常是直接重试或者退避（Backoff）。而 HotSpot 却在这里插入了一个 TryLock。这是一个非常有价值的启发式优化：当发生冲突时，意味着时间流逝了一小段，此时原本持有锁的那个老线程可能刚好执行完了同步块并释放了锁。如果能在这个间隙"顺手牵羊"拿到锁，就能完美避免后续昂贵的内核态切换（Thread Park）成本。

四、关键技术点深度总结

头插法（LIFO 栈结构） ：_cxq 本质上是一个无锁栈。新来的线程总是通过修改 _cxq 指针把自己"挤"到最前面成为新的头节点。这就是为什么 Java 的重量级锁在某些激进场景下呈现出非公平性（后来的线程反而可能先被唤醒，因为它们在栈顶）。
硬件级锁保证 ：Atomic::cmpxchg_ptr 在底层依赖具体的 CPU 指令（例如 x86 架构下的 lock cmpxchg）。它会锁定北桥总线或触发 MESI 缓存一致性协议，确保"读取-比较-替换"这三个步骤在硬件层面是不可分割的单步原子操作。
天然免疫 ABA 问题 ：在通用的无锁队列中，由于内存释放与复用，常常需要引入版本号来解决 ABA 问题。但在 HotSpot 的 EnterI 中，ObjectWaiter node 是分配在线程私有栈 上的局部变量。这意味着，只要该线程没有退出 EnterI 方法，这个内存地址绝不可能被其他线程复用。因此，HotSpot 在这里不需要任何额外的版本号或 Epoch 机制，非常干净利落地完成了无锁高并发链表的操作。

Java锁机制之Java对象重量级锁源码剖析

Java对象重量级锁源码剖析

前言

Java对象重量级锁源码剖析

一、 ObjectMonitor::EnterI 核心源码分析

二、 多线程并发"挤压" _cxq 的演进全过程

1. 第一阶段：并发乐观读取

2. 第二阶段：硬件级 CAS 决胜

3. 第三阶段：冲突缓解与分支重试（Retry & Mitigate）

三、深度架构思考：为什么要这样设计？

四、关键技术点深度总结

一、 `ObjectMonitor::EnterI` 核心源码分析

二、多线程并发"挤压" `_cxq` 的演进全过程