Volatile详解-优快云博客

volatile

当一个变量定义为volatile后，它将具备两种特性：

保证内存可见性，
禁止指令重排序，保证有序性。

1.内存可见性

Java 内存模型

首先我们需要理解Java 内存模型（Java Memory Model）简称为 JMM。

JMM主要是用来屏蔽不同硬件和操作系统的内存访问差异的，因为在不同的硬件和不同的操作系统下，内存的访问是有一定的差异得，这种差异会导致相同的代码在不同的硬件和不同的操作系统下有着不一样的行为，而 Java 内存模型就是解决这个差异，统一相同代码在不同硬件和不同操作系统下的差异的。

Java 内存模型规定：所有的变量（实例变量和静态变量）都必须存储在主内存中，每个线程也会有自己的工作内存，线程的工作内存保存了该线程用到的变量和主内存的副本拷贝，线程对变量的操作都在工作内存中进行。线程不能直接读写主内存中的变量。

Java 内存模型会带来一个新的问题，那就是内存可见性问题，也就是当某个线程修改了主内存中共享变量的值之后，其他线程不能感知到此值被修改了，它会一直使用自己工作内存中的“旧值”。

private static boolean flag = false;
public static void main(String[] args) {
    Thread t1 = new Thread(new Runnable() {
        @Override
        public void run() {
            while (!flag) {

            }
            System.out.println("终止执行");
        }
    });
    t1.start();
    Thread t2 = new Thread(new Runnable() {
        @Override
        public void run() {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("设置 flag=true");
            flag = true;
        }
    });
    t2.start();
}

以上代码我们预期的结果是，在线程 1 执行了 1s 之后，线程 2 将 flag 变量修改为 true，之后线程 1 终止执行，然而，因为线程 1 感知不到 flag 变量发生了修改，也就是内存可见性问题，所以会导致线程 1 会永远的执行下去

如何解决以上问题呢？只需要给变量 flag 加上 volatile 修饰即可，这就是 volatile 的内存可见性。

可见性的实现原理

volatile 内存可见性主要通过 lock 前缀指令实现的，它会锁定当前内存区域的缓存（缓存行），并且立即将当前缓存行数据写入主内存（耗时非常短），回写主内存的时候会通过 MESI 协议使其他线程缓存了该变量的地址失效，从而导致其他线程需要重新去主内存中重新读取数据到其工作线程中。

MESI 协议，全称为 Modified, Exclusive, Shared, Invalid，是一种高速缓存一致性协议。它是为了解决多处理器（CPU）在并发环境下，多个 CPU 缓存不一致问题而提出的。

2.有序性

有序性也叫做禁止指令重排序。指令重排序是指编译器或 CPU 为了优化程序的执行性能，而对指令进行重新排序的一种手段。指令重排序的实现初衷是好的，但是在多线程执行中，如果执行了指令重排序可能会导致程序执行出错。

指令重排序最典型的一个问题就发生在单例模式中，比如以下问题代码：

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

以上问题发生在代码 ② 这一行“instance = new Singleton();”，这行代码看似只是一个创建对象的过程，然而它的实际执行却分为以下 3 步：

创建内存空间。
在内存空间中初始化对象 Singleton。
将内存地址赋值给 instance 对象（执行了此步骤，instance 就不等于 null 了）。

如果此变量不加 volatile，那么线程 1 在执行到上述代码的第 ② 处时就可能会执行指令重排序，将原本是 1、2、3 的执行顺序，重排为 1、3、2。但是特殊情况下，线程 1 在执行完第 3 步之后，如果来了线程 2 执行到上述代码的第 ① 处，判断 instance 对象已经不为 null，但此时线程 1 还未将对象实例化完，那么线程 2 将会得到一个被实例化“一半”的对象，从而导致程序执行出错，这就是为什么要给私有变量添加 volatile 的原因了。

要使以上单例模式变为线程安全的程序，需要给 instance 变量添加 volatile 修饰。

有序性的实现原理

volatile 的有序性是通过插入内存屏障（Memory Barrier），在内存屏障前后禁止重排序优化，以此实现有序性的。

什么是内存屏障？

内存屏障（Memory Barrier 或 Memory Fence）是一种硬件级别的同步操作，它强制处理器按照特定顺序执行内存访问操作，确保内存操作的顺序性，阻止编译器和 CPU 对内存操作进行不必要的重排序。

内存屏障可以确保跨越屏障的读写操作不会交叉进行，以此维持程序的内存一致性模型。

volatile 通过内存屏障的插入来实现：

写内存屏障（Store Barrier / Write Barrier）：当线程写入 volatile 变量时，JMM 会在写操作前插入 StoreStore 屏障，确保在这次写操作之前的所有普通写操作都已完成。接着在写操作后插入 StoreLoad 屏障，强制所有后来的读写操作都在此次写操作完成之后执行，这就确保了其他线程能立即看到 volatile 变量的最新值。
读内存屏障（Load Barrier / Read Barrier）：当线程读取 volatile 变量时，JMM 会在读操作前插入 LoadLoad 屏障，确保在此次读操作之前的所有读操作都已完成。而在读操作后插入 LoadStore 屏障，防止在此次读操作之后的写操作被重排序到读操作之前，这样就确保了对 volatile 变量的读取总是能看到之前对同一变量或其他相关变量的写入结果。

通过这种方式，volatile 关键字有效地实现了内存操作的顺序性，从而保证了多线程环境下对 volatile 变量的操作遵循 happens-before 原则，确保了并发编程的正确性。

原文链接：https://www.javacn.site/interview/thread/volatile-principle.html