Java volatile关键字单变量可见性相关疑问求解

第一个基础问题：无volatile修饰时订阅者是否会无限卡在while循环 #

是，完全有可能，原因有两点：

• JVM的即时编译器（JIT）可能对循环进行激进优化：如果检测到ready变量在当前线程内没有被修改，会直接将while (!ready) {}优化为等价的if (!ready) { while(true) {} }，后续永远不会重新读取ready的最新值
• 即使没有JIT优化，Java内存模型（JMM）允许线程将变量缓存在寄存器或者CPU本地缓存中，不会主动同步主存的最新修改，订阅者线程可能永远读不到发布者线程对ready的更新

你的三个具体问题解答 #

1. 「立即可见」的具体含义

Java内存模型中说的volatile修改立即可见，是编程语言规范层面的逻辑保证，不是物理层面的零延迟：

• volatile的写操作是原子的，写操作完全执行完成之前，所有读操作都只会读到旧值
• 只要写操作完成，后续所有线程对该变量的volatile读操作，都一定能读到本次修改的最新值，不会出现JVM层面的无意义延迟
  对应你给出的时间轴场景：
• 读线程1的读操作发生在写操作执行过程中，只能读到旧值
• 读线程2的读操作发生在写操作完成之后，一定能读到最新值

2. 已有CPU缓存一致性协议（如MESI），为什么还需要volatile？

MESI是CPU硬件层面的缓存一致性保证，但是它无法约束上层JVM的优化行为，也无法抹平不同CPU架构的内存模型差异：

• 没有volatile修饰的变量，JIT可能直接将变量值存在寄存器中，根本不会访问CPU缓存，MESI协议自然无法生效
• 不同CPU架构的内存模型强度不同，比如x86是强内存模型，默认不允许部分重排序，而ARM是弱内存模型，允许更多重排序。volatile的作用是JVM在不同硬件平台自动插入对应的内存屏障，给上层Java应用提供统一的可见性、有序性保证，不需要开发者适配不同硬件

3. 「volatile变量直接操作主存而非CPU缓存」的说法是否正确？

这个说法是完全错误的，是非常常见的误解：

• 现代CPU的性能高度依赖缓存，正常场景下不会跳过缓存直接访问主存
• volatile的可见性实现逻辑是靠内存屏障配合缓存一致性协议完成的：
  • volatile写操作完成后，会通过内存屏障强制将当前CPU缓存中该变量的修改刷新到主存，同时触发其他CPU中该变量对应的缓存行失效
  • volatile读操作前，会通过内存屏障判断本地缓存行是否已失效，如果失效则从主存拉取最新值
    全程都依赖CPU缓存工作，没有跳过缓存的逻辑。

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