Java锁膨胀机制之无锁到偏向锁源码剖析

前言

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

无锁到偏向锁源码剖析

核心概念：修正“无锁 -> 偏向锁”的常见误区

在深入 OpenJDK 8 源码之前，必须首先理清楚HotSpot 虚拟机内部对“无锁”状态的精细划分。

我们通常将锁升级路径简单描述为：普通无锁 (001) -> 偏向锁 (101)。这在 HotSpot 的实际实现中是一个普遍的误区。

事实上，在 JVM 中，一个单纯处于普通无锁状态（锁标志位 01，偏向标志位 0，即001）的对象，是无法通过单条线程的加锁操作直接“升级”或“转换”为偏向锁的。如果一个对象的 Mark Word 是001，当某个线程尝试对其加锁时，JVM 会直接跳过偏向锁逻辑，通过 CAS 将其升级为轻量级锁（00）。

真正的偏向锁引入路径依赖于匿名偏向（Anonymous Biased）状态。当 JVM 启用了偏向锁（-XX:+UseBiasedLocking，JDK 8 默认在启动时激活该配置项），新分配出的对象其对象头标准格式即为101，但内部的 Thread ID 此时为0。

• 真正的路径是：匿名偏向状态 (101, ThreadID=0) -> 已偏向状态 (101, ThreadID=有效本地线程指针)。

以下结合 OpenJDK 8 源码，对该状态的初始化、判定以及转换的完整架构进行深度剖析。

一、 基石定义：Mark Word 内存布局与状态判定

涉及文件：hotspot/src/share/vm/oops/markOop.hpp

markOop（在 64 位系统下本质是uint64_t指针的别名）定义了对象头的 Mark Word 结构。为了高效判定，源码中通过位掩码（Bit Masks）和枚举来实现对匿名偏向及偏向状态的快速识别。

以下是markOop.hpp中的核心源码片段及深度注释：

// 文件路径：hotspot/src/share/vm/oops/markOop.hppclassmarkOopDesc:publicoopDesc{public:// 1. 定义锁状态的底层常量标志位enum{locked_value=0,// 00: 轻量级锁unlocked_value=1,// 01: 普通无锁状态（未激活偏向）monitor_value=2,// 10: 重量级锁marked_value=3,// 11: GC 标记状态biased_lock_pattern=5// 101: 偏向锁特征码（包含1位偏向标志 + 2位锁标志）};// 2. 位数及掩码定义（以64位架构为例）enum{age_bits=4,// 分代年龄占4位lock_bits=2,// 锁标志位占2位biased_lock_bits=1,// 偏向锁标志位占1位max_hash_bits=31,// HashCode占31位hash_bits=31,epoch_bits=2// 偏向周期 Epoch 占2位};// 3. 核心判定函数：检查当前 Mark Word 是否符合偏向锁模式 (即后三位是否为 101)boolhas_bias_pattern()const{// biased_lock_mask_in_place 是后三位全为1的掩码 (7)// 逻辑：将当前值与 7 进行与运算，判断结果是否等于 5 (biased_lock_pattern)return(mask_bits(value(),biased_lock_mask_in_place)==biased_lock_pattern);}// 4. 核心提取函数：从 Mark Word 中解包出持有锁的 JavaThread 线程指针JavaThread*biased_locker()const{assert(has_bias_pattern(),"必须在确认是偏向模式下才能调用此方法");// 64位架构下，前54位存储的是 JavaThread 的内存地址// 逻辑：通过位掩码清除掉 Epoch、Age、Biased位和Lock位，直接转型为指针return(JavaThread*)((address)value()&~(biased_lock_mask_in_place|age_mask_in_place|epoch_mask_in_place));}// 5. 辅助判定：判断是否为匿名偏向（即后三位是101，且前54位线程ID全为0）boolis_biased_anonymously()const{return(has_bias_pattern()&&biased_locker()==NULL);}};

二、 锁初始化：原型请求头的确立

涉及文件：hotspot/src/share/vm/oops/klass.hpp

既然普通无锁（001）无法直接变成偏向锁（101），那么对象是如何获得101初始状态的？答案在Klass类中。每一个 Java 类在 JVM 内部被加载时，都会包含一个原型对象头_prototype_header。

