Volatile详解

在 Java 多线程编程的过程中，常常会遇到数据不一致、指令执行顺序混乱等并发问题，而volatile关键字正是解决这些问题的关键之一。这里我们来介绍下volatile关键字是如何解决多线程中的可见性有序性问题，以及底层的实现原理。

Volatile 是什么

Volatile 是 Java 中的一个关键字，专门用于修饰变量，堪称多线程编程中的 “特殊标记” 。一旦一个变量被它修饰，就如同被赋予了特殊的 “魔力”，具备了与众不同的特性。

从本质上来说，Volatile 是 Java 提供的轻量级同步机制。相较于其他复杂的同步手段，它就像是一把轻盈却锋利的剑，虽不具备全方位的防护能力，但在特定的场景下，能发挥出高效且精准的作用。它主要有两大核心作用：保证变量的可见性以及禁止指令重排。

在多线程的世界里，每个线程都有自己的工作内存，就像一个个独立的小仓库，线程对变量的操作通常是在自己的工作内存中进行的。而主内存则像是一个公共的大仓库，存放着共享变量。当一个线程修改了被 Volatile 修饰的变量时，它会立即将新值写回到主内存中，就如同迫不及待地将自己仓库中的新物品放回公共大仓库。同时，其他线程在读取这个变量时，也会直接从主内存中获取最新的值，而不是从自己工作内存的缓存中读取旧值，这样就保证了变量值在不同线程间的实时可见。

指令重排是编译器和处理器为了提高程序性能而进行的一种优化策略，它会在不影响单线程执行结果的前提下，对指令的执行顺序进行重新排列。但在多线程环境下，这种重排可能会引发数据不一致的问题。Volatile 关键字就像是给指令们划定了一条不可逾越的红线，禁止对被它修饰变量的相关指令进行重排，确保多线程环境下操作的顺序执行。例如，在某些涉及到初始化操作和变量赋值的场景中，如果没有 Volatile 的约束，指令重排可能会导致其他线程在变量还未完全初始化时就读取到它的值，从而引发错误。而有了 Volatile，就可以保证初始化操作先于变量赋值完成，进而保证程序的正确性。

为什么需要 Volatile

Volatile 解决的问题

它主要通过保证变量的可见性和禁止指令重排，有效地解决了多线程环境下共享变量的同步问题。

在保证变量可见性方面，Volatile 就像是在各个线程的工作内存与主内存之间搭建了一条高速信息通道。当一个线程修改了被 Volatile 修饰的变量时，它会立即将新值写回到主内存中，就如同在公共大仓库中及时更新了物品信息。同时，其他线程在读取这个变量时，也会直接从主内存中获取最新的值，而不是从自己工作内存的缓存中读取旧值。这样一来，所有线程看到的变量值始终是最新的，避免了数据不一致的问题。例如，在一个多线程协作的任务中，某个线程负责更新任务的进度状态，其他线程则根据这个进度状态来决定下一步的操作。如果进度状态变量被 Volatile 修饰，那么当负责更新的线程修改了进度值后，其他线程能够立刻获取到最新的进度，从而保证整个任务的协调进行。

禁止指令重排则是 Volatile 的另一大重要作用。它就像是给指令们制定了严格的规则，不允许它们随意改变执行顺序。在多线程环境下，如果没有 Volatile 的约束，编译器和处理器可能会为了提高性能而对指令进行重排，这就可能导致程序的执行结果与预期不符。比如，在单例模式的实现中，如果没有使用 Volatile 修饰单例对象，在多线程环境下可能会出现指令重排，导致其他线程在单例对象还未完全初始化时就获取到它，从而引发空指针异常等问题。而有了 Volatile，就可以确保单例对象的初始化操作先于其他线程对它的访问，保证了单例模式的正确性。

Volatile 的工作原理

Java 内存模型（JMM）

在深入探究 Volatile 关键字的工作原理之前，我们首先需要了解 Java 内存模型（JMM）的基本概念，它就像是多线程编程世界的底层架构蓝图，为我们理解多线程之间的内存交互提供了基础框架。

JMM 是 Java 虚拟机规范中定义的一种抽象的内存模型，它描述了一组规则和规范，用于控制 Java 程序中各个线程对内存的访问。在 JMM 中，内存被分为主内存和工作内存两部分。主内存就像是一个公共的大仓库，是所有线程共享的内存区域，存放着共享变量，比如类的静态变量、实例变量等。它就像一个信息的中央存储站，为所有线程提供数据支持。而工作内存则是每个线程私有的内存区域，类似于线程自己的小仓库，线程对变量的操作都在工作内存中进行。线程在工作内存中保存了主内存中共享变量的副本，当线程需要读取共享变量时，它会从自己的工作内存中获取副本；当线程修改了共享变量的副本后，需要将修改后的值同步回主内存。

