无竞争场景下HotSpot JVM同步方法运行时原理疑问

嘿，我来帮你捋清楚这两个关于Java 8 HotSpot Server VM中synchronized反汇编的细节问题，都是很核心的锁机制知识点：

1. 为什么反汇编中存在多条lock cmpxchg %rbx,(%rsi)指令？ #

你看到的这几条lock cmpxchg指令，其实对应了HotSpot锁升级流程中不同状态的锁获取逻辑——偏向锁、轻量级锁、重量级锁的分支处理代码。

Java 8中偏向锁是默认开启的，HotSpot的C1编译器（你用-server模式启动，初始编译会用C1，后续可能触发C2优化）会提前把锁的所有可能处理路径都编译进代码里：

• 第一条可能对应偏向锁的CAS尝试获取
• 后续的则对应轻量级锁膨胀、重量级锁竞争的处理逻辑

虽然跳转指令看起来会跳过部分代码，但这些指令是为不同运行场景准备的：当程序运行时，JVM会根据当前锁的实际状态（比如是否被偏向、是否有竞争），通过分支跳转到对应的处理逻辑，未被选中的分支代码不会被执行，但它们提前存在于编译后的代码段中，避免了运行时动态生成代码的开销，是JVM的一种预优化策略。

2. and $0x7,%rbx操作的作用，以及rbx寄存器的内容 #

首先，rbx寄存器此时存储的是App类对象的Mark Word——Mark Word是对象头的核心部分，用来存储锁状态、哈希码、偏向线程ID、GC标记等关键信息。

而and $0x7,%rbx这个操作是提取Mark Word的低3位，因为HotSpot里Mark Word的低3位是锁状态的标识位：

• 001：无锁/偏向锁状态
• 000：轻量级锁状态
• 100：重量级锁状态
• 101：GC标记状态

这个操作的目的就是获取当前锁的状态，后续的跳转逻辑会根据这个结果，决定进入哪一条锁处理分支（比如尝试偏向锁获取、轻量级锁加锁，或者膨胀到重量级锁）。

内容的提问来源于stack exchange，提问作者St.Antario