// 文件路径：hotspot/src/share/vm/oops/klass.hppclassKlass:publicMetadata{friendclassVMStructs;protected:// 每一个类元数据中都保存了一个原型 Mark Word// 当实例分配（new 实例）时，直接拷贝此值作为新对象的对象头markOop _prototype_header;public:markOopprototype_header()const{return_prototype_header;}voidset_prototype_header(markOop header){_prototype_header=header;}};

• 运行机制：在 JVM 启动的前 4 秒内（如果没有通过参数修改），Klass::_prototype_header被初始化为001（普通无锁）。因此这段时间内new出来的对象全部无法使用偏向锁。
• 当偏向锁激活延迟结束后，VM 线程会执行一个安全点任务，将后续加载的类的_prototype_header修改为101（此时 Thread ID 字段填充为 0）。此后新创建的对象一出生就处于匿名偏向状态。

三、 顶层入口：快速路径与慢速路径分流

涉及文件：hotspot/src/share/vm/runtime/synchronizer.cpp

当解释器或 JIT 编译器执行到monitorenter字节码指令，且无法在汇编层面的 Fast Path（汇编快速路径）直接解决时，会强制下沉调用 C++ 层的运行时同步器ObjectSynchronizer。

// 文件路径：hotspot/src/share/vm/runtime/synchronizer.cppvoidObjectSynchronizer::fast_enter(Handle obj,BasicLock*lock,boolattempt_rebias,TRAPS){// 检查是否开启了 -XX:+UseBiasedLocking 参数if(UseBiasedLocking){// 确保当前不处于全局安全点（Safepoint）if(!SafepointSynchronize::is_at_safepoint()){// 调用偏向锁核心机能函数，尝试获取或重偏向BiasedLocking::Condition cond=BiasedLocking::revoke_and_rebias(obj,attempt_rebias,THREAD);// 如果返回状态是 BIAS_REVOKED_AND_REBIASED，说明成功执行了偏向操作（或成功隐式重入）if(cond==BiasedLocking::BIAS_REVOKED_AND_REBIASED){return;// 直接返回，免去后续轻量级锁的开销}}else{// 安全点下的特殊撤销assert(SafepointSynchronize::is_at_safepoint(),"must be at safepoint");BiasedLocking::revoke_at_safepoint(obj);}}// 【核心分流点】// 如果对象是普通无锁状态(001)，has_bias_pattern()将返回false，上面的revoke_and_rebias会直接返回常规状态。// 程序将直接步入 slow_enter，并在内部直接通过 CAS 转换为轻量级锁 (00)slow_enter(obj,lock,THREAD);}

四、 核心蜕变：revoke_and_rebias的原子状态机

涉及文件：hotspot/src/share/vm/runtime/biasedLocking.cpp

BiasedLocking::revoke_and_rebias是处理偏向锁获取、重偏向和撤销的核心状态机。对于匿名偏向 -> 已偏向的转换，整个逻辑完全基于无锁的用户态 CAS 完成，绝不涉及内核态切换。

以下是高度精简并附带详尽注释的实现源码：