线程对变量的读写操作在这两个内存区域间的交互过程，就像是一场精心编排的舞蹈。当线程要读取一个共享变量时，它会首先从主内存中将变量的值复制到自己的工作内存中，就如同从公共大仓库中取走一份货物到自己的小仓库。在工作内存中，线程对变量进行各种操作。而当线程完成对变量的修改后，又会将新值写回到主内存，就像把小仓库中修改后的货物重新放回公共大仓库。然而，这个看似简单的过程却隐藏着一个问题：由于每个线程都有自己独立的工作内存，并且对变量的操作是异步进行的，这就可能导致不同线程之间对共享变量的修改不能及时被其他线程感知，从而引发数据不一致的问题。例如，线程 A 修改了工作内存中的共享变量 x，并将其写回主内存，但此时线程 B 的工作内存中仍然保存着变量 x 的旧值，它并不知道线程 A 已经对 x 进行了修改，直到线程 B 再次从主内存中读取变量 x，才会获取到最新的值。这就是多线程编程中常见的可见性问题，而 Volatile 关键字的作用之一，就是解决这个问题。

可见性的实现机制

Volatile 关键字保证可见性的实现机制，就像是在主内存和工作内存之间搭建了一条高速信息通道，确保一个线程对变量的修改能立即同步到主内存，并且其他线程能及时读取到最新值。

当一个变量被 Volatile 修饰时，JVM 会在对该变量的写操作和读操作前后插入内存屏障。内存屏障是一种特殊的指令，它可以阻止指令重排序，并保证特定的内存操作顺序。在写操作时，JVM 会在写操作后插入一个写屏障（Store Barrier）。这个写屏障就像是一个严格的监工，它会确保在写操作完成后，将修改后的值立即刷新到主内存中，使得其他线程能够看到最新的值。例如，当线程 A 修改了 Volatile 修饰的变量 x 后，写屏障会强制线程 A 将变量 x 的新值写回到主内存，保证主内存中的 x 值是最新的。

在读操作时，JVM 会在读操作前插入一个读屏障（Load Barrier）。读屏障就像是一个警惕的哨兵，它会确保在读取变量时，先从主内存中获取最新的值，而不是从线程自己的缓存中读取旧值。比如，当线程 B 要读取 Volatile 修饰的变量 x 时，读屏障会强制线程 B 从主内存中读取变量 x 的值，这样线程 B 就能获取到线程 A 修改后的最新值，从而保证了可见性。

除了内存屏障，在硬件层面，Volatile 变量的可见性还依赖于处理器的缓存一致性协议，如 MESI 协议。当一个线程修改了某个 Volatile 变量，处理器会通知其他处理器该变量已经修改，导致其他处理器中的该变量缓存行无效。这样，下次其他处理器读取该变量时，必须从主内存中重新加载，从而保证了最新值的可见性。例如，在一个多核处理器系统中，线程 A 在处理器 1 上修改了 Volatile 变量 x，处理器 1 会通过缓存一致性协议向其他处理器广播这个修改消息，处理器 2、处理器 3 等接收到消息后，会将它们缓存中的变量 x 标记为无效。当处理器 2 上的线程 B 要读取变量 x 时，由于其缓存中的 x 已经无效，它就会从主内存中重新读取最新的 x 值。

禁止指令重排的原理

在多线程编程中，指令重排是一个常见的优化策略，它会在不影响单线程执行结果的前提下，对指令的执行顺序进行重新排列，以提高程序的性能。然而，在多线程环境下，指令重排可能会导致程序出现意想不到的结果。Volatile 关键字的另一个重要作用就是禁止指令重排，确保代码执行顺序与编写顺序一致。

Volatile 关键字禁止指令重排的原理，同样依赖于内存屏障。当一个变量被 Volatile 修饰时，JVM 会在对该变量的读写操作前后插入特定的内存屏障。在写操作时，JVM 会在写操作前插入一个 StoreStore 屏障，确保在这次写操作之前的所有普通写操作都已完成。然后在写操作后插入一个 StoreLoad 屏障，强制所有后来的读写操作都在此次写操作完成之后执行。例如，有如下代码：

