Java volatile重排序与可见性特性的理解正确性咨询

你的理解是正确的，这两条语句确实允许被重排序，会出现线程B观测到b=true但a=0的情况：
Java内存模型中volatile的重排序约束为：普通写操作不能重排序到volatile写操作之后，但反过来volatile写操作可以和它后面的普通写操作重排序。你给出的代码中a=10是volatile写，b=true是位于它之后的普通写，CPU或编译器完全可以把两个操作的顺序调换，先执行b=true再执行a=10，这就会导致线程B判断b==true进入分支时，a的赋值还没完成，触发assert失败。
如果要避免这个问题，需要把b声明为volatile，或者把b的赋值放到a的赋值之前，这样普通写就不会被重排序到volatile写之后了。

已完成写操作的可见性 #

你的理解是对的：硬件层面真正完成的写操作（已经离开store buffer、写入CPU缓存、完成MESI协议的失效同步），对所有CPU都是可见的，不存在不可见的问题。大家常说的“写操作不可见”，本质上是Java层面的赋值语句执行后，硬件层面写操作还没完成（滞留在store buffer、失效队列还没处理完），本质是写操作的提交被延迟了，不是已完成的写操作不可见。
你猜测的“写回寄存器而不写入缓存”的场景确实存在，编译器可能把变量值存在寄存器里复用，不会写回内存，这种情况确实没有一致性协议保证。volatile会禁止编译器做这种优化，强制要求赋值操作必须写回内存（缓存层面，不需要到主存），读操作也要从内存（缓存）读取，不能复用寄存器里的旧值。

volatile的边界作用 #

你对volatile的核心作用的理解完全正确：volatile的本质是一个同步边界，它的happens-before规则保证：线程A对volatile变量的写操作之前的所有读写操作，都对后续读取到这个volatile变量新值的线程B的所有后续操作可见。
你提到的“就算B是volatile，线程2也可能读到B=0直接结束”是正常现象，这是因为线程2读取B的时候，线程1对B的写操作还没有完成，不属于volatile可见性的覆盖范围，可见性规则只保证“如果线程B读到了volatile变量的新值，那么之前的操作都可见”，不保证写操作立刻被其他线程观测到。

“volatile必须读主存不允许本地缓存”说法正误 #

你的判断是对的，这个说法是完全错误的。
这个说法是把Java内存模型里抽象的“主内存/工作内存”概念，错误对应到了物理层面的“主存/CPU缓存”。实际JVM实现volatile语义的时候，根本不需要跳过CPU缓存，只需要在volatile写操作之前插入StoreStore屏障，写之后插入StoreLoad屏障，读操作之前插入LoadLoad和LoadStore屏障，配合CPU的MESI缓存一致性协议就可以满足语义，性能比每次读主存高得多。现在所有主流的x86、ARM架构的JVM都是这么实现的，没有直接读主存的情况。

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