如何证明Java Volatile的可见性保障？验证无volatile时可见性无保障的方法

一、为什么你的测试没复现可见性问题？ #

• JVM本身可能会做指令重排或缓存优化，但简单的单赋值操作（counter=1）在很多场景下会被JVM优化，直接把值刷到主内存，尤其是当线程A执行完赋值后很快结束，JVM会自动同步内存。
• 现代CPU的缓存一致性协议（比如MESI）在某些情况下会主动同步缓存，加上测试代码逻辑太简单，线程B可能在线程A完成赋值后才开始执行，自然能读到最新值。

二、如何复现未用volatile的可见性问题？ #

要复现需要构造长时间运行的循环，让JVM的缓存优化显现出来。示例代码如下：

public class VisibilityTest {
    private static int flag = 0;

    public static void main(String[] args) throws InterruptedException {
        // 线程1：持续读取flag，直到值变为1
        new Thread(() -> {
            while (flag == 0) {
                // 空循环避免JVM优化掉读取逻辑
            }
            System.out.println("线程1读到flag=1");
        }).start();

        // 主线程休眠1秒，确保线程1进入循环
        Thread.sleep(1000);

        // 线程2：修改flag的值为1
        new Thread(() -> {
            flag = 1;
            System.out.println("线程2已将flag设为1");
        }).start();
    }
}

在部分JVM参数或多核CPU环境下，线程1会一直卡在循环中，永远读不到线程2修改后的flag=1——这就是典型的可见性问题：线程2修改的值仅存于自身CPU缓存，未同步到主内存，线程1持续读取的是自己缓存中的旧值。

如果给flag添加volatile修饰，线程1会立刻感知到主内存的更新，循环会终止。

三、单写多读场景下必须用volatile吗？ #

是的，必须使用volatile或其他同步机制保证可见性。

虽然简单测试可能复现不出问题，但这属于偶然情况：Java内存模型（JMM）明确规定，未被volatile修饰的变量，线程对它的写入不保证对其他线程可见。在生产环境中，随着代码复杂度提升、CPU核心数增加、JVM优化策略变化，可见性问题极大概率会出现，且这类问题排查难度极高。

除了volatile，也可以使用synchronized块、Lock接口等同步手段，它们同样能保证可见性（同步块的进入和退出会触发内存屏障，强制刷新缓存）。但如果是单写多读的场景，volatile是最轻量的解决方案。

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