重量级锁升级后不再依赖自旋或cas，而是交由操作系统互斥量管理；jit编译后调用objectmonitor::enter/exit，最终映射为pthread_mutex_lock等系统原语，汇编中无lock cmpxchg循环，仅含分支跳转与函数调用。
synchronized 代码块在 JIT 编译后，若升级为重量级锁（Inflated Lock），其底层不再依赖自旋或 CAS，而是交由操作系统互斥量（如 pthread_mutex 或 Windows Critical Section）管理。此时生成的汇编指令中，不会直接出现 lock cmpxchg，而是调用 JVM 内部的 ObjectMonitor::enter / exit 函数，最终映射为系统级锁原语。
重量级锁触发条件
当轻量级锁自旋失败、竞争激烈或锁持有时间较长时，JVM 会将对象头中的锁标志位设为 0b10（重量级锁），并将 Monitor 对象关联到该对象。此后所有线程进入 synchronized 块时，必须通过 Monitor 的 entry list 等待，而非忙等。
- 对象头 Mark Word 中的锁状态位变为 10（即 inflated）
- Monitor 对象被分配在堆外（C++ new 出的 ObjectMonitor 实例），包含 _owner、_EntryList、_WaitSet 等字段
- JIT 编译器识别到该锁已膨胀，会内联或直接调用 InterpreterRuntime::monitorenter（HotSpot 中）
JIT 后典型汇编行为（x86-64，Linux HotSpot 21+）
以 synchronized(obj) { ... } 为例，JIT 编译后的关键路径不包含用户可见的 lock 指令序列，而是：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 先检查对象头是否为 inflated 状态（mov + test + jz 跳转）
- 若已膨胀，则调用
ObjectMonitor::enter，该函数内部会执行：
– 尝试原子获取 _owner 字段（cmpxchg 指令，但仅用于设置 owner，非循环自旋）
– 获取失败则调用pthread_mutex_lock（Linux 下）或EnterCriticalSection（Windows） - 退出时调用
ObjectMonitor::exit，同样委托给 OS 互斥量解锁逻辑
也就是说，真正承担阻塞/唤醒语义的是操作系统原语，而非 CPU 指令级的 lock 前缀操作。lock cmpxchg 仅出现在偏向锁撤销或轻量级锁尝试阶段，一旦膨胀完成，它就退居幕后。
如何验证？
可通过以下方式观察真实汇编：
- 启动 JVM 加参数：
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=print,*YourClass.yourMethod - 确保使用 hsdis 插件，并运行足够多次使方法被 C2 编译
- 搜索关键词：
call.*monitorenter或call.*ObjectMonitor::enter，而非 lock cmpxchg - 配合 JOL（Java Object Layout）确认对象头已为 0x000000000000000d（mark word 高位含 inflated 标志）
为什么不是纯汇编实现？
重量级锁本质是线程挂起与唤醒，这涉及调度器介入、上下文切换、内核态转换——这些无法靠单条 CPU 指令完成。JVM 把这部分交给 OS，既保证语义正确，又避免重复造轮子。所以 JIT 不会“生成 lock cmpxchg 循环”，而是生成对 Monitor 接口的高效调用，让汇编层聚焦于分支预测、寄存器分配和调用约定优化。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