volatile int x;

int y;

// 线程A执行

y = 10;

x = 20;

在这个例子中，当线程 A 执行x = 20这个写操作时，StoreStore 屏障会确保y = 10这个普通写操作已经完成，然后 StoreLoad 屏障会保证后续对 x 或其他变量的读写操作都在x = 20之后执行，避免了指令重排导致的问题。

在读操作时，JVM 会在读操作前插入一个 LoadLoad 屏障，确保在此次读操作之前的所有读操作都已完成。然后在读操作后插入一个 LoadStore 屏障，防止在此次读操作之后的写操作被重排序到读操作之前。比如，有如下代码：

volatile int x;

int y;

// 线程B执行

if (x > 0) {

   y = 30;

}

当线程 B 执行if (x > 0)这个读操作时，LoadLoad 屏障会确保之前的读操作都已完成，LoadStore 屏障会保证y = 30这个写操作不会被重排序到读操作之前，从而保证了程序的正确性。

Volatile 的使用场景

状态标志变量

在多线程编程中，状态标志变量是一种常见的用于控制线程执行流程的方式。Volatile 关键字在这种场景下发挥着重要作用，它能确保一个线程对状态标志变量的修改，能被其他线程及时感知到。

以一个简单的线程停止示例来说明。假设有一个任务线程，它需要根据一个状态标志来决定是否继续执行任务。代码如下：

public class TaskRunner implements Runnable {

   private volatile boolean running = true;

   @Override
   public void run() {
       while (running) {
           // 执行任务
           System.out.println("Task is running...");
           try {
               Thread.sleep(1000);
           } catch (InterruptedException e) {
               e.printStackTrace();
           }
       }
       System.out.println("Task is stopped.");
   }
   public void stop() {
       running = false;
   }
}

在上述代码中，running是一个状态标志变量，并且被volatile修饰。当主线程调用stop()方法将running设置为false时，由于volatile保证了可见性，任务线程能立即感知到这个变化，从而停止循环，结束任务的执行。如果running没有被volatile修饰，可能会出现任务线程无法及时获取到running的最新值，导致任务无法停止的情况。比如，任务线程在自己的工作内存中缓存了running的旧值，而主线程对running的修改没有及时同步到任务线程的工作内存，任务线程就会继续使用旧值，一直执行循环。

单例模式的双重检查锁定（DCL）

单例模式是一种常用的设计模式，它确保一个类在整个应用程序中只有一个实例。在多线程环境下实现单例模式时，双重检查锁定（DCL）是一种常见的方式，而volatile关键字在其中起着至关重要的作用，它可以防止指令重排，避免其他线程获取到未完全初始化的实例。

下面是使用双重检查锁定实现单例模式的代码：

public class Singleton {

   private static volatile Singleton instance;

   private Singleton() {
       // 私有构造函数，防止外部实例化
   }

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

在这个实现中，instance被volatile修饰。当instance = new Singleton()这行代码执行时，实际上会进行三个步骤：首先为Singleton对象分配内存空间；然后调用构造函数初始化对象；最后将对象引用赋值给instance 。在多线程环境下，如果没有volatile关键字，编译器和处理器可能会对这三个步骤进行指令重排，比如先分配内存空间并将对象引用赋值给instance，然后再调用构造函数初始化对象。这样，当一个线程执行到instance = new Singleton()，但还未完成构造函数的调用时，另一个线程可能会进入第一个if (instance == null)判断，由于此时instance已经被赋值（虽然对象还未完全初始化），就会直接返回一个未完全初始化的instance，导致程序出现错误。而volatile关键字禁止了这种指令重排，确保了对象的初始化操作先于其他线程对instance的访问，从而保证了单例模式的正确性。

轻量级同步

在一些对性能要求高、操作简单的场景中，Volatile 可以作为轻量级同步机制替代重量级的锁，提高程序执行效率。例如，在一个读多写少的场景中，多个线程主要对共享变量进行读取操作，只有少数线程会进行写操作。如果使用锁机制，每次读取操作都需要获取锁，这会带来较大的开销。而使用volatile修饰共享变量，由于它保证了可见性，读线程可以直接读取到最新的值，不需要获取锁，从而大大提高了程序的执行效率。

假设我们有一个简单的计数器，多个线程需要读取计数器的值，偶尔有一个线程会对计数器进行递增操作。代码如下：

public class Counter {

   private volatile int count = 0;

   public int getCount() {
       return count;
   }

