Java volatile字段可见性原理及常见认知误区问询

1. 已提交的缓存写操作是否会对其他CPU不可见？ #

只要写操作确实已经提交到CPU缓存、符合MESI协议一致性要求，就一定会对其他CPU可见。存放在store buffer中的写入属于未完成的pending操作，不属于已提交的写，这类操作对其他线程不可见是正常的硬件优化结果。

2. 写结果是否可能仅存寄存器不进入缓存？volatile是否会禁止该行为？ #

• 普通变量会被编译器优化分配到寄存器，仅保留寄存器副本不写入内存/缓存，这是普通变量可见性问题的常见来源之一。
• volatile会禁止编译器做这类优化：编译器必须保证volatile变量的写入最终会落到内存层级（至少到CPU缓存），不能仅保留寄存器副本。注意这不是禁止CPU用寄存器加载volatile变量，只是禁止把变量的唯一更新副本留在寄存器不回写。

3. 示例代码的可见性问题本质 #

// 初始值 A=0,B=0
// 线程1执行
A=1; B=2;
// 线程2执行
if(B==2) {
    // 此处A可能为0
}

该现象的核心是硬件层面的内存重排序：CPU不会等待store buffer中的写入全部提交到缓存再执行后续指令，所以线程1对B的写入可能比A的写入先被其他线程观测到，和编译器重排无关。

4. volatile的作用边界 #

volatile的可见性能力是基于happens-before规则的边界约束：

线程A中对volatile变量的写操作之前的所有写操作，都对线程B中该volatile变量的读操作之后的所有操作可见。
它不是保证volatile变量的写入瞬间被所有线程感知，而是当其他线程确实读取到该volatile变量的最新值时，能同步拿到写volatile之前的所有更新。

5. 常见错误说法验证 #

“volatile会要求JVM线程每次都从主内存读取变量值，不做本地缓存”的说法是完全错误的。
这个说法是对JMM抽象模型的误读：实际硬件层面volatile依赖内存屏障实现一致性，不会禁用CPU缓存，只是通过屏障指令强制刷写store buffer、处理失效队列，基于MESI协议保证缓存一致性，全程不需要每次都访问主内存，性能远高于直接读写主内存。 #

内容的提问来源于stack exchange，提问作者pythonHua