Java volatile详解：可见性、有序性与内存屏障原理

先把话放前头如果你已经能熟练写多线程代码却还没搞懂 volatile 到底是什么、它凭什么能保证可见性、为什么不能保证原子性那这篇就是给你准备的。这篇是 Java 进阶系列的第十三篇主题就一个字volatile。它是 Java 并发编程里最轻量的线程同步机制也是面试八股文里的常青树几乎每一场 Java 后端面试都会问到。你不需要背答案只需要理解它的设计动机和运行机制就能在面试时讲得比背答案的人深一层。volatile 只有两个核心能力保证可见性、禁止指令重排序。这两个能力听起来简单但背后牵扯到 Java 内存模型JMM、CPU 缓存一致性协议、内存屏障、编译器和 CPU 的指令重排规则以及单例模式双重检查锁DCL为什么必须用它。这篇文章我会从一段诡异的代码讲起把原理拆开揉碎再给你一套可以直接回答面试官的逻辑框架。1. 为什么要关注 volatile先从一段诡异的并发代码说起我见过不少工作两三年的开发说起 volatile 能背出可见性、有序性六个字但真要他解释为什么两个线程之间会看不见对方修改的值他就开始含糊了。要理解 volatile你得先理解一个问题在 Java 多线程环境下为什么一个线程改了共享变量另一个线程可能完全感知不到1.1 一段跑不起来的死循环代码先看这段代码你可以在本地跑一下大概率会遇到诡异的现象。public class VolatileDemo { private static boolean flag true; public static void main(String[] args) throws InterruptedException { Thread t1 new Thread(() - { System.out.println(线程1启动开始执行循环...); while (flag) { // 空循环 } System.out.println(线程1退出循环); }); t1.start(); Thread.sleep(1000); // 主线程修改 flag 为 false flag false; System.out.println(主线程已将 flag 修改为 false); } }你预想的结果是主线程把 flag 改成 false 之后线程 t1 的 while 循环条件不成立循环退出打印线程1退出循环。但实际情况很可能是主线程打印完已将 flag 修改为 false之后程序一直没有结束线程 t1 还在死循环里跑着。为什么按直觉来说t1 每次循环都要读取 flag 的值主线程改完它应该马上就能看到才对。但事实是t1 压根看不到 flag 的变化。这就是典型的可见性问题。你如果在这里把 flag 加上 volatile 修饰程序立刻恢复正常。这个实验几乎在每台机器上都能复现是理解 volatile 的最好入口。1.2 Java 内存模型问题背后的根源这个问题的根源要从 Java 内存模型Java Memory ModelJMM说起。JMM 是 Java 虚拟机规范中定义的一套抽象规则它规定了多线程环境下共享变量的读写行为。JMM 把内存划分成两部分主内存和工作内存也叫本地内存。主内存所有线程共享的内存区域存放所有的共享变量。工作内存每个线程私有的内存区域线程对变量的所有操作读取、赋值等都必须在工作内存中进行不能直接读写主内存。线程之间不能直接访问对方的工作内存变量传递必须通过主内存来完成。整体流程是这样的线程从主内存读取共享变量复制一份到自己的工作内存。线程在工作内存中修改这个副本。线程在某个时机把工作内存中的新值刷回主内存。问题就出在某个时机上。这个时机不是由你控制的而是由 JVM 和底层硬件共同决定的它可能是立即回写也可能延迟回写。如果线程 t1 在循环开始前已经把 flag 的值拷贝到了自己的工作内存而主线程修改主内存中的 flag 之后t1 的工作内存里的副本一直是旧值那 t1 就永远看不到变化。更深一层说这个模型是对底层硬件架构的抽象。在实际的 CPU 架构中每个 CPU 核心都有自己的缓存L1、L2、L3CPU 计算时先读缓存缓存未命中才读主内存。多个核心各自缓存了同一份数据的副本就存在缓存不一致的问题。JMM 的工作内存本质上就是对 CPU 缓存的一个抽象。好到这里你就能明白一个关键点了可见性问题的本质是线程工作内存中的副本和主内存中的最新值不一致。而 volatile 要解决的就是强制让线程在读写共享变量时直接绕过工作内存的缓存逻辑和主内存保持一致。具体怎么做到后面讲。1.3 你可能会踩的坑这个实验为什么有时候正常有同学会问我跑这段代码为什么有时候正常退出了这里要说明JMM 是抽象规范具体的执行行为受到 JVM 版本、JIT 编译器优化程度、CPU 架构、线程调度时机等多方面影响。在极端情况下JIT 编译器甚至会把 while (flag) 这种循环直接优化成类似if (!flag) while(true);的形式因为编译器认为循环体内没有修改 flagflag 在循环过程中不会变。这实际上是编译器层面的优化导致的。所以这段代码不是一定死循环而是有概率死循环。这个概率在不同环境下差别很大有的机器几乎稳定复现有的机器怎么跑都正常。无论哪种情况它都是一颗定时炸弹因为结果不可控。而加上 volatile就是明确告诉 JVM 和 CPU这个变量每次都要从主内存重新读不许给我缓存优化也不许给我重排序。2. volatile 到底做了什么两个核心语义拆解volatile 的官方定义用一句话说当一个共享变量被 volatile 修饰后它就有两个语义——保证不同线程对该变量的可见性以及禁止指令重排序优化。听起来还是抽象我一个个拆开讲。2.1 可见性让共享变量曝光在所有线程面前先讲可见性。volatile 变量的读写规则是这样的线程对 volatile 变量的写操作会立即把新值刷新到主内存。线程对 volatile 变量的读操作会直接从主内存中读取最新值而不是从工作内存的缓存副本中读。这个规则等同于一个线程写了一个 volatile 变量其他线程再读这个变量时一定能读到最新写入的值。这就保证了跨线程的可见性。你可以这么理解普通变量的读写像是工作内存里的私有记事本线程各记各的什么时候同步给主内存全看心情volatile 变量的读写像是公告栏上的大字报写的人贴上去读的人直接看公告栏不存在拿着旧复印件的问题。这里有一个关键点volatile 的可见性并不仅仅是自己写、自己读这么简单。它还牵扯到 CPU 层的缓存一致性协议比如 x86 架构下的 MESI 协议。当线程对 volatile 变量执行写操作时处理器会发出一个 Lock 前缀指令这个指令有两大作用将当前处理器缓存行的数据写回到系统内存。这个写回操作会使其他 CPU 内核里缓存了同一内存地址的缓存行失效。也就是说一个 CPU 核心改了 volatile 变量其他核心发现自己缓存的数据失效了下次读取时就必须从主内存重新拉取。这是硬件层面的保障把这层逻辑讲出来面试官会知道你确实懂底层而不是只会背概念。2.2 有序性编译器和 CPU 的重排是怎么被拦住的第二语义是禁止指令重排序。先解释什么是重排序。为了提高性能编译器和 CPU 在保证单线程执行结果不变的前提下可能会对指令的执行顺序进行调整。比如int a 1; // 指令1 int b 2; // 指令2 int c a b; // 指令3如果编译器发现指令3依赖指令1和指令2的结果那指令3必须在指令1、2之后执行。但指令1和指令2之间没有依赖关系编译器可能会让指令2先于指令1执行这对单线程结果没有影响。问题在于多线程环境下指令重排序可能带来不可预期的结果。举个经典的例子// 线程 A data 100; // 语句1 ready true; // 语句2, ready是volatile变量 // 线程 B if (ready) { int result data * 2; // 如果result不是200就出问题了 }如果 ready 不是 volatile那么语句1和语句2之间没有数据依赖关系编译器或 CPU 可能把执行顺序重排成先执行 ready true再执行 data 100。在单线程里这没问题但线程 B 可能在 data 还没赋值的时候就看到了 ready true然后读到一个旧值或默认值 0result 就变成了 0 而不是 200。当 ready 是 volatile 时JVM 会在这个操作周围插入内存屏障禁止屏障前后的指令跨越屏障重排序保证写 ready 之前的指令data 100不能跑到写 ready 之后也保证读 ready 之后的指令读 data不能跑到读 ready 之前。这就是有序性的保障。2.3 内存屏障volatile 的底层实现细节上面说到了内存屏障这是 volatile 实现机制里最硬核的部分。聊聊这个因为这是加分项。内存屏障Memory Barrier是一类 CPU 指令作用是强制内存访问操作的顺序并确保内存可见性。在 JMM 中针对 volatile 变量规定了几种屏障规则LoadLoad 屏障禁止上面的普通读操作和下面的 volatile 读操作重排序。StoreStore 屏障禁止上面的普通写操作和下面的 volatile 写操作重排序。LoadStore 屏障禁止上面的普通读操作和下面的 volatile 写操作重排序。StoreLoad 屏障禁止上面的 volatile 写操作和下面的普通读/写操作重排序。具体到 volatile 的操作规则可以总结为在每个 volatile 写操作的前面插入一个 StoreStore 屏障禁止前面的普通写和后面的 volatile 写重排序保证普通写的结果对后续的 volatile 写可见。在每个 volatile 写操作的后面插入一个 StoreLoad 屏障禁止 volatile 写和后面可能有的 volatile 读/写重排序。在每个 volatile 读操作的后面插入 LoadLoad 屏障 和 LoadStore 屏障禁止 volatile 读和后面的普通读、普通写重排序。在某些 JVM 实现里还会在 volatile 读前面插入 LoadLoad 屏障具体看版本和 CPU 架构。用大白话说内存屏障就像一道栅栏指令可以在我这一侧随便折腾但不许从栅栏这边跳到那边。JVM 通过插入这些栅栏把 volatile 的内存语义完整地落地到了指令级别。这里我给一个忠告面试时不需要把所有屏障类别背得滚瓜烂熟但一定要能说出volatile 通过内存屏障禁止指令重排序在 x86 架构下 StoreLoad 屏障是最关键的这句话。这比背口号强得多。3. volatile 与 synchronized 怎么选对比与适用范围很多初学 Java 并发的同学会有一个困惑既然 volatile 能解决可见性问题那么它是不是能替代 synchronized答案是绝对不能。3.1 一张对比表看清本质区别先把两者的核心差异拉一张表后面逐个解释。对比维度volatilesynchronized修饰对象只能修饰变量成员变量、静态变量修饰方法、代码块线程阻塞不阻塞线程会阻塞线程重量级锁原子性不保证保证可见性保证保证有序性保证禁止重排序保证加锁解锁的语义性能开销轻量开销小相对较重锁竞争时使用场景一写多读、状态开关复合操作、多个线程同时写最重要的区别就是原子性。volatile 不保证原子性synchronized 保证。这意味着如果一个操作是读-改-写这种复合操作比如count它包含读 count、count1、写回 count 三个步骤用 volatile 修饰 count 是没法保证线程安全的。两个线程可能同时读到 count5然后各自加 1 写回最后 count 只变成 6而不是 7。synchronized 则不同它通过锁机制保证同一时刻只有一个线程能执行被锁住的代码块三个步骤要么全部执行要么全部不执行中间不可能被其他线程插入。3.2 什么场景适合用 volatile三个典型特征那么什么时候用 volatile我总结了三个典型特征满足这些场景用 volatile 就是最合适的选择对变量的写操作不依赖于当前值。或者说单个线程写、其他线程读。该变量与其他状态变量无关。对该变量的读写不需要加锁保护且没有其他线程会同时写这个变量。最常见的应用场景就是状态标志位。文章开头那段代码里的flag就是典型例子一个线程改其他线程读写操作不依赖当前值用 volatile 完美解决。还有一个高频场景是双重检查锁Double-Checked LockingDCL这个我们下一节专门讲它是 volatile 面试中的必考题。3.3 一个反直觉的经验volatile 不是银弹我在实际开发中见过不少误用 volatile 的案例。最常见的一种是拿 volatile 修饰计数器volatile int count 0; public void increment() { count; // 错误这不是原子操作 }这种写法在多线程环境下会丢数据而且问题非常隐蔽因为大部分时候结果正确只有高并发下才会偶发异常。排查这种问题非常头疼因为你很难通过代码审查发现问题只能通过压测才能暴露。另一个误区是认为 volatile 能保证复合操作的安全性比如先检查后执行volatile boolean initialized false; public void init() { if (!initialized) { // 做初始化操作... initialized true; } }两个线程可能同时通过!initialized检查然后重复执行初始化逻辑。这里 volatile 只保证了可见性但检查-设置这个复合动作并不具备原子性需要 synchronized 或 AtomicBoolean 才能正确实现。所以我的建议是能用 volatile 的场景非常有限界定标准就一句话——这个变量是单写多读状态开关吗是用 volatile不是老老实实上锁或使用原子类。4. 实战拆解单例模式双重检查锁为什么离不开 volatilevolatile 在单例模式中的应用是 Java 面试中几乎绕不开的经典题目。DCLDouble-Checked Locking写了很多年很多人代码写得出来但你要问他为什么这个单例要加 volatile他支支吾吾说不清楚。这节我把这个抠明白。4.1 经典代码逐行拆解先看标准的 DCL 单例实现public class Singleton { // volatile 是必须的吗 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 null是为了避免每次调用都进入同步代码块提升性能。synchronized 代码块保证同一时刻只有一个线程执行实例化逻辑。第二次检查instance null是防止多个线程同时通过第一次检查一个线程创建完后面的线程不要再重复创建。这段代码看起来天衣无缝但如果instance不加 volatile它其实存在严重的隐患。隐患就藏在instance new Singleton()这行代码里。4.2 new Singleton() 到底经历了什么很多人以为new Singleton()就是一个简单的对象创建过程其实它在字节码层面至少包含四个步骤在堆内存中分配一块内存空间。在栈上生成一个指向该内存地址的引用。在分配的内存上执行 Singleton 的构造方法完成对象初始化。将引用指向这块内存空间。从顺序上看应该是先初始化对象再把引用指向它。但由于指令重排序的存在步骤3和步骤4的顺序可能发生调换。也就是说对象可以先引用指向内存空间然后再执行构造方法。4.3 不加 volatile 的后果拿到一个半初始化的对象如果这两个步骤发生重排序会怎样把这个场景放到多线程中线程 A 进入同步代码块执行instance new Singleton()。JVM 分配了内存把引用先指向了这块地址此时对象还没有执行构造方法是半初始化状态。此时线程 B 执行第一次检查instance null发现 instance 不是 null直接返回了这个引用。线程 B 拿着这个半初始化的对象去调用方法访问到的是默认值0、null、false甚至因为对象内部状态不完整而抛出异常。如果 instance 不加 volatileJVM 和 CPU 是允许这种重排序发生的。这就是 DCL 单例必须加 volatile 的根本原因通过 volatile 禁止指令重排序保证引用指向内存空间这个操作一定发生在对象构造完成之后。这个案例也是 volatile 第二个语义有序性最典型的应用场景。面试时能把这个流程讲清楚比单纯说为了禁止重排序要深入得多。4.4 一个更容易理解的实现静态内部类单例讲到这里顺便提一嘴其实现在很多人已经不再用 DCL 单例了而是用静态内部类方式代码更简洁也不需要 volatilepublic class Singleton { private Singleton() {} private static class Holder { private static final Singleton INSTANCE new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }静态内部类方案利用 JVM 类加载机制天然实现了懒加载和线程安全Holder只有在getInstance()第一次被调用时才会被加载和初始化类加载过程由 JVM 保证线程安全。这种写法比 DCL 更优雅也不容易写错。但它对为什么 class 初始化是线程安全的这个问题有要求所以面试官还是经常拿 DCL 来考察你对 volatile 的理解。我个人在实际项目里的选择是能不用 DCL 就不用 DCL静态内部类或者枚举单例更稳。但理解 volatile 在 DCL 中的价值是绕不开的面试考点也有助于你理解并发编程的深层逻辑。5. 高频面试题与常见坑volatile 不能做什么最后这部分我把 volatile 面试中的高频问题和实际开发中的常见坑整理一遍。这也是全文的收尾部分希望对你有实际帮助。5.1 高频必问题volatile 能保证原子性吗答案不能。这是面试官最常用来终结背答案考生的问题。如果你只回答了不能等于把加分机会让了出去。正确的回答方式是把原理也讲出来volatile 只能保证可见性和有序性不能保证原子性。因为原子性要求的是要么全部执行要么全部不执行而 volatile 并不具备锁的排他性。比如count这种操作在字节码层面是读取、加一、写回三步操作两个线程可能同时读取 count 的值各自加一后写回最终结果比预期小。要保证原子性应该使用 synchronized 代码块或者 AtomicInteger 之类的原子类。这样回答面试官能立刻知道你理解的是机制而非概念。5.2 常见问题速查表再列一个高频问题速查表供你复习时快速对照问题标准回答要点volatile 和 synchronized 的区别volatile 轻量、不阻塞、不保证原子性synchronized 重量、阻塞、保证原子性volatile 能替代 synchronized 吗不能语义范围不同复合操作仍需锁或原子类volatile 的适用场景状态标志位、单次发布不可变对象、DCL 单例volatile 为什么不能保证原子性没有锁的排他性读-改-写复合操作可被并发破坏volatile 的性能代价比普通变量访问慢但比锁开销小强制约缓存和禁止重排什么是内存屏障屏障指令强制内存访问顺序防止指令重排序volatile 变量全用缓存一致性协议吗底层依赖缓存一致性协议如 MESI和锁前缀指令但这是硬件级实现JMM 层面用内存屏障抽象JMM 中 volatile 的读写规则写立即刷新主内存读从主内存刷新副本5.3 实际开发中的避坑建议根据我看过的生产故障整理几条关于 volatile 的实操经验送给正在写并发代码的你如果只是需要一写多读的标志位优先用 volatile不要动不动就上锁。锁会让代码变慢还会引入死锁风险。如果你需要线程安全的计数器直接用 AtomicInteger 或 LongAdder不要用 volatile 自旋的奇技淫巧那只会给自己挖坑。如果判断不了某个变量是否该加 volatile先画一张图标注哪个线程写、哪个线程读。只有单写多读才适合 volatile多写多读必须加锁。DCL 单例的 volatile 不要删不要觉得我 JIT 很聪明不会重排这是 JMM 规范层面的要求与具体运行环境无关。生产环境排查并发问题时如果怀疑可见性问题可以用 jstack 查看线程状态但更直接的方式是在相关变量上临时加 volatile 验证如果问题消失就基本能确认是可见性问题。5.4 最后说两句说实话volatile 是 Java 并发编程里最简单也最难的关键字。简单在于它的语义只有两条难在于它的背后牵扯到整个 JMM 的设计哲学以及 CPU、编译器和 JVM 三层之间的配合。你在面试时如果能把本文第 2 节的内存屏障和第 4 节的 DCL 案例讲透那已经超过绝大多数候选手了在实战中只要你能做到不滥用 volatile、不错用 volatile并发问题就少了一半。目前 Java 并发这一块我还在继续整理下一篇准备写 JMM 的 happens-before 规则这个和 volatile、synchronized 都强相关值得好好梳理。等写出来再和你细聊。