JVM 内存模型深度解析：原子性、可见性与有序性的实现-优快云博客

本文链接：https://blog.youkuaiyun.com/dom_jun/article/details/149718270

在了解了 JVM 的基础架构和类加载机制后，我们需要进一步探索 Java 程序在多线程环境下的内存交互规则。JVM 内存模型（Java Memory Model，JMM）定义了线程和主内存之间的抽象关系，它通过规范共享变量的访问方式，解决了多线程并发时的数据一致性问题。本文将从内存模型的核心目标出发，详解原子性、可见性、有序性的实现机制，以及 volatile、synchronized 等关键字在其中的作用。

一、JVM 内存模型的核心目标：解决多线程内存可见性问题

在单线程环境中，程序的执行结果是可预测的，但在多线程环境下，由于 CPU 缓存、指令重排序等硬件和编译器优化的存在，线程间的数据交互可能出现 “不可见”“无序” 等问题。JMM 的核心目标就是定义线程对共享变量的读写操作规则，确保多线程环境下的内存访问行为是可预测的。

1.1 主内存与工作内存的抽象划分

JMM 将内存划分为两个部分：

主内存：所有线程共享的内存区域，存储了共享变量（实例字段、静态字段等）的值。

工作内存：每个线程独有的内存区域，存储了该线程使用的共享变量的副本（从主内存复制而来）。

线程对共享变量的操作必须在工作内存中进行，不能直接读写主内存，具体流程如下：

线程从主内存读取共享变量到工作内存，形成副本；

线程在工作内存中修改副本的值；

线程将修改后的副本值刷新回主内存。

这种抽象模型隔离了不同线程的内存操作，而 JMM 的核心就是规范这三个步骤的交互细节，避免出现 “线程 A 修改了变量值，线程 B 却看不到” 的问题。

1.2 多线程并发的三大问题

JMM 需要解决多线程并发时的三大核心问题：

原子性：一个操作或多个操作要么全部执行且执行过程不被中断，要么全部不执行（如i++这类操作在多线程下可能被拆分为 “读取 - 修改 - 写入” 三步，导致原子性问题）。

可见性：当一个线程修改了共享变量的值，其他线程能立即看到修改后的结果（如线程 A 修改了flag变量，线程 B 可能因缓存未刷新而看不到最新值）。

有序性：程序执行的顺序按照代码的先后顺序执行（编译器或 CPU 可能为优化性能对指令重排序，导致多线程下的执行顺序与预期不符）。

以下将逐一解析 JMM 如何通过关键字和底层机制解决这些问题。

二、原子性保障：从基本操作到复合操作

原子性是多线程安全的基础，JMM 通过两种方式保障原子性：

2.1 基本数据类型的原子操作

JVM 对基本数据类型的读取和赋值操作是原子性的（long和double除外，在 32 位虚拟机中可能被拆分为两个 32 位操作）。例如：


int a = 10; // 原子操作

b = a; // 读取a（原子）+ 赋值给b（原子），整体非原子

但复合操作（如i++）不是原子的，它包含三个步骤：

读取i的值到工作内存；

在工作内存中对i加 1；

将结果刷新回主内存。

在多线程环境下，这三个步骤可能被其他线程打断，导致结果错误：

public class AtomicDemo {
    private static int count = 0;

    public static void main(String[] args) throws InterruptedException {
        Runnable increment = () -> {
            for (int i = 0; i < 10000; i++) {
                count++; // 非原子操作，多线程下结果可能小于20000
            }
        };

        Thread t1 = new Thread(increment);
        Thread t2 = new Thread(increment);
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count); // 可能输出15678等小于20000的值
    }
}

2.2 锁机制实现复合操作的原子性

对于复合操作，JMM 通过锁机制（如synchronized）保障原子性。synchronized会对代码块加锁，确保同一时间只有一个线程执行该代码块，从而将非原子操作转换为原子操作：

public class SynchronizedAtomicDemo {
    private static int count = 0;
    private static final Object lock = new Object();

    public static void main(String[] args) throws InterruptedException {
        Runnable increment = () -> {
            for (int i = 0; i < 10000; i++) {
                synchronized (lock) { // 加锁保障原子性
                    count++;
                }
            }
        };

        Thread t1 = new Thread(increment);
        Thread t2 = new Thread(increment);
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count); // 必然输出20000
    }
}

synchronized的原子性保障原理是：

进入同步块时，线程获取锁，独占对共享变量的操作权；

退出同步块时，线程释放锁，其他线程才能获取锁执行操作。

2.3 java.util.concurrent.atomic 包的原子类

JDK 提供了AtomicInteger、AtomicLong等原子类，通过CAS（Compare-And-Swap）操作实现原子性，性能通常优于synchronized：

import java.util.concurrent.atomic.AtomicInteger;

public class AtomicIntegerDemo {
    private static AtomicInteger count = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        Runnable increment = () -> {
            for (int i = 0; i < 10000; i++) {
                count.incrementAndGet(); // 原子操作
            }
        };

        Thread t1 = new Thread(increment);
        Thread t2 = new Thread(increment);
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count.get()); // 必然输出20000
    }
}

CAS 操作包含三个参数（V：内存值，A：预期值，B：新值），只有当 V 等于 A 时，才将 V 改为 B，否则不做操作。该操作通过硬件指令实现原子性，无需加锁，效率更高。

三、可见性保障：volatile 与内存屏障