   public void increment() {
       count++;
   }
}

在这个例子中，count被volatile修饰。读线程调用getCount()方法时，可以直接获取到最新的count值，无需获取锁。写线程调用increment()方法时，虽然count++操作不是原子的，但由于写操作较少，这种非原子性带来的影响相对较小。如果使用锁机制，每次读取和写入都需要获取锁，会增加额外的开销，降低程序的性能。然而，需要注意的是，volatile不能完全替代锁机制。如果操作涉及到复杂的逻辑，或者需要保证原子性，仍然需要使用锁或者其他同步工具。比如，如果increment()方法中除了count++，还涉及到其他对共享资源的复杂操作，就不能仅仅依靠volatile，而需要使用锁来保证操作的原子性和完整性。

Volatile 与其他同步机制的比较

与 Synchronized 的对比

在 Java 的多线程编程领域中，Volatile 和 Synchronized 都是重要的同步工具，但它们在功能和使用场景上存在着明显的差异。

从原子性角度来看，Volatile 关键字不具备原子性。这意味着对于一些复合操作，如count++，即使count被volatile修饰，在多线程环境下也无法保证操作的原子性。因为count++实际上包含了读取、修改和写入三个步骤，而 Volatile 无法保证这三个步骤的原子执行。例如，当多个线程同时执行count++时，可能会出现数据不一致的情况。而 Synchronized 关键字则可以保证原子性，它通过锁定对象，使得同一时刻只有一个线程能够进入被同步的代码块或方法，从而确保了代码块或方法中所有操作的原子性。比如，在一个银行账户的取款操作中，使用 Synchronized 可以保证取款操作的原子性，避免出现多线程同时取款导致账户余额错误的问题。

在可见性方面，两者都能保证可见性。Volatile 通过内存屏障机制，使得一个线程对变量的修改能立即同步到主内存，并且其他线程能及时读取到最新值。Synchronized 在进入同步块时，会将变量从线程的工作内存中清除，从主内存中读取；退出同步块时，会将对共享变量的修改刷新到主内存中，从而保证了可见性。例如，在一个多线程协作的任务中，使用 Volatile 或 Synchronized 都能确保各个线程对共享变量的修改能被其他线程及时感知。

有序性上，Volatile 禁止指令重排，确保代码执行顺序与编写顺序一致。Synchronized 虽然也能保证有序性，但它是通过串行化执行来实现的，即同一时刻只有一个线程能够执行被同步的代码，从而间接保证了有序性。比如，在单例模式的实现中，使用 Volatile 可以禁止指令重排，避免其他线程获取到未完全初始化的实例；而使用 Synchronized 则通过锁定对象，保证了实例化过程的串行化，同样确保了单例的正确性。

性能表现上，Volatile 由于不涉及锁的获取和释放，不会造成线程的阻塞，所以在高并发的读多写少场景下，性能表现较好。而 Synchronized 在竞争激烈时，会导致线程频繁阻塞和唤醒，从而产生较大的性能开销。例如，在一个简单的计数器场景中，如果读操作远远多于写操作，使用 Volatile 修饰计数器变量可以提高程序的执行效率；但如果存在大量的写操作，并且需要保证操作的原子性，此时使用 Synchronized 更为合适。

与 Lock 的对比

Lock 是 Java 并发包 JUC 下的接口，它提供了比 Volatile 更强大和灵活的同步控制功能。与 Volatile 相比，Lock 可以实现更细粒度的控制，例如在try-finally块中使用lock和unlock，能够确保即使发生异常，锁也能被释放。此外，Lock 还支持可中断的锁获取操作、尝试获取锁以及条件变量等功能。比如，在一个复杂的多线程任务中，可能需要根据不同的条件来控制线程的执行，此时使用 Lock 的条件变量可以实现更灵活的线程间通信和协作。

然而，Volatile 在简单场景中具有明显的优势。它的使用方式简单，开销小，不会像 Lock 那样需要手动获取和释放锁，从而减少了出错的可能性。例如，在一些对性能要求高、操作简单的场景中，如状态标志变量的使用，使用 Volatile 可以作为轻量级同步机制替代 Lock，提高程序执行效率。总的来说，Lock 适用于复杂的同步需求，而 Volatile 则更适合简单场景下的轻量级同步。

使用 Volatile 的注意事项

原子性问题

虽然 Volatile 关键字在保证可见性和禁止指令重排方面表现出色，但它却无法保证复合操作的原子性。这就像是一位拥有强大防御能力的战士，虽然能抵御外界的干扰，但在面对复杂的内部操作时却显得力不从心。

以自增操作count++为例，尽管count被volatile修饰，但count++这个操作实际上包含了读取count的值、增加 1 以及写回count的新值这三个步骤。在多线程环境下，这些步骤并非原子性的，也就是说，它们可能会被其他线程的操作所打断。比如，当线程 A 读取了count的值为 10，正准备进行增加 1 操作时，线程 B 也读取了count的值，同样是 10 。然后线程 A 完成了增加 1 操作，将count的值更新为 11 并写回主内存。接着，线程 B 继续执行它的操作，由于它读取的count值是 10，所以它也将count增加 1，得到 11 并写回主内存。这样一来，原本应该增加 2 的count，最终只增加了 1，出现了数据不一致的问题。

为了更直观地感受这个问题，我们来看下面的代码示例：

public class VolatileAtomicityTest {

