Java `Memory Consistency Models` (`Sequential Consistency`, `Release Consistency`) 与并发可见性

各位观众老爷，大家好！我是你们的老朋友，今天咱们来聊聊 Java 并发编程里一个听起来玄乎，但其实很重要的东西：Java 内存一致性模型（Memory Consistency Models），特别是其中的 Sequential Consistency 和 Release Consistency，以及它们跟并发可见性之间的爱恨情仇。

开场白：并发的“乱”世

想象一下，你在厨房做饭，你老婆（或者老公，或者室友，别杠，这里只是举例子）在客厅看电视。你切菜需要用到冰箱里的食材，你从冰箱里拿出食材，然后开始切菜。而你老婆想知道你今天晚上做什么好吃的，过来问你。

如果你们俩的行为都按照时间顺序来，一切都井然有序。但如果你们俩都想抄近路，比如你一边切菜一边把冰箱门开着，方便下次拿东西；你老婆一边问你做什么菜，一边还在刷手机，时不时回个微信。

这时候，问题就来了：

• 你可能忘记关冰箱门，导致冰箱里的东西坏掉。
• 你老婆可能因为看手机没听清你说了什么，导致晚饭没法顺利进行。

这就是并发的“乱”世。多个线程（或者多个处理器）同时访问共享数据，如果不加以控制，就会导致数据不一致，程序行为不可预测。而内存一致性模型，就是用来规范这种“乱”世”的秩序。

什么是内存一致性模型？

简单来说，内存一致性模型定义了多个线程（或者处理器）对共享内存进行读写操作时，必须遵守的规则。它决定了：

1. 一个线程写入的数据，什么时候对其他线程可见？
2. 多个线程的读写操作，看起来会以什么样的顺序执行？

如果没有内存一致性模型，每个线程都可以“自由发挥”，想什么时候读就什么时候读，想什么时候写就什么时候写，那整个程序就彻底乱套了。

Sequential Consistency (顺序一致性)：理想主义者的乌托邦

Sequential Consistency 是最简单、最理想化的内存一致性模型。它规定：

1. 所有线程的操作，看起来都是按照某种全局唯一的顺序执行的。
2. 每个线程的操作，都按照程序代码的顺序执行。

换句话说，Sequential Consistency 就像一个“全知全能”的裁判，它知道所有线程的所有操作，并且按照某种全局顺序把它们“串”起来。每个线程看到的操作顺序，都跟这个全局顺序一致。

举个例子：

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

    public static void main(String[] args) throws InterruptedException {
        Thread thread1 = new Thread(() -> {
            a = 1;
            x = b;
        });

        Thread thread2 = new Thread(() -> {
            b = 1;
            y = a;
        });

        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();

        System.out.println("x = " + x + ", y = " + y);
    }
}

在这个例子中，有两个线程分别执行以下操作：

• Thread 1:
  1. a = 1;
  2. x = b;
• Thread 2:
  1. b = 1;
  2. y = a;

如果按照 Sequential Consistency，可能的执行顺序有很多，比如：

1. a = 1;
2. x = b;
3. b = 1;
4. y = a; (此时 x = 0, y = 1)

或者：

1. b = 1;
2. y = a;
3. a = 1;
4. x = b; (此时 x = 1, y = 0)

或者：

1. a = 1;
2. b = 1;
3. x = b;
4. y = a; (此时 x = 1, y = 1)

但是，不可能出现 x = 0, y = 0 的情况。 因为按照 Sequential Consistency，a = 1 和 b = 1 必须先执行，才能执行 x = b 和 y = a。

Sequential Consistency 的问题：理想很丰满，现实很骨感

Sequential Consistency 非常容易理解，也方便程序员进行推理。但是，它的性能非常差。因为为了保证所有线程的操作都按照全局顺序执行，需要大量的同步和协调，导致 CPU 的利用率很低。

现代处理器为了提高性能，会进行各种优化，比如：

• 乱序执行 (Out-of-Order Execution): 处理器可以不按照程序代码的顺序执行指令，只要不影响最终结果。
• 缓存 (Cache): 处理器会在本地缓存中保存常用的数据，减少访问主内存的次数。
• 写缓冲区 (Write Buffer): 处理器会先把数据写入写缓冲区，然后再异步地写入主内存。

这些优化都会破坏 Sequential Consistency。例如，a = 1 可能会先写入写缓冲区，然后再写入主内存，导致其他线程先看到 x = b 的结果，然后再看到 a = 1。

因此，Sequential Consistency 在现代处理器上很难实现。Java 虚拟机 (JVM) 并没有强制要求实现 Sequential Consistency。

Release Consistency (释放一致性)：实用主义者的妥协

Release Consistency 是一种更宽松的内存一致性模型。它认识到 Sequential Consistency 的性能瓶颈，并试图在性能和可编程性之间找到一个平衡点。

Release Consistency 的核心思想是：

1. 将内存操作分为两类：同步操作和普通操作。
2. 只对同步操作强制执行顺序性，而允许普通操作乱序执行。

