为何未使用volatile变量的Java程序仍正常运行？实测未复现预期异常

我太懂这种困惑了——明明把volatile的内存屏障、可见性原理背得滚瓜烂熟，照着公认的测试案例写代码，结果线程居然乖乖读到了变量的最新值，完全没出现预期的“缓存导致死循环”场景，简直怀疑自己学了个假知识点😂

其实这种情况大概率是你的测试代码里藏着一些隐性的干扰因素，破坏了“变量被线程缓存”的前提，下面我给你拆解几个最常见的原因：

1. 循环里的操作触发了隐性内存屏障 #

你是不是在循环里用了System.out.println()？别小看这个输出语句，它的底层实现里是加了synchronized锁的！而synchronized关键字会强制触发内存屏障，要求线程刷新主存中的数据——相当于每次打印的时候，线程都会主动去主存重新读取isRunning的值，自然能看到主线程的修改。

要复现问题，得把循环里的代码改成纯计算逻辑，比如：

private static boolean isRunning = true;

public static void main(String[] args) throws InterruptedException {
    new Thread(() -> {
        int counter = 0;
        // 只做简单累加，无任何带锁/IO操作
        while (isRunning) {
            counter++;
        }
        System.out.println("线程终止，累计次数：" + counter);
    }).start();

    Thread.sleep(2000);
    isRunning = false;
    System.out.println("主线程已修改isRunning为false");
}

这个版本里，循环只有变量累加，没有触发内存屏障的操作，JIT编译器就会把isRunning缓存到线程本地，主线程修改后工作线程根本看不到，会一直死循环下去；给isRunning加上volatile，就能立刻终止线程。

2. JIT编译还没触发 #

JVM在程序启动初期是解释执行代码的，这时候变量读写基本都是直接操作主存，不会做缓存优化。只有当代码被反复执行、触发JIT即时编译后，才会生成机器级的缓存优化。

如果你的测试代码运行时间太短，循环次数不够，JVM还没来得及把这段代码编译成优化后的机器码，自然不会出现缓存问题。可以试试让线程多跑一会儿，或者在启动JVM时加上参数-XX:CompileThreshold=100（降低JIT编译触发的阈值），强制让代码更快进入优化状态。

3. CPU缓存的“巧合同步” #

现代多核CPU都有缓存一致性协议（比如MESI），当主线程修改了变量后，CPU可能刚好在某个时机主动同步了缓存（比如其他线程操作了同一块内存，或者CPU空闲时做了缓存刷新）。这种情况是概率性的，你多跑几次测试，或者换个不同架构的CPU（比如从Intel换到ARM），大概率就能看到预期的死循环场景。

4. JVM参数或版本的影响 #

不同版本的JVM对缓存优化的策略可能不同，比如较新的OpenJDK版本可能对某些场景做了额外的内存屏障优化；如果你不小心加了-Xint（强制解释执行）或者-XX:-DoEscapeAnalysis（禁用逃逸分析）这类参数，也会阻止JIT做缓存优化，导致变量始终从主存读取。

总结 #

不是你对volatile的理解错了，而是复现场景里的隐性因素干扰了缓存优化的触发。调整测试代码，避开带锁/IO这类会触发内存屏障的操作，让JIT有机会生成优化后的机器码，就能看到volatile真正解决的问题啦。

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