1. 开篇从一个“诡异”的程序说起很多 Java 初学者第一次接触 volatile 关键字都是在面试题或者并发编程的文章里。看到它的第一反应往往是“这不就是让变量在多个线程之间可见吗好像和 synchronized 差不多吧”结果真正写代码时程序还是会时不时抽风要么读到旧值要么计数少了几百次。为了让你真正搞懂 volatile我们先不急着背概念先看一段代码。假设有这样一个场景一个线程在不停地修改一个开关变量另一个线程根据这个开关决定要不要停止执行。很多人会写出下面这种代码public class StopFlagDemo { private static boolean stop false; public static void main(String[] args) throws InterruptedException { Thread worker new Thread(() - { int count 0; while (!stop) { count; } System.out.println(worker 线程结束count count); }); worker.start(); Thread.sleep(1000); stop true; System.out.println(主线程已经把 stop 设置为 true); } }按照正常的思维主线程休眠 1 秒后把 stop 改成 trueworker 线程应该马上退出循环并打印结果。但如果你真的跑这段代码很可能会出现一个尴尬的现象主线程已经打印了“stop 设置为 true”worker 线程却还在死循环程序永远不会结束。问题就出在 stop 这个变量上。worker 线程并没有在主线程修改 stop 之后“看到”这个最新值。换句话说stop 这个变量在多线程环境下出现了可见性问题。而我们今天的主角 volatile恰恰就是用来解决这一类问题的。把 stop 变量的声明改成下面这样private static volatile boolean stop false;再次运行worker 线程就能正常感知到 stop 的变化程序可以顺利结束。这个例子虽然简单但它背后藏着 volatile 最核心的价值保证变量在多个线程之间的可见性并且阻止一定的指令重排序。接下来这篇文章会用最通俗的语言从内存模型、可见性、有序性、原子性、底层实现、使用场景、常见误区等多个维度把 volatile 讲深、讲透。即使你之前对 JMM、内存屏障这些词一头雾水读完以后也能给别人讲清楚 volatile 到底是什么、能干什么、不能干什么。2. 为什么会有 volatile先理解多线程的三个麻烦要想真正明白 volatile 为什么存在我们必须先搞清楚多线程编程里的三个经典问题可见性、原子性和有序性。这三个问题就像三座大山几乎所有并发 bug 都能归结到它们身上。2.1 可见性你改了别人不一定看得到可见性指的是一个线程修改了共享变量之后另一个线程能不能立刻读到修改后的新值。在我们的 StopFlagDemo 例子中主线程修改了 stop但 worker 线程没有看到这就是可见性问题。为什么会出现这种情况因为现代计算机为了提高运行速度不会让 CPU 每次都去主内存里读取变量。每个 CPU 都有自己的高速缓存线程运行时很可能把变量缓存到自己的 CPU 缓存里。一个线程修改了自己缓存里的值如果没及时同步回主内存其他线程读取的还是自己缓存里的旧值。在 Java 内存模型里这种“缓存”抽象为每个线程拥有自己的工作内存。所有变量都存储在主内存中线程要操作变量必须先从主内存拷贝一份到自己的工作内存操作完成后再写回主内存。如果两个线程各自持有同一变量的副本又没有合适的同步机制就可能读到过期数据。volatile 变量具备可见性保证。当一个线程写 volatile 变量时会立即把新值刷新回主内存当另一个线程读 volatile 变量时会强制从主内存重新读取最新值。这样就避免了各线程各读各的缓存副本。2.2 原子性看似一行代码实际分好几步原子性指的是一个操作要么全部执行完成要么全部不执行中间不会被其他线程打断。很多人误以为“一行代码就是原子的”这其实是并发编程里最常见的误区。比如 i 这行代码它看起来只有一步实际在底层至少包含三个步骤读取 i 的当前值把当前值加 1把结果写回 i。如果有两个线程同时执行 i可能都读到了同一个旧值各自加 1 后写回最终 i 可能只增加了 1而不是我们期望的 2。这就是典型的原子性问题。需要特别强调的一点是volatile 并不保证原子性。也就是说即便你把 i 声明成 volatile两个线程同时执行 i依然可能丢失更新。这个问题我们后文会重点展开它是很多人用错 volatile 的根源。2.3 有序性代码不是从上到下执行的有序性指的是程序执行的顺序是否和代码书写顺序一致。直觉告诉我们代码当然是从上往下执行。但为了提高性能编译器、JVM 和 CPU 都可能在保证单线程语义不变的前提下对指令进行重排序。例如下面这段代码int a 1; int b 2; a a 3; b b 4;如果只看单线程结果最后 a 是 4b 是 6。但实际执行时CPU 可能先计算 b b 4再计算 a a 3甚至把后面的赋值提前。因为在单个线程看来这种重排并不影响最终结果。然而在多线程环境下重排序就可能引发严重问题。一个线程看到另一个线程的执行顺序和代码书写顺序不一致时就可能出现非常隐蔽的 bug。volatile 的一个重要能力就是通过内存屏障禁止特定类型的指令重排序。3. Java 内存模型volatile 的理论基础前面反复提到可见性、原子性、有序性这些背后有一套统一的规范就是 Java 内存模型简称 JMM。JMM 不是真实存在的物理硬件而是一套抽象的规则。它规定了多线程环境下共享变量的读写顺序、可见性以及哪些重排序是允许的、哪些是不允许的。理解 JMM 不需要陷入枯燥的规范条文抓住几个核心点就足够了。3.1 主内存和工作内存JMM 把内存抽象成两部分主内存和工作内存。主内存是共享的所有线程都能访问工作内存是线程私有的每个线程独有一份。线程不能直接读写主内存中的变量必须先把变量从主内存拷贝到自己的工作内存在工作内存中修改后再把结果写回主内存。这个抽象和真实的 CPU 缓存、寄存器并不完全等同但足够帮助我们理解并发问题的来源。可以这样记忆主内存相当于大家都能看到的共享白板工作内存相当于每个人手里的草稿纸。你修改自己草稿纸上的数字并不代表白板上的数字马上变掉。只有当你主动把草稿纸上的结果抄回白板别人才有机会看到。3.2 happens-before判断可见性的“因果关系”JMM 提出了 happens-before 原则用来描述两个操作之间的偏序关系。如果操作 A happens-before 操作 B那么 A 产生的影响对 B 可见且 A 在时间顺序上排在 B 前面。可以把 happens-before 理解成一种“因果承诺”。如果 A happens-before B那么 B 一定能够看到 A 的结果。JMM 保证了几条重要的 happens-before 规则程序顺序规则在同一个线程内前面的操作 happens-before 后面的操作。监视器锁规则对一个锁的解锁 happens-before 后续对这个锁的加锁。volatile 变量规则对一个 volatile 变量的写 happens-before 后续对这个 volatile 变量的读。传递性规则如果 A happens-before B且 B happens-before C那么 A happens-before C。volatile 之所以能解决可见性问题正是因为它建立在 happens-before 规则之上。一旦某个线程写入了 volatile 变量后续任何线程读取这个 volatile 变量都能看到这次写入并且还能看到写入线程在此之前对其他变量的修改。这个特性我们后续会用代码验证。4. volatile 到底能保证什么在进入具体场景之前我们先给 volatile 的能力做一个清晰、不夸大的总结。很多人背面试题时只记住一句“volatile 保证可见性、禁止指令重排、不保证原子性”这句话本身没错但如果不懂其中的细节还是会在实际开发中踩坑。4.1 保证可见性当一个线程修改 volatile 变量后新值会立刻刷新到主内存。其他线程读取 volatile 变量时必须从主内存中重新读取而不是使用自己工作内存里的旧副本。这样volatile 变量的最新值对所有线程真正可见。在 StopFlagDemo 中stop 声明为 volatile 后主线程把 stop 改成 true 的操作对其他线程可见worker 线程随即退出循环。4.2 禁止指令重排序volatile 的写操作和读操作之间会插入内存屏障阻止 JVM 和 CPU 对这些 volatile 操作的某些重排序。这样能在一定程度上保证代码执行的有序性。需要区分清楚的是volatile 并不能禁止所有重排序。它禁止的是和 volatile 变量相关的那些关键重排序。例如volatile 写之前的普通写不能被重排到 volatile 写之后volatile 读之后的操作也不能被重排到 volatile 读之前。这种限制在许多并发设计里非常关键比如双重检查锁单例模式。4.3 不保证原子性volatile 最常被误解的一点就是以为它能保证原子性。事实是volatile 对复合操作无能为力。i、i--、check-then-act 这类“读、改、写”的组合操作即便变量被 volatile 修饰也不会因为可见性而变得线程安全。我们会在后文用计数器的例子直观展示这一点。简单说如果你需要的只是“一个线程写、多个线程读”volatile 通常够了如果你需要“多个线程同时改”volatile 单独使用远远不够还得借助锁或者原子类。5. 深入理解可见性volatile 的读写语义光说“保证可见性”还不够我们来看看 volatile 在读写时到底发生了什么。5.1 volatile 写立刻刷新到主内存当一个线程对一个 volatile 变量执行写操作时JMM 会把这个线程工作内存中对应的值立即刷新到主内存。这就像我们把草稿纸上的数字第一时间抄回白板不让它继续藏在草稿纸上。更重要的是volatile 写还会把该线程在此之前对其他普通变量的修改一并刷新到主内存。换句话说volatile 写不仅保证自己可见还会“顺带”保证写之前的所有修改可见。这个特性在实现“状态发布”时非常有用。5.2 volatile 读强制从主内存读当一个线程读取 volatile 变量时JMM 会把这个线程工作内存中对应的副本置为无效强制线程重新从主内存中读取。也就是说线程不会使用自己草稿纸上的旧数据而是去共享白板上看最新结果。同样地volatile 读之后这个线程对其他普通变量的后续读取也都能够看到最新值。volatile 读相当于一个“刷新点”把线程的工作内存和主内存重新对齐。5.3 volatile 写读之间的 happens-before 关系假设线程 A 先写 volatile 变量 v然后线程 B 再读 v。根据 volatile 变量规则线程 A 对 v 的写 happens-before 线程 B 对 v 的读。再结合传递性线程 A 在写 v 之前进行的所有修改对线程 B 在读 v 之后的所有操作都是可见的。这个特性可以表达成一句非常实用的话volatile 变量的写读可以充当线程之间发布共享状态的“桥梁”。只要 B 读到了 A 写的 volatile 值B 就能看到 A 在写这个值之前已经完成的所有准备工作。6. 深入理解有序性volatile 与内存屏障指令重排序是 CPU 和编译器提高性能的重要手段但也是并发编程的隐形杀手。volatile 通过内存屏障来约束重排序。要理解 volatile 的有序性保证最好先看看 Java 编译器在遇到 volatile 读写时会插入什么样的屏障。6.1 什么是内存屏障内存屏障也常被翻译为内存栅栏是一种 CPU 指令。它的作用是保证屏障前后的指令不会跨过屏障乱序执行同时确保某些内存操作对其他 CPU 可见。可以把内存屏障想象成地铁站里的闸机。闸机可以规定某些人不能越过某条线或者必须按顺序通过。内存屏障就是 CPU 指令流里的“闸机”它限制指令重排的范围并确保内存写入的可见顺序。6.2 常见的四类屏障在 JMM 的抽象层面内存屏障大致分为四类LoadLoad 屏障屏障前的读操作完成之后才执行屏障后的读操作。StoreStore 屏障屏障前的写操作完成之后才执行屏障后的写操作。LoadStore 屏障屏障前的读操作完成之后才执行屏障后的写操作。StoreLoad 屏障屏障前的写操作完成之后才执行屏障后的读操作。其中 StoreLoad 屏障是成本最高的一种因为它需要保证写操作完成以后后续的读操作才能开始。volatile 的写通常会伴随 StoreLoad 屏障这也是 volatile 写操作相对开销较大的原因之一。6.3 volatile 写前后的屏障规则当编译器遇到 volatile 写时会在它的前后做文章。简单理解volatile 写之前会插入 StoreStore 屏障确保在 volatile 写之前的所有普通写都已经刷新到主内存不会跑到 volatile 写之后。volatile 写之后会插入 StoreLoad 屏障确保这个写完成之后后续对其他变量的读操作不会被提前到写之前。这样做的效果是在 volatile 写之前的普通操作不会因为重排序而发生在 volatile 写之后。6.4 volatile 读前后的屏障规则当编译器遇到 volatile 读时会在它的两侧插入 LoadLoad 和 LoadStore 屏障。屏障前的读操作先执行屏障后的读写操作后执行。这样可以保证 volatile 读之后的普通操作不会被编译器或 CPU 提前到 volatile 读之前执行。以上规则共同构成了 volatile 的有序性保证。它们是理解双重检查锁单例为什么需要 volatile 的重要基础。7. volatile 为什么不保证原子性用计数器实验证明前面反复说 volatile 不保证原子性现在我们用一段实验代码把这一点坐实。假设我们有一个计数器 count声明为 volatile然后启动 10 个线程每个线程对 count 自增 1000 次理论上最终结果应该是 10000。public class VolatileCounter { private static volatile int count 0; public static void main(String[] args) throws InterruptedException { Thread[] threads new Thread[10]; for (int i 0; i threads.length; i) { threads[i] new Thread(() - { for (int j 0; j 1000; j) { count; } }); threads[i].start(); } for (Thread thread : threads) { thread.join(); } System.out.println(最终 count count); } }如果你多次运行这段代码大概率会发现最终结果小于 10000比如 9847、9912每次结果都不一样。这说明虽然 count 是 volatile 的但 count 这个操作仍然不是线程安全的。原因在于 count 不是一个原子操作。它分为“读取当前值、计算新值、写回新值”三个步骤。线程 A 和线程 B 可能同时读取到相同的旧值然后各自写回相同的新值导致一次自增被覆盖。volatile 只能保证每次读写拿到的都是主内存的最新值却无法阻止两个线程在“读取”和“写回”之间发生交错。要解决这个问题有三种常见方案使用 synchronized 或 Lock把自增操作变成临界区。使用 AtomicInteger 等原子类通过 CAS 保证自增的原子性。如果业务允许也可以使用 LongAdder在高并发计数场景下性能更好。这些方案并不是 volatile 的替代品而是和 volatile 互补。记住这样一句话就比较稳妥volatile 负责可见和有序锁和原子类负责原子。8. volatile 与 synchronized 的区别volatile 和 synchronized 经常被放在一起比较。两者都能在一定程度上解决并发问题但机制和适用场景差异很大。搞懂它们的区别才能在不同场景下做出正确选择。8.1 底层机制不同内存可见性 vs 互斥加锁volatile 本质上是 Java 内存模型提供的一种可见性保证机制。它通过在读写操作前后插入内存屏障保证变量最新值及时回到主内存并限制相关指令重排序。volatile 并不会阻塞线程也不会让线程进入阻塞队列。synchronized 则是基于对象监视器实现的互斥锁。线程进入同步块时需要获取锁获取不到就阻塞等待退出同步块时释放锁。锁不仅能保证临界区内共享变量的可见性和有序性还能保证互斥访问从而保证原子性。可以把 volatile 理解为“给变量加了一个可见性标签”而 synchronized 是“给一段代码加了一把锁”。一个解决的是数据是否最新另一个解决的是操作是否互斥。8.2 原子性不同volatile 无原子性synchronized 有原子性volatile 修饰的变量在执行 i、i--、check-then-act 这类复合操作时仍然不是线程安全的。synchronized 则不同只要把复合操作放在同一个同步块内就能保证这些操作作为一个整体被串行执行不会出现中间状态被其他线程看到。所以当你只需要保证一个变量的可见性时使用 volatile 更轻量当你需要保证一组操作的原子性时应该使用 synchronized 或 java.util.concurrent 包下的 lock 和原子类。8.3 性能与开销不同volatile 更轻但不是银弹volatile 的开销主要来自内存屏障尤其是 StoreLoad 屏障成本较高。但整体而言volatile 不会引起线程上下文切换和锁竞争在“一写多读”场景下通常比 synchronized 更轻。不过这不意味着 volatile 永远比 synchronized 快。现代 JVM 对 synchronized 做了大量优化比如偏向锁、轻量级锁和锁粗化在竞争不激烈的情况下synchronized 的性能也非常可观。选型时应该先看语义是否满足再看性能差异。8.4 一张表看懂核心区别对比维度volatilesynchronized保证可见性是是保证原子性否是禁止重排序部分禁止同步块内保证有序阻塞线程不会锁竞争时会阻塞适用场景状态标志、安全发布复合操作、临界区这张表适合作为面试速记但真正的判断标准始终是你的业务逻辑到底需要“可见”还是需要“互斥”。9. volatile 的典型使用场景volatile 不是万能的但它在几个典型场景下非常合适。判断标准可以浓缩成一句话如果一个变量是“一个线程写、多个线程读”并且每次写都不依赖当前值那么 volatile 通常是合适的候选方案。9.1 状态标志位这是 volatile 最经典、最不容易用错的场景。用一个 volatile boolean 表示某个任务的停止标志工作线程不断读取这个标志控制是否继续运行。我们开篇的 StopFlagDemo 就是这种用法。private static volatile boolean running true; public static void stop() { running false; } public static void main(String[] args) { new Thread(() - { while (running) { // 执行任务 } System.out.println(任务线程已停止); }).start(); }这里 running 只有一个线程写、多个线程读写操作不依赖当前值所以 volatile 完全够用而且比加锁更简单。9.2 一次性安全发布对象有些对象在初始化完成后就不会再修改其引用例如配置对象、缓存初始化对象。此时可以使用 volatile 保证对象引用的可见性避免其他线程读到未初始化完成的对象。public class ConfigHolder { private volatile Config config; public Config getConfig() { Config result config; if (result null) { result loadConfig(); config result; } return result; } private Config loadConfig() { return new Config(); } }需要提醒的是这个简单写法只是为了保证引用可见并不能保证线程安全地只加载一次。如果要求严格单次初始化应该结合双重检查锁、静态内部类或枚举实现。9.3 独立状态变量当多个状态字段相互独立、各自只有一个写线程时可以把它们都声明为 volatile借用 happen-before 关系发布最新状态。例如一个简单的统计状态public class SystemStatus { private volatile boolean healthy true; private volatile long version 0; public void markUnhealthy() { healthy false; } public void markHealthy() { healthy true; } public void upgrade() { version; } public boolean isHealthy() { return healthy; } public long getVersion() { return version; } }每个变量都有自己的写线程或简单的写语义互相之间没有复合依赖volatile 就能很好地承载这种“读多写少”的状态发布需求。9.4 双重检查锁单例中的关键一环双重检查锁单例是 volatile 最著名的应用之一也是很多面试官喜欢追问的场景。下一章我们专门展开。10. 经典案例双重检查锁单例模式单例模式看似简单但在多线程环境下要实现“懒加载 高性能 线程安全”并不容易。双重检查锁即 double-checked locking就是在尽量减小加锁范围的前提下实现线程安全的懒汉单例。10.1 如果不加 volatile 会怎样先看一个容易出问题的版本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; } }表面上看这个代码做了两次 null 判断避免了每次获取实例都加锁。但问题出在 instance new Singleton() 这一行。它并不是一个原子操作在 JVM 层面至少可以拆成三步给对象分配内存、执行构造方法初始化对象、把内存地址赋给 instance 引用。为了提高性能编译器或 CPU 可能把后两步重排序先把内存地址赋给 instance再执行构造初始化。如果另一个线程在外面第一次检查 instance 时看到非 null就会直接返回一个还没有初始化完成的对象导致拿到一个“残缺”的单例。更糟的是这种 bug 非常隐蔽可能在高并发或不同平台下才偶现。10.2 加 volatile 后为什么安全把 instance 声明为 volatile 后volatile 会禁止把对象构造和引用赋值之间的关键步骤重排序从而保证 instance 引用被赋到变量上时对象已经完成初始化。修正后的代码如下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; } }这里的 volatile 不是为了解决可见性因为 synchronized 已经能处理可见性问题而是为了禁止指令重排序。正因为 volatile 写之前的所有普通写不能被重排到 volatile 写之后对象内部的初始化操作才能保证发生在 instance 引用被发布之前。如果你不想使用 volatile也可以选择静态内部类方式利用 JVM 的类初始化机制天然保证线程安全public class Singleton { private Singleton() { } private static class Holder { private static final Singleton INSTANCE new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }两种写法各有优劣。双重检查锁加 volatile 能实现懒加载静态内部类写法更简洁且同样懒加载读者可以根据团队习惯选择。11. volatile 的常见误区volatile 被误解的频率很高。下面梳理几个最常见的误区帮助你避开那些隐蔽的坑。11.1 误区一volatile 保证原子性这是最经典的误解。volatile 只能保证单个读或单个写的可见性不能让 i、i-- 这类复合操作变成原子操作。只要操作存在“读旧值、计算新值、写回新值”的序列就可能出现更新丢失。11.2 误区二volatile 能替代所有锁volatile 只是轻量级同步工具不具备互斥能力。凡是要保证多个操作串行执行、参与条件判断、修改一组关联状态的场景仍然需要 synchronized 或显式锁。把 synchronized 全部换成 volatile很可能把程序从“性能问题”变成“正确性问题”。11.3 误区三加上 volatile 就一定能立刻看到最新值volatile 保证的是当某个线程写入新值后后续读取该 volatile 变量的线程能看到这个最新值。它并不代表“所有线程在所有时刻看到的都是同一个值”。并发写、读取时序交错时不同线程仍然可能先后看到不同状态。理解 happen-before 关系比简单背诵“立刻可见”更准确。11.4 误区四volatile 引用能保证引用对象的内部字段可见如果声明了一个 volatile 的对象引用保证的只是这个引用的可见性而不是对象内部字段的可见性。例如 volatile 修饰一个数组引用数组元素的修改并不受 volatile 保护volatile 修饰一个对象对象内部 int 字段也不自动具备 volatile 语义。如果既要发布引用、又要保护内部状态通常需要更完整的同步策略。12. 总结把 volatile 用得又稳又准到这里我们已经从底层机制到实战场景完整梳理了 volatile。最后再把核心结论串起来。12.1 三句话记住 volatilevolatile 保证可见性写后刷新主内存读时强制重新读取。volatile 禁止部分重排序通过内存屏障约束关键读写顺序。volatile 不保证原子性不能用于 i 等复合操作。12.2 什么时候用 volatile状态标志位一个线程写多个线程读。一次性发布对象引用例如双重检查锁中的 instance。读取频繁、写入简单且不依赖旧值的变量。12.3 什么时候不要用 volatile需要复合操作的原子性时。需要多个线程同时修改变量时。对象内部状态也需要可见性保障时。不确定用不用的时候优先选择更稳的 synchronized 或并发工具。12.4 后续学习建议建议依次深入三个方向一是系统学习 Java 内存模型和 happens-before 规则二是阅读 AtomicInteger、LongAdder 等原子类的底层 CAS 实现三是结合 ConcurrentHashMap 的源码观察 volatile 和锁在实际工程中如何协同工作。理解这些之后你不仅能回答 volatile 相关面试题更能在真实并发场景里做出可靠的技术选型。