volatile关键字不直接生成lock指令，而是由jvm通过内存屏障实现语义；x86平台常以lock addl $0, (%rsp)这类轻量指令触发缓存一致性协议并提供全屏障效果。
Java 中 volatile 关键字本身不直接生成特定汇编指令，它的语义由 JVM 在运行时通过插入内存屏障（Memory Barrier）来实现，而这些屏障在 x86 等硬件平台常被 JIT 编译器编译为带 lock 前缀的轻量指令——最典型的是 lock addl $0, (%rsp)。这不是对变量加锁，而是利用 CPU 的缓存锁定机制触发全内存屏障效果。
如何观察 volatile 对应的汇编代码
要真实看到 volatile 读写生成的汇编，需满足几个前提：
- 使用 HotSpot JVM（如 OpenJDK），开启
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly - 确保代码被 JIT 编译（避免解释执行），可通过
-XX:CompileThreshold=1强制快速编译 - 禁用 TieredCompilation（
-XX:-TieredCompilation）或使用 C2 编译器 - 确保目标方法足够“热”，例如循环调用 volatile 读写操作
x86 平台下典型的汇编表现
在 x86-64 上，HotSpot JIT（C2）通常这样处理：
-
volatile 写操作：先执行普通写（如
mov DWORD PTR [rdx+0x10], 1），再插入lock addl $0, (%rsp)—— 这条指令不改变栈内容（%rsp 加 0），但lock前缀强制刷新 store buffer，并使当前写对其他核心可见 -
volatile 读操作：多数情况下仅用普通
mov（因 x86 读天然具有 acquire 语义），但为跨平台一致性或应对某些边界场景，JIT 可能仍插入lock addl $0, (%rsp)或mfence - 注意：
lock addl $0, (%rsp)是全屏障（full barrier），等效于mfence，但更轻量，尤其在老款 CPU 上
不是所有 volatile 都有 lock 指令
是否生成 lock 指令取决于多个因素：
- CPU 架构：ARM 平台用
dmb ish或dsb sy替代lock；RISC-V 用fence rw,rw - JVM 版本与优化策略：较新版本可能省略冗余屏障，比如后续无普通读时跳过
StoreLoad - 变量访问模式：单线程访问、逃逸分析判定无竞争时，JIT 可能完全消除 volatile 语义（即去虚拟化）
- 是否涉及 final 字段重排序：volatile + final 组合会触发额外屏障，但不增加 lock 指令
关键点：别把内存屏障等同于 lock 指令
volatile 的本质是内存语义（可见性 + 禁止重排序），而非具体指令：
- JVM 规范未规定必须用
lock，只规定必须满足 happens-before 和缓存一致性要求 -
lock addl $0, (%rsp)是 x86 下一种高效实现方式，不是唯一方式 - 真正起作用的是它触发的 MESI 协议行为（如 Invalidate 其他核缓存行）和内存屏障语义，不是“加锁”动作本身
- 如果看到汇编里没有
lock，不代表 volatile 失效——可能是用了mfence，或被 JIT 优化掉了（需结合 hsdis 输出与 JMM 行为验证）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
