夜雨聆风- 无锁到偏向锁源码剖析
- 核心概念：修正“无锁 -> 偏向锁”的常见误区
- 一、 基石定义：Mark Word 内存布局与状态判定
- 二、 锁初始化：原型请求头的确立
- 三、 顶层入口：快速路径与慢速路径分流
- 四、 核心蜕变：`revoke_and_rebias` 的原子状态机
- 五、 详细执行过程总结（系统视角）
前言
本文旨在记录近期研读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.hpp
class markOopDesc: public oopDesc {
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)
bool has_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）
bool is_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.hpp
class Klass : public Metadata {
friend class VMStructs;
protected:
// 每一个类元数据中都保存了一个原型 Mark Word
// 当实例分配（new 实例）时，直接拷贝此值作为新对象的对象头
markOop _prototype_header;
public:
markOop prototype_header() const{ return _prototype_header; }
void set_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.cpp
void ObjectSynchronizer::fast_enter(Handle obj, BasicLock* lock, bool attempt_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.cpp
BiasedLocking::Condition BiasedLocking::revoke_and_rebias(Handle obj, bool attempt_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) {
// 如果不允许重偏向（比如禁用了该类的偏向），则进入撤销逻辑
return BIAS_REVOKED;
}
// 1. 基于当前对象的 Age 和所属类的 Epoch，构建一个期望偏向当前线程的全新 Mark Word
markOop 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)
return BIAS_REVOKED_AND_REBIASED;
}
// 如果 CAS 失败，说明在此瞬间有其他线程抢先写入了它的 Thread ID，存在并发竞争，降级去处理冲突
}
// 【分支 B：已经偏向了当前线程】—— 对应偏向锁的可重入加锁
else if (bl_thread == THREAD) {
// 如果当前 Mark Word 内记录的 Thread ID 刚好就是我自己
// 偏向锁的核心优势在此体现：不需要任何原子操作（CAS），不需要修改对象头，直接通过
return BIAS_REVOKED_AND_REBIASED;
}
// 【分支 C：Epoch 过期，触发批量重偏向】
// 如果类的 prototype_header 里的 epoch 改变了，说明引发了批量操作，允许当前线程重新偏向
if (mark->bias_epoch() != obj->klass()->prototype_header()->bias_epoch()) {
if (attempt_rebias) {
// 构建带有新 Epoch 且偏向当前线程的 Mark Word
markOop 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) {
return BIAS_REVOKED_AND_REBIASED;
}
}
}
// 【分支 D：偏向冲突】—— 已经偏向了其他线程
// 运行到这里，说明对象头中的 Thread ID 不为 0 且不是当前线程，意味着多个线程交替/同时进入同步块
// 偏向锁宣告失效，此时必须启动复杂的撤销（Revocation）流程，这通常需要等待全局安全点（Safepoint）
// 来暂停原持有偏向锁的线程，并将其锁状态一举推高至轻量级锁（00）或普通无锁（001）
}
// 如果根本没有偏向锁模式（比如标准的普通无锁001），直接返回 NOT_BIASED 告知上层走慢速路径
return NOT_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）
设计亮点思考
零总线锁开销： 在已偏向当前线程的情况下（分支 B），HotSpot 成功将同步操作的开销压低到了“判定几条 CPU 寄存器标志位”的级别，完全绕过了传统的 X86 LOCK前缀总线指令。防御性膨胀： 通过区分 001和101，JVM 保证了那些由于计算过hashCode()（会导致偏向锁位被强占，无法存储 Thread ID）或处于高度并发类的对象，不会无谓地在偏向锁逻辑中自旋或尝试，而是直接通过轻量级锁快速沉淀到更稳健的锁状态。