可见性问题的根源是线程工作内存与主内存的同步延迟。当一个线程修改了共享变量，若未及时刷新到主内存，其他线程读取的仍是旧值。JMM 通过volatile关键字和synchronized、final等机制保障可见性。

3.1 volatile 关键字的可见性实现

volatile是 JMM 提供的轻量级可见性保障机制，当一个变量被声明为volatile时，它的修改会被立即刷新到主内存，且其他线程读取时会直接从主内存加载，跳过工作内存的缓存。

代码示例：

public class VolatileVisibilityDemo {
    private static volatile boolean flag = false;

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            while (!flag) {
                // 循环等待flag变为true
            }
            System.out.println("线程1检测到flag已修改");
        });

        Thread t2 = new Thread(() -> {
            try {
                Thread.sleep(1000);
                flag = true; // 修改volatile变量
                System.out.println("线程2已将flag设为true");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });

        t1.start();
        t2.start();
    }
}

若flag不加volatile，线程 1 可能永远看不到线程 2 的修改（因 CPU 缓存未刷新），导致无限循环；加volatile后，线程 2 的修改会立即被线程 1 感知。

底层原理：volatile通过内存屏障（Memory Barrier）实现可见性：

写屏障（Store Barrier）：当线程写入volatile变量时，会将工作内存中的值刷新到主内存，并 invalidate 其他线程的缓存（强制它们重新从主内存加载）。

读屏障（Load Barrier）：当线程读取volatile变量时，会从主内存加载最新值，忽略工作内存中的缓存。

3.2 synchronized 与 final 的可见性保障

synchronized也能保障可见性，其原理是：

线程释放锁时，会将工作内存中的变量刷新到主内存；

线程获取锁时，会清空工作内存中的变量，从主内存重新加载。

final关键字修饰的变量一旦初始化完成，其值就不能被修改，且其他线程能看到它的初始化值（通过禁止重排序保障）。

3.3 volatile 与 synchronized 的可见性对比

特性	volatile	synchronized
适用场景	单个变量的读写	代码块或方法中的复合操作
性能	开销小（无锁）	开销大（可能导致线程阻塞）
原子性保障	不保障（仅可见性和有序性）	保障（全程加锁）

volatile适合修饰单一共享变量（如状态标记），而synchronized适合复合操作（如i++）。

四、有序性保障：禁止指令重排序

指令重排序是编译器或 CPU 为优化性能对指令执行顺序的调整（如将a=1; b=2;优化为b=2; a=1;，单线程下结果一致，但多线程下可能出错）。JMM 通过happens-before 原则和volatile、synchronized等机制保障有序性。

4.1 指令重排序的问题案例

public class ReorderDemo {
    private static int a = 0, b = 0;
    private static int x = 0, y = 0;

    public static void main(String[] args) throws InterruptedException {
        int i = 0;
        while (true) {
            i++;
            a = 0; b = 0;
            x = 0; y = 0;

            Thread t1 = new Thread(() -> {
                a = 1;
                x = b; // 可能被重排序为：x = b; a = 1;
            });

            Thread t2 = new Thread(() -> {
                b = 1;
                y = a; // 可能被重排序为：y = a; b = 1;
            });

            t1.start();
            t2.start();
            t1.join();
            t2.join();

            if (x == 0 && y == 0) {
                System.out.println("第" + i + "次执行：x=" + x + ", y=" + y);
                break;
            }
        }
    }
}

正常情况下，x和y不可能同时为 0，但由于指令重排序，t1的a=1和x=b可能被交换顺序，t2的b=1和y=a也可能被交换，导致x=0且y=0的异常结果。

4.2 happens-before 原则：有序性的判断标准

JMM 通过 happens-before 原则定义两个操作的执行顺序，若操作 A happens-before 操作 B，则 A 的结果对 B 可见，且 A 的执行顺序在 B 之前。核心规则包括：

程序顺序规则：同一线程中，代码按顺序执行，前面的操作 happens-before 后面的操作。

volatile 规则：volatile变量的写操作 happens-before 后续的读操作。

锁规则：释放锁的操作 happens-before 获取同一把锁的操作。

传递性：若 A happens-before B，B happens-before C，则 A happens-before C。

示例：

int a = 0;

volatile int b = 0;

// 线程1

a = 1; // 操作1

b = 1; // 操作2（volatile写）

// 线程2

if (b == 1) { // 操作3（volatile读）

    System.out.println(a); // 操作4

}

根据规则：

操作 1 happens-before 操作 2（程序顺序规则）；

操作 2 happens-before 操作 3（volatile 规则）；

操作 3 happens-before 操作 4（程序顺序规则）；

因此操作 1 happens-before 操作 4，线程 2 能看到a=1，输出 1。

4.3 volatile 的有序性保障

volatile除可见性外，还能禁止指令重排序：

禁止编译器和 CPU 将volatile变量的读写操作与其他指令重排序；

通过内存屏障实现（写屏障禁止前面的指令重排序到volatile写之后，读屏障禁止后面的指令重排序到volatile读之前）。

在单例模式的双重检查锁实现中，volatile是必须的，否则可能因指令重排序导致获取到未初始化的对象：

public class Singleton {
    private static volatile Singleton instance; // 必须加volatile

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) { // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) { // 第二次检查
                    instance = new Singleton(); // 可能被重排序
                }
            }
        }
        return instance;
    }
}

new Singleton()可拆分为 “分配内存→初始化对象→赋值给 instance”，若不加volatile，可能被重排序为 “分配内存→赋值给 instance→初始化对象”，导致其他线程获取到未初始化的instance。