JAVA JMM重排序导致多线程逻辑错误的实际案例分析 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

Java 内存模型（JMM）重排序导致多线程逻辑错误的实际案例分析

大家好，今天我们来深入探讨一个在并发编程中经常遇到，但又非常隐蔽的问题：Java 内存模型（JMM）的重排序导致的线程安全问题。很多时候，我们的代码在单线程环境下运行良好，甚至在并发量较低的情况下也能正常工作，但一旦并发量增大，就会出现各种各样匪夷所思的Bug，这些Bug往往难以追踪，而JMM的重排序正是导致这些问题的重要原因之一。

一、什么是JMM和重排序？

首先，我们需要理解JMM的概念。JMM并非一种物理结构，而是一套规范，它定义了Java程序中各种变量（线程共享变量）的访问规则，以及在并发环境下如何保证数据的可见性、原子性和有序性。简单来说，JMM规定了线程如何与主内存交互，以及如何通过工作内存（每个线程私有的内存区域）来操作共享变量。

重排序是指为了优化程序性能，编译器和处理器可能会对指令的执行顺序进行调整。这种调整在单线程环境下通常不会带来问题，因为程序的最终结果看起来是一致的（as-if-serial语义）。然而，在多线程环境下，重排序可能会破坏线程间的可见性和有序性，从而导致数据竞争和意想不到的错误。

重排序主要分为以下几类：

编译器优化重排序： 编译器在不改变单线程程序语义的前提下，重新安排语句的执行顺序。
指令级并行重排序： 现代处理器采用了指令级并行技术（ILP）来并行执行多条指令。如果指令之间不存在数据依赖性，处理器可以改变它们的执行顺序。
内存系统重排序： 现代处理器通常包含多个缓存层级，并且使用写缓冲区来提高内存访问效率。处理器可能会延迟将数据写入主内存，或者以不同的顺序写入数据。

二、重排序带来的问题：可见性与有序性

重排序直接影响了多线程编程中的两个关键属性：

可见性： 一个线程对共享变量的修改，其他线程不一定能立即看到。这是因为线程可能将变量的值缓存在自己的工作内存中，而没有及时刷新到主内存，或者其他线程没有及时从主内存读取最新的值。
有序性： 程序代码的执行顺序未必是按照我们编写的顺序执行的。重排序可能导致指令的执行顺序发生改变，从而影响程序的逻辑。

三、实际案例分析：双重检查锁定（DCL）

双重检查锁定（Double-Checked Locking，DCL）是一种常用的单例模式实现方式，旨在提高性能，避免每次都进行同步操作。然而，如果不正确地使用DCL，就可能会因为重排序而导致线程安全问题。

以下是一个典型的DCL单例模式的实现代码：

public class Singleton {
    private static Singleton instance;

    private Singleton() {
        // 一些初始化操作
    }

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

这段代码看起来似乎没有问题，但在多线程环境下，它可能会因为重排序而导致问题。instance = new Singleton(); 这行代码实际上包含了三个步骤：

分配Singleton对象的内存空间。
初始化Singleton对象。
将instance指向分配的内存地址。

由于JMM的重排序，步骤2和步骤3的执行顺序可能被颠倒。也就是说，可能先将instance指向了分配的内存地址，但Singleton对象还没有完成初始化。此时，如果另一个线程调用getInstance()方法，它会发现instance不为null，从而直接返回instance。但是，这个instance指向的对象可能还没有完成初始化，导致程序出错。

表格1：DCL重排序导致的问题

线程	操作	说明
A	`instance == null` (第一次检查)	检查instance是否为空，发现为空
A	获取`Singleton.class`锁
A	`instance == null` (第二次检查)	再次检查instance是否为空，仍然为空
A	`instance = new Singleton();`	1. 分配内存 2. (可能) 将instance指向分配的内存（但对象尚未初始化) 3. 初始化对象. 注意：2,3可能重排序. 如果重排序发生，线程A执行完第2步，但是第3步还没开始的时候，线程B开始执行。
B	`instance == null` (第一次检查)	检查instance是否为空，发现不为空，因为线程A已经把instance指向了分配的内存地址（即使对象还没初始化）
B	直接返回`instance`	线程B直接返回instance，但是此时的instance指向的对象可能还没有完成初始化，因此线程B可能会使用到未初始化的对象，导致程序出错。