同步操作通常包括：

• 锁的获取 (Acquire): 线程尝试获取一个锁。
• 锁的释放 (Release): 线程释放一个锁。
• volatile 变量的读写: volatile 变量保证了可见性和有序性。

Release Consistency 规定：

• Release: 在释放锁之前，所有之前的写操作必须对其他线程可见。
• Acquire: 在获取锁之后，所有之后的读操作必须看到其他线程在释放锁之前所做的写操作。

简单来说，Release Consistency 就像一个“有原则的流氓”，它只在关键时刻才遵守规则，平时则可以“自由发挥”。

Release Consistency 的好处：性能提升

Release Consistency 允许处理器进行更多的优化，比如乱序执行和缓存。只要保证同步操作的顺序性，就可以在一定程度上保证程序的正确性，同时提高性能。

Release Consistency 的挑战：编程难度增加

Release Consistency 的编程难度比 Sequential Consistency 大。程序员需要仔细考虑哪些变量需要同步，哪些变量可以“自由发挥”。如果同步不当，就可能导致数据不一致，程序行为不可预测。

Java 中的内存一致性模型：折中方案

Java 内存模型 (JMM) 并没有明确规定使用哪种内存一致性模型。它采用了一种折中方案，介于 Sequential Consistency 和 Release Consistency 之间。

JMM 定义了一套规则，称为 happens-before 关系，用于描述哪些操作必须在哪些操作之前发生。如果两个操作之间存在 happens-before 关系，那么第一个操作的结果必须对第二个操作可见。

happens-before 关系有很多种，其中最常见的包括：

• 程序顺序规则 (Program Order Rule): 一个线程中的每个操作，happens-before 该线程中在其后的任何操作。
• 监视器锁规则 (Monitor Lock Rule): 对一个锁的解锁，happens-before 后面对同一个锁的加锁。
• volatile 变量规则 (Volatile Variable Rule): 对一个 volatile 变量的写操作，happens-before 后面对同一个 volatile 变量的读操作。
• 线程启动规则 (Thread Start Rule): Thread.start() 方法 happens-before 启动线程中的任何操作。
• 线程终止规则 (Thread Termination Rule): 线程中的所有操作，happens-before 对该线程的终止检测。
• 传递性 (Transitivity): 如果 A happens-before B，B happens-before C，那么 A happens-before C。

JMM 通过 happens-before 关系，保证了程序的正确性。同时，它也允许处理器进行一定的优化，以提高性能。

代码示例：volatile 的威力

public class VolatileExample {
    private volatile static boolean running = true;

    public static void main(String[] args) throws InterruptedException {
        Thread thread = new Thread(() -> {
            while (running) {
                // Do something
            }
            System.out.println("Thread stopped.");
        });

        thread.start();
        Thread.sleep(1000);

        running = false;
        System.out.println("Main thread set running to false.");
    }
}

在这个例子中，running 变量被声明为 volatile。这意味着：

• 可见性： 当主线程将 running 设置为 false 时，子线程能够立即看到这个变化。
• 有序性： 对 running 的写操作，happens-before 子线程对 running 的读操作。

如果没有 volatile，子线程可能永远无法看到 running 的变化，导致程序无法正常结束。这是因为主线程对 running 的修改可能只存在于缓存中，而没有及时刷新到主内存，导致子线程读取的仍然是旧值。

表格总结：各种内存一致性模型的对比

特性	Sequential Consistency	Release Consistency	Java Memory Model (JMM)
复杂程度	最简单	较复杂	复杂
性能	最差	较好	较好
编程难度	最低	较高	较高
同步要求	所有操作	同步操作	基于 happens-before 关系
是否易于实现	否	是	是

并发可见性的重要性：避免“鬼故事”

并发可见性是指一个线程对共享变量的修改，能够及时被其他线程看到。如果并发可见性有问题，就会出现各种“鬼故事”，比如：

• 脏读 (Dirty Read): 一个线程读取了另一个线程尚未提交的修改。
• 不可重复读 (Non-Repeatable Read): 一个线程多次读取同一个数据，但每次读取的结果都不一样。
• 幻读 (Phantom Read): 一个线程多次查询同一个范围的数据，但每次查询的结果集都不一样。

这些“鬼故事”会导致程序行为不可预测，难以调试。因此，保证并发可见性是并发编程的重要目标。

总结：理解内存一致性模型，才能写出靠谱的并发代码

Java 内存一致性模型是一个复杂而重要的概念。理解它，才能写出正确、高效的并发代码。虽然 Sequential Consistency 很理想，但现实中我们往往需要选择 Release Consistency 或 JMM 提供的机制，牺牲一些易用性，换取更好的性能。

记住，并发编程是一门艺术，需要不断学习和实践。希望今天的讲座能帮助大家更好地理解 Java 内存一致性模型，写出更加靠谱的并发代码！

最后，别忘了点赞、收藏、转发！ 感谢大家！