Java 内存模型（JMM）通俗解释：volatile 背后的秘密-CSDN博客

本文链接：https://blog.csdn.net/zj6182007/article/details/148113615

在并发编程中，我们常听说 volatile 可以“禁止指令重排序、保证可见性”，但这背后到底发生了什么？Java 内存模型（JMM）又是怎么定义这一切的？本文一文带你厘清核心机制与底层原理。

一、什么是 Java 内存模型（JMM）？

Java 并发问题的根源，在于：

多线程对共享变量的访问无法保证可见性与有序性。

JMM 定义了一组规则，规定：

变量如何在主内存和线程工作内存之间传递；
线程对共享变量的读写行为是否安全；
允许或禁止哪些重排序操作。

📌 本质上，JMM 是 Java 虚拟机对 CPU 和内存之间屏障差异的抽象。

二、JMM 中的关键概念图示

线程并不会直接访问主内存中的变量，而是先将其拷贝到工作内存进行操作，之后再写回主内存。

三、为什么会出现“可见性问题”？

示例代码：

class Example {
    static boolean running = true;
    public static void main(String[] args) {
        new Thread(() -> {
            while (running) {
                // do something
            }
        }).start();
        Thread.sleep(1000);
        running = false;  // 主线程修改变量
    }
}

这段代码中，子线程可能永远无法感知主线程对 running = false 的修改，因为它读取的是自己缓存的副本。

四、volatile 到底解决了什么问题？

volatile 是轻量级的同步手段，主要解决两个核心问题：

1. 可见性

加上 volatile 后，修改会立刻刷新到主内存，其他线程会立刻看到最新值。

2. 禁止指令重排序

volatile 语义强制在读写操作前后插入 内存屏障（Memory Barrier），避免重排序带来的问题。

五、底层实现机制

编译器 + CPU 指令层面协同实现：

在 写 volatile 变量时，JVM 会发出 StoreStore、StoreLoad 屏障。
在 读 volatile 变量时，会加入 LoadLoad、LoadStore 屏障。

这些屏障确保：

写操作在其后的读写执行前完成；
读操作在其前的读写执行后执行。

六、volatile 不等于原子性！

一个典型错误用法：

volatile int count = 0;
public void increment() {
    count++;  // 非原子操作，仍然有并发问题
}

这里 count++ 实际上分为三步：

读取 count；
执行 +1；
写回 count。

⚠️ 多线程下会造成数据丢失问题，仍需 synchronized 或 AtomicInteger 保证原子性。

七、volatile 与 synchronized 的对比

特性	volatile	synchronized
可见性	✅	✅
原子性	❌	✅
指令重排序屏蔽	✅（部分）	✅（完全）
性能开销	低	高
用法适用场景	状态标识/信号量	临界区/复合操作

☑️ 如果你只需要标志变量的可见性，可以选用 volatile；如果涉及多操作的并发修改，优先选择 synchronized 或并发包。

八、典型应用场景

双重检查锁（DCL） 中的单例模式：

class Singleton {
    private static volatile Singleton instance;
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}