volatile底层不锁总线，而是通过lock前缀指令触发缓存行刷新与MESI协议失效机制，确保变量修改对其他核心立即可见，但不保证原子性。
Java 中 volatile 关键字在底层并不直接“锁住”缓存行，而是通过生成带 lock 前缀的汇编指令（如 lock addl $0, (%rsp)）来触发硬件级的缓存一致性机制。它不靠软件加锁，也不阻塞其他 CPU 核心执行，而是依赖现代 CPU 的缓存协议协同完成可见性保障。
lock 指令实际不锁总线，而是触发缓存行刷新与失效
从 Intel P6 架构（1995 年起）开始，lock 前缀不再默认锁总线，而是优先采用“缓存锁定”（Cache Locking）：
- 当目标变量已在当前 CPU 的 L1/L2 缓存中命中，且对应缓存行为可写（Exclusive 或 Modified 状态），
lock指令会直接将该缓存行内容写回主内存，并向其他核心广播“该缓存行已修改”信号； - 其他 CPU 核心收到信号后，通过 MESI 协议将自己缓存中同地址的缓存行状态置为 Invalid（无效）；
- 下次这些核心读取该变量时，发现缓存行无效，就必须重新从主内存或拥有最新副本的 CPU 缓存中加载——从而保证看到最新值。
为什么说是“锁缓存行”，而不是“锁数据”
这里的“锁”是逻辑上的原子性保障，不是互斥锁意义上的长期占用：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 缓存行是 CPU 缓存最小操作单位（通常 64 字节），
lock操作作用于整个缓存行，而非单个变量； - 即使只改一个
volatile int（4 字节），也会使整块 64 字节缓存行被标记为需同步； - 若多个无关变量落在同一缓存行（即“伪共享”），一次
volatile写会导致其他变量所在缓存行也被频繁失效，影响性能。
硬件如何确保这个过程原子且及时
关键依赖两个底层支撑：
立即学习“Java免费学习笔记（深入）”；
-
Store Buffer 与 Store Forwarding：CPU 写操作先入 store buffer 异步刷出，
lock指令会强制清空 store buffer 中相关条目，保证写立即对其他核心可见； - 环形总线（Ring Bus）+ MESI 协议嗅探（Snooping）：各核心通过高速片上互连实时监听总线/缓存请求，一旦检测到某缓存行被修改，立刻作废本地副本——这种“嗅探”是毫微秒级的硬件行为，无需软件干预。
和 CAS 的 lock 有何区别
CAS（如 CMPXCHG）本身也隐含 lock 语义，但它是针对读-改-写复合操作的原子保障；而 volatile 的 lock 仅用于单次写操作的可见性刷新，不保证读-改-写原子性。两者都走同一套硬件路径（缓存行锁定 + MESI），但触发场景和语义不同。
