• 1. 核心源码注释解析 (`synchronizer.cpp`)
• 1.1 ObjectSynchronizer::fast_enter
• 1.2 ObjectSynchronizer::slow_enter
• 2. JVM 判断与尝试轻量级锁的详细图解流程
• 第一步：状态前置检查（偏向锁拦截）
• 第二步：无锁状态下的 CAS 抢占（轻量级锁核心）
• 第三步：重入性判定（轻量级锁重入）
• 3. 对象头（Mark Word）状态转换临界点
• 总结

前言

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

轻量级锁判断与尝试逻辑源码剖析

在 OpenJDK 8 的 HotSpot 虚拟机中，对象同步（synchronized）的入口核心逻辑位于 hotspot/src/share/vm/runtime/synchronizer.cpp。

虽然用户通常关注 ObjectSynchronizer::fast_enter，但实际上 fast_enter 主要负责处理偏向锁（Biased Locking）。如果偏向锁未开启、获取失败或被撤销，JVM 会立即调用 ObjectSynchronizer::slow_enter。而轻量级锁（Lightweight Locking）的判断与尝试，正是 slow_enter 的核心职责。只有当轻量级锁尝试失败或发生锁竞争时，JVM 才会调用 ObjectSynchronizer::inflate 膨胀为重量级锁。

以下是完整的执行流、源码及深度注释解析。

1. 核心源码注释解析 (synchronizer.cpp)

1.1 ObjectSynchronizer::fast_enter

这是 Java 字节码 monitorenter 在运行时的第一站。

void ObjectSynchronizer::fast_enter(Handle obj, BasicLock* lock, bool attempt_rebias, TRAPS){
// 1. 判断是否开启了偏向锁虚拟机参数 (-XX:+UseBiasedLocking)
if (UseBiasedLocking) {
if (!SafetyChecks) {
// 如果不在安全点，进行一些必要的安全检查
runtime_verify_locks();
    }

// 尝试获取偏向锁或进行偏向锁撤销
    BiasedLocking::Condition cond = BiasedLocking::revoke_and_rebias(obj, attempt_rebias, THREAD);

// 如果成功获取了偏向锁或成功重偏向，则直接返回，不再向下执行轻量级锁逻辑
if (cond == BiasedLocking::BIAS_REVOKED_AND_REBIASED) {
return;
    }
  }

// 2. 如果偏向锁未开启、或者偏向锁尝试失败/被撤销，则进入 slow_enter
// 核心的“轻量级锁”尝试与判断全在这里面
slow_enter (obj, lock, THREAD) ;
}

1.2 ObjectSynchronizer::slow_enter

在这个方法中，JVM 正式开始判断并尝试进行轻量级锁的获取。

void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS){
// 读取对象头中的 Mark Word
  markOop mark = obj->mark();

// 断言：此时 Mark Word 的偏向标记位绝对不应该为 1 (已经在 fast_enter 或撤销流程中处理完毕)
assert(!mark->has_bias_pattern(), "should not see bias pattern here");

// ------------------------------------------------------------------
// 核心判断一：判断目标对象是否处于“无锁状态”（Neutral State）
// 无锁状态的特征：Mark Word 后三位为 001（即 hash:25 | age:4 | biased_lock:0 | lock:01）
// ------------------------------------------------------------------
if (mark->is_neutral()) {

// 【尝试轻量级锁步骤 A】：在当前线程的栈帧（Stack Frame）中构建一个锁记录（BasicLock）
// 将当前无锁对象的 Mark Word 复制到线程栈的 displaced_header 中保存
    lock->set_displaced_header(mark);

// 【尝试轻量级锁步骤 B】：利用 CAS 尝试将对象头（Mark Word）替换为指向当前线程栈中 BasicLock 的指针
// 如果成功，说明没有竞争，当前线程成功升级并持有该对象的轻量级锁
if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark)) {
TEVENT (slow_enter: fast path success) ;
return; // 成功获取轻量级锁，直接返回，避免了重量级锁的开销
    }
// 如果 CAS 失败，说明在此期间有其他线程竞争，或者状态发生改变，直接落入下方进行膨胀