// 文件路径：hotspot/src/share/vm/runtime/biasedLocking.cppBiasedLocking::ConditionBiasedLocking::revoke_and_rebias(Handle obj,boolattempt_rebias,TRAPS){assert(!SafepointSynchronize::is_at_safepoint(),"此方法专为非安全点下的快速互斥设计");// 1. 读取当前对象头markOop mark=obj->mark();// 2. 检查该对象是否具备偏向锁特征（后三位是否为 101）if(mark->has_bias_pattern()){// 获取当前试图加锁的本地 JavaThread 指针JavaThread*bl_thread=mark->biased_locker();// 【分支 A：匿名偏向状态】—— 对应首次加锁（Thread ID 为 0）if(bl_thread==NULL){if(!attempt_rebias){// 如果不允许重偏向（比如禁用了该类的偏向），则进入撤销逻辑returnBIAS_REVOKED;}// 1. 基于当前对象的 Age 和所属类的 Epoch，构建一个期望偏向当前线程的全新 Mark WordmarkOop prototype=markOopDesc::biased_lock_prototype()->set_age(mark->age());// encode 宏负责将本地 JavaThread 指针拼接到高 54 位中markOop biased_mark=markOopDesc::encode(THREAD,prototype->age(),prototype->bias_epoch());// 2. 核心操作：通过 CPU 级的原子 CAS 指令尝试写回对象头// 期望值：原 mark（匿名偏向）；替换目标值：biased_mark（偏向当前线程）markOop res_mark=(markOop)Atomic::cmpxchg_ptr(biased_mark,obj->mark_addr(),mark);// 3. 如果返回值 res_mark 等于原本的 mark，说明在没有竞争的情况下 CAS 成功if(res_mark==mark){// 成功将匿名偏向状态 (101, ID=0) 转换为已偏向状态 (101, ID=CurrentThread)returnBIAS_REVOKED_AND_REBIASED;}// 如果 CAS 失败，说明在此瞬间有其他线程抢先写入了它的 Thread ID，存在并发竞争，降级去处理冲突}// 【分支 B：已经偏向了当前线程】—— 对应偏向锁的可重入加锁elseif(bl_thread==THREAD){// 如果当前 Mark Word 内记录的 Thread ID 刚好就是我自己// 偏向锁的核心优势在此体现：不需要任何原子操作（CAS），不需要修改对象头，直接通过returnBIAS_REVOKED_AND_REBIASED;}// 【分支 C：Epoch 过期，触发批量重偏向】// 如果类的 prototype_header 里的 epoch 改变了，说明引发了批量操作，允许当前线程重新偏向if(mark->bias_epoch()!=obj->klass()->prototype_header()->bias_epoch()){if(attempt_rebias){// 构建带有新 Epoch 且偏向当前线程的 Mark WordmarkOop prototype=obj->klass()->prototype_header()->set_age(mark->age());markOop rebiased_mark=markOopDesc::encode(THREAD,prototype->age(),prototype->bias_epoch());// 尝试 CAS 重新偏向if(Atomic::cmpxchg_ptr(rebiased_mark,obj->mark_addr(),mark)==mark){returnBIAS_REVOKED_AND_REBIASED;}}}// 【分支 D：偏向冲突】—— 已经偏向了其他线程// 运行到这里，说明对象头中的 Thread ID 不为 0 且不是当前线程，意味着多个线程交替/同时进入同步块// 偏向锁宣告失效，此时必须启动复杂的撤销（Revocation）流程，这通常需要等待全局安全点（Safepoint）// 来暂停原持有偏向锁的线程，并将其锁状态一举推高至轻量级锁（00）或普通无锁（001）}// 如果根本没有偏向锁模式（比如标准的普通无锁001），直接返回 NOT_BIASED 告知上层走慢速路径returnNOT_BIASED;}

五、 详细执行过程总结（系统视角）

当 Java 线程执行到一条synchronized(obj)代码块时，从无锁（匿名偏向）到偏向锁的底层调用链和数据状态变换如下：

[Java 线程执行 synchronized(obj)] │ ▼ [激活检查] - 检查全局选项 -XX:+UseBiasedLocking 且已过延迟期 │ ▼ [获取 Mark Word] - 读取 obj->mark()，检查后三位是否为 101 (has_bias_pattern) │ ├──► [情况一：如果是 001 (普通无锁)] │ │ │ ▼ │ 跳过整个偏向锁机制，直接进入 ObjectSynchronizer::slow_enter │ 使用 CAS 尝试将对象头修改为轻量级锁指针 (状态变为 00) │ └──► [情况二：如果是 101 (偏向模式)] │ ▼ [检查高54位 Thread ID] │ ├──► [Thread ID == 当前线程指针] (偏向重入) │ │ │ ▼ │ 不执行任何 CAS 和总线锁，直接放行，执行同步块代码 │ └──► [Thread ID == 0] (匿名偏向状态) │ ▼ [执行原子 CAS 替换] 将当前线程的真实指针填入高54位 (Atomic::cmpxchg_ptr) │ ├──► [CAS 成功] │ │ │ ▼ │ 成功确立偏向锁关系，无锁状态结束，直接进入同步块 │ └──► [CAS 失败] (遭遇并发竞争) │ ▼ 进入偏向锁撤销流程， 在安全点（Safepoint）将锁膨胀为轻量级锁（00）

设计亮点思考

1. 零总线锁开销：在已偏向当前线程的情况下（分支 B），HotSpot 成功将同步操作的开销压低到了“判定几条 CPU 寄存器标志位”的级别，完全绕过了传统的 X86LOCK前缀总线指令。
2. 防御性膨胀：通过区分001和101，JVM 保证了那些由于计算过hashCode()（会导致偏向锁位被强占，无法存储 Thread ID）或处于高度并发类的对象，不会无谓地在偏向锁逻辑中自旋或尝试，而是直接通过轻量级锁快速沉淀到更稳健的锁状态。