如何解决DCL的重排序问题？

解决DCL重排序问题的关键是禁止重排序。在Java中，可以使用volatile关键字来修饰instance变量，volatile关键字可以保证可见性和禁止指令重排序。

public class Singleton {
    private volatile static Singleton instance;

    private Singleton() {
        // 一些初始化操作
    }

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

使用volatile修饰instance变量后，可以保证以下两点：

可见性： 当线程A完成Singleton对象的初始化后，立即将instance的值刷新到主内存，其他线程可以立即看到instance的最新值。
禁止重排序： 禁止instance = new Singleton(); 这行代码中的步骤2和步骤3进行重排序。

四、其他案例：延迟初始化

除了DCL之外，延迟初始化也是一个容易出现重排序问题的场景。例如：

public class LazyInit {
    private int a = 0;
    private boolean ready = false;

    public void writer() {
        a = 1;
        ready = true;
    }

    public void reader() {
        if (ready) {
            System.out.println(a);
        } else {
            System.out.println("Not ready");
        }
    }
}

在多线程环境下，writer()方法和reader()方法可能被不同的线程调用。由于重排序，a = 1; 和 ready = true; 的执行顺序可能被颠倒。如果先执行了ready = true;，然后执行了a = 1;，那么reader()方法可能会在a被赋值之前就读取到ready为true，从而输出a的值为0，而不是1。

为了解决这个问题，我们可以使用volatile关键字来修饰ready变量：

public class LazyInit {
    private int a = 0;
    private volatile boolean ready = false;

    public void writer() {
        a = 1;
        ready = true;
    }

    public void reader() {
        if (ready) {
            System.out.println(a);
        } else {
            System.out.println("Not ready");
        }
    }
}

使用volatile修饰ready变量后，可以保证a = 1; 一定在 ready = true; 之前执行。

五、JMM提供的happens-before原则

为了更好地理解和避免重排序带来的问题，我们需要了解JMM提供的happens-before原则。happens-before原则定义了两个操作之间的happens-before关系，如果一个操作happens-before另一个操作，那么前一个操作的结果对于后一个操作是可见的，并且前一个操作的执行顺序一定在后一个操作之前。

以下是一些常见的happens-before规则：

程序顺序规则： 在一个线程中，按照程序代码的顺序，书写在前面的操作happens-before书写在后面的操作。
管程锁定规则： 对一个锁的解锁happens-before后续对这个锁的加锁。
volatile变量规则： 对一个volatile变量的写操作happens-before后续对这个volatile变量的读操作。
线程启动规则： 线程的start()方法happens-before该线程中的任何操作。
线程终止规则： 线程中的所有操作happens-before对此线程的终止检测。
线程中断规则： 对线程interrupt()方法的调用happens-before被中断线程的代码检测到中断事件的发生。
对象终结规则： 一个对象的初始化完成happens-before它的finalize()方法的开始。
传递性： 如果A happens-before B，B happens-before C，那么A happens-before C。

六、总结与建议

JMM的重排序是多线程编程中一个非常重要的概念，理解重排序的原因和影响，以及如何避免重排序带来的问题，对于编写正确的并发程序至关重要。

以下是一些建议：

理解JMM和happens-before原则： 这是编写正确并发程序的基础。
谨慎使用双重检查锁定（DCL）： 如果使用DCL，一定要使用volatile关键字修饰单例对象。
使用volatile关键字保证可见性和禁止重排序： 当一个变量被多个线程访问时，并且至少有一个线程会修改这个变量，那么最好使用volatile关键字修饰这个变量。
使用锁（synchronized或Lock）来保证原子性和可见性： 锁不仅可以保证操作的原子性，还可以保证操作的可见性。
尽可能使用线程安全的数据结构： 例如ConcurrentHashMap、CopyOnWriteArrayList等。
避免共享可变状态： 尽量减少线程之间共享的可变状态，可以有效降低并发编程的复杂性。

掌握以上原则，可以帮助我们写出更加健壮和可靠的多线程程序。

七、JMM学习的下一步

深入理解JMM，需要实践和不断学习，希望大家能够多多练习，多多思考，在并发编程的道路上越走越远。

Java 内存模型（JMM）重排序导致多线程逻辑错误的实际案例分析

发表回复 取消回复

发表回复取消回复