// ------------------------------------------------------------------
// 核心判断二：判断是否为“锁重入”（Reentrant Locking）
// 如果对象已经处于轻量级锁状态（后两位为 00），且该锁指针指向当前线程的栈范围内
// ------------------------------------------------------------------
  } else if (mark->has_locker() && THREAD->is_lock_owned((address)mark->locker())) {

// 断言检查：确保不是重复锁同一个 BasicLock 实例
assert(lock != mark->locker(), "must not re-lock the same BasicLock");
assert(lock->displaced_header()->is_neutral(), "must be neutral");

// 【锁重入优化】：对于轻量级锁的重入，HotSpot 采用将 displaced_header 设置为 NULL 的简便标记法
// 解锁时如果发现是 NULL，说明是重入释放，直接弹栈即可，无需写回对象头
    lock->set_displaced_header(NULL);
return; // 成功处理轻量级锁重入，返回
  }

// ------------------------------------------------------------------
// 走到这里，说明上述轻量级锁的尝试【全部失败】：
// 1. 对象非无锁状态（可能已经是重量级锁，或者已被其他线程抢占为轻量级锁）
// 2. 发生竞争，CAS 替换失败
// 3. 也不是当前线程的锁重入
// ------------------------------------------------------------------

// 在膨胀前，出于安全考虑，将当前栈中锁记录的 displaced_header 设置为一个不可用的标记位
  lock->set_displaced_header(markOopDesc::unused_mark());

// 【激进化/膨胀】：正式调用 inflate 方法，将轻量级锁升级为重量级锁（ObjectMonitor）
// 并调用 enter() 让当前线程进入 Monitor 的等待队列或自旋等待
  ObjectSynchronizer::inflate(THREAD, obj())->enter(THREAD);
}

2. JVM 判断与尝试轻量级锁的详细图解流程

根据上述源码，JVM 在决定动用重量级锁（ObjectMonitor）之前，有着非常严密的三步式判断逻辑：

第一步：状态前置检查（偏向锁拦截）

在 fast_enter 中，JVM 首先检查 -XX:+UseBiasedLocking 是否开启。

• 如果开启，JVM 试图通过无因果关系的指针更替（CAS 线程 ID）来实现偏向锁。
• 如果发现偏向锁失效（比如其他线程曾持有过该锁导致偏向被撤销），或者发生竞争导致撤销，JVM 会清理掉偏向标记（将 Mark Word 的最后 3 位从 101 变更为 001），随后将其送入 slow_enter。

第二步：无锁状态下的 CAS 抢占（轻量级锁核心）

进入 slow_enter 后，第一件事就是通过 mark->is_neutral() 判断最后两位是否为 01。

• 为什么是无锁才尝试轻量级锁？ 因为轻量级锁的设计初衷是假设“在绝大多数情况下，同步块内不存在实质性的竞争”。
• 如何尝试？ 1. 线程在自己的栈帧中分配一个 BasicLock（锁记录空间）。

1. 把对象当前的 Mark Word 备份到 BasicLock 的 displaced_header 中（这是为了在未来解锁时能够完美还原对象头）。
2. 执行 Atomic::cmpxchg_ptr 原子指令。这一步试图将对象头的 Mark Word 刷新为指向该线程栈中 BasicLock 的物理内存地址，同时锁标志位变成 00（轻量级锁状态）。
3. 结果导向：如果成功，就此返回，整个加锁过程只消耗了一次内存复制和一次原子 CAS 指令，完美避开了操作系统级别的互斥量（Mutex）。

第三步：重入性判定（轻量级锁重入）

如果第二步的 CAS 失败了，JVM 并不会马上升级重量级锁，它会进一步求证：“这个锁是不是我自己持有的？”

• 通过 mark->has_locker() 确认对象头当前是否正处于轻量级锁状态（后两位为 00）。
• 通过 THREAD->is_lock_owned((address)mark->locker()) 判定对象头里存储的那个指针地址，是否落在了当前线程的栈空间最高点和最低点之间。
• 如果都在范围内，说明是当前线程发生了锁重入。JVM 此时只需向栈中再压入一个 displaced_header 为 NULL 的 BasicLock 即可，宣告轻量级锁重入成功。

3. 对象头（Mark Word）状态转换临界点

为了彻底理解源码中的 is_neutral() 和状态转换，以下是 HotSpot 中 Mark Word 在各个阶段的位分布特征（以 64 位虚拟机为例）：

总结

JVM 在做出“膨胀为重量级锁”这个沉重决定之前，会利用轻量级锁做最后的努力。其核心判断准则是：只要对象目前没有被其他线程实质性占用（无锁），就用 CAS 赌一把将其转化为轻量级锁；即使被占用了，如果发现占用者是自己，就通过简化的栈记录（NULL displaced header）来实现快速重入。 只有当这两项尝试全部宣告失败（即存在多线程真正的交替竞争或同时抢占），JVM 才会死心塌地地调用 inflate 走向重量级锁。