Java并发编程-Java内存模型(JMM)

关注

原创最新推荐文章于 2026-04-28 05:46:52 发布 309 阅读 AI 写同款· GEO 优化 ›

JUC并发编程第五章——Java内存模型JMM CPU的运行并不是直接操作内存而是先把内存里面的数据读到缓存，而内存的读和写操作的时候会造成不一致的问题。JVM规范中试图定义一种Java内存模型来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序再各种平台下都能达到一致性的内存访问效果。，通过这组规范定义了程序中（尤其是多线程）各个变量的读写访问方式并决定一个线程对共享变量的写入以及如何变成对另一个线程可见，关键技术点都是围绕多线程的。● JMM没有那些特征或者它的三大特征是什么？● 你知道什么是Java内存模型JMM吗？阅读详情

前言

在上一章 Java并发编程-Android的UI框架为什么是单线程的？中笔者介绍了并发编程线程安全「三大恶」：「可见性」、「原子性」以及「有序性」

广义上来说，并发编程问题笔者归纳为：是由于后续操作看不到前面操作的结果而引发的

首先「大恶-可见性」顾名思义，即线程B能否看见线程A对共享变量的操作结果

其次「二恶-原子性」CPU 指令/操作被中断/分割，广义上看笔者认为也是可见性问题，比如线程 A 修改共享变量 x += 1 时被中断，去执行线程 B x = 40 ，线程 A 恢复执行时可能看不到 x 已经被修改为 40

最后「三恶-有序性」指的是程序按照代码的先后顺序执行，即先执行 x = 40 ，后续读取 x == 40 一定为真，如果有各种优化导致指令重排序，后续读取 x == 40 时可能不为真

总而言之，并发编程的问题大部分都是「可见性」问题

Java内存模型(JMM)

在上一章中笔者介绍了导致「可见性」的原因是缓存，导致「有序性」的原因是各种优化(编译时、处理器以及运行时)，首先笔者想到的是禁用缓存和禁止各种优化操作，在 Java 中如何禁用缓存和禁止各种优化呢？

Happens-Before

Java 内存模型是通过各种操作来定义的¹，包括对变量的读 / 写操作，监视器锁的加锁和释放操作，以及线程的启动和合并操作。JMM 为程序中所有的操作定义了一个偏序关系²，称之为 Happens-Before。要想保证执行操作 B 的线程看到操作 A 的结果（无论 A 和 B 是否在同一个线程中执行），那么在 A 和 B 之间必须满足 Happens-Before 关系。如果两个操作之间缺乏 Happens-Before 关系，那么 JVM 可以对它们任意的重排序。

Happens-Before 的规则包括：

规则一：程序顺序

这条规则比较符合我们的直觉，在单线程中代码的顺序即程序的执行顺序：int x = 40 将在 int y = 41 之前执行

public void test() {
    int x = 40;
    int y = 41;
}

规则二：监视器锁³

监视器锁即内置锁(synchronized)，在监视器锁上的解锁操作必须在同一个监视器锁的加锁操作之前执行，这条规则比较好理解，现实世界中的锁在关锁前必须处于打开状态

规则三：volatile 变量⁴⁵

对 volatile 变量的写入操作必须在对该变量的读取操作之前执行。

这条规则不大好理解，以下代码与文字摘自深入理解Java内存模型（四）——volatile

理解 volatile 特性的一个好方法是：把对 volatile 变量的单个读/写，看成是使用同一个监视器锁对这些单个读/写操作做了同步⁶

class VolatileFeaturesExample {
    volatile long vl = 0L;  // 使用 volatile 声明 64 位的 long 型变量

    public void set(long l) {
        vl = l;   // 单个 volatile 变量的写
    }

    public void getAndIncrement () {
        vl++;    // 复合（多个）volatile 变量的读 / 写
    }

    public long get() {
        return vl;   // 单个 volatile 变量的读
    }
}

假设有多个线程分别调用上面程序的三个方法，这个程序在语意上和下面程序等价：

class VolatileFeaturesExample {
    long vl = 0L;               // 64 位的 long 型普通变量

    public synchronized void set(long l) {     // 对单个的普通 变量的写用同一个监视器同步
        vl = l;
    }

    public void getAndIncrement () { // 普通方法调用
        long temp = get();           // 调用已同步的读方法
        temp += 1L;                  // 普通写操作
        set(temp);                   // 调用已同步的写方法
    }
    
    public synchronized long get() { 
        return vl; // 对单个的普通变量的读用同一个监视器同步
    }
}

如上面示例程序所示，对一个 volatile 变量的单个读 / 写操作，与对一个普通变量的读 / 写操作使用同一个监视器锁来同步，它们之间的执行效果相同。

从内存语义的角度来说，volatile 与监视器锁有相同的效果：volatile 写和监视器的释放有相同的内存语义；volatile 读与监视器的获取有相同的内存语义。

简而言之，volatile 变量自身具有下列特性：

可见性。对一个 volatile 变量的读，总是能看到（任意线程）对这个 volatile 变量最后的写入。
原子性：对任意单个 volatile 变量的读 / 写具有原子性，但类似于 volatile++ 这种复合操作不具有原子性。

规则四：线程启动

在线程上对 Thread.start 的调用必须在该线程中执行任何操作之前执行。

这条规则比较好理解，即线程 A 启动操作先执行，然后再执行线程 A 内的操作，换言之，线程 A 启动前的操作结果对线程 A 中的操作可见，参考下面的示例代码：

Thread thread = new Thread(() -> {
    // 线程中的操作, 可以看到线程启动前对共享变量的操作结果
    System.out.println(x);
});

// 线程启动前操作共享变量
x = 10;

// 线程启动
thread.start();

规则五：线程结束

线程中的任何操作都必须在其他线程检测到该线程已经结束之前执行，或者从 Thread.join 中成功返回，或者在调用 Thread.isAlive 时返回 false。

这条规则也比较好理解，即线程结束前，线程内的任何操作都已经执行，换言之，线程结束后，线程内的操作结果对后续操作可见，参考下面的示例代码：

Thread thread = new Thread(() -> {
    // 线程中的操作, 可以看到线程启动前对共享变量的操作结果
    System.out.println(x);

    // 线程中操作共享变量
    x = 20;
});

// 线程启动前操作共享变量
x = 10;

// 线程启动
thread.start();

// 线程join, 等待线程结束
thread.join();

// 线程中对共享变量的操作结果此处可见
System.out.println(x);