   private static volatile int count = 0;

   public static void main(String[] args) throws InterruptedException {

       Thread[] threads = new Thread[100];

       for (int i = 0; i < threads.length; i++) {
           threads[i] = new Thread(() -> {
               for (int j = 0; j < 100; j++) {
                   count++;
               }
           });
           threads[i].start();
       }

       for (int i = 0; i < threads.length; i++) {
           threads[i].join();
       }

       System.out.println("Expected count: " + (threads.length * 100));
       System.out.println("Actual count: " + count);
   }
}

在这个例子中，我们创建了 100 个线程，每个线程对count进行 100 次自增操作。理论上，如果count++是原子操作，最终的count值应该是 100 * 100 = 10000 。然而，由于count++不具备原子性，在多线程环境下，最终的count值通常会小于 10000 。这充分证明了 Volatile 变量在复合操作中无法保证原子性。

适用场景的局限性

Volatile 虽然在某些场景下能够发挥重要作用，但它并非适用于所有多线程场景，就像一把钥匙只能打开特定的锁一样，我们需要根据实际情况来选择合适的同步机制。

在一些涉及复杂同步逻辑的场景中，仅仅依靠 Volatile 是远远不够的。例如，在一个多线程的银行转账系统中，转账操作不仅涉及到对账户余额的修改，还可能涉及到事务处理、日志记录等多个步骤。这些步骤之间存在着复杂的依赖关系，需要保证它们的原子性和一致性。如果使用 Volatile 来修饰账户余额变量，虽然可以保证余额的可见性，但无法保证整个转账操作的原子性，可能会导致转账过程中出现数据不一致的问题。在这种情况下，我们就需要使用更强大的同步机制，如synchronized关键字或Lock接口来保证操作的原子性和完整性。

当需要保证原子性时，Volatile 也无法满足需求。除了前面提到的自增操作count++，像count = count + 1、count--等复合操作，Volatile 都无法保证其原子性。在这些情况下，我们可以使用java.util.concurrent.atomic包中的原子类，如AtomicInteger、AtomicLong等，它们提供了原子性的操作方法，能够有效地解决原子性问题。例如，使用AtomicInteger来实现计数器功能，代码如下：

import java.util.concurrent.atomic.AtomicInteger;

public class AtomicCounter {

   private static AtomicInteger count = new AtomicInteger(0);

   public static void main(String[] args) throws InterruptedException {

       Thread[] threads = new Thread[100];

       for (int i = 0; i < threads.length; i++) {
           threads[i] = new Thread(() -> {
               for (int j = 0; j < 100; j++) {
                   count.incrementAndGet();
               }
           });
           threads[i].start();
       }

       for (int i = 0; i < threads.length; i++) {
           threads[i].join();
       }
       System.out.println("Expected count: " + (threads.length * 100));
       System.out.println("Actual count: " + count.get());
   }
}

在这个例子中，AtomicInteger的incrementAndGet()方法是原子性的，能够保证在多线程环境下计数器的正确性。最终输出的Actual count将与Expected count一致，都是 10000 。这表明，在需要保证原子性的场景中，使用原子类是一个更合适的选择。

总结

Volatile 关键字作为 Java 多线程编程中的重要组成部分，通过保证变量的可见性和禁止指令重排，有效地解决了多线程环境下共享变量的同步问题。在实际应用中，我们可以将 Volatile 用于状态标志变量、单例模式的双重检查锁定以及轻量级同步等场景。然而，我们也要清楚地认识到 Volatile 的局限性，它无法保证复合操作的原子性，也并非适用于所有的多线程场景。