这期是“多线程拾遗”系列的第九篇，聊的是 Java 并发里那个最轻量、也最容易被用错的同步关键字：volatile。先纠正一个细节，系列标题里的 Volitate 是我手滑拼错了，正确拼写是 volatile。这个单词看起来平平无奇，但在并发编程里出现频率极高，拼错率也极高，代码评审里我见过不止一次因为拼写错误导致资料搜不到的情况。回到正题，volatile 解决的问题非常聚焦：一个线程对共享变量的修改，到底什么时候能被另一个线程看见。我问过不少人 volatile 有什么用，答案多半是“防止脏数据”“加了它就不用 synchronized”，这两种说法都沾边，但离真正会用还差一层。这篇文章我会把 volatile 的语义边界、JMM 层面的原理、与锁的选型对比、经典的单例双重检查锁案例，以及我在生产环境里踩过的坑一起聊透。已经会写 Thread 和 synchronized、想补上并发这块知识拼图的同学，这期很适合你；就算暂时用不上，把底层逻辑理顺了，看别人的并发代码也会顺眼很多。
1. 先把语义边界盘明白：可见性、有序性、非原子性
1.1 可见性：不加 volatile，另一个线程可能永远看不见
先看一个最直观的实验。定义一个静态的 boolean 变量 running，主线程在 sleep 一秒后把它改成 false，子线程在循环里不停检查这个变量。直觉上，子线程应该在一秒后退出循环，但如果你把变量前的 volatile 去掉再跑，程序经常会一直卡在循环里，控制台什么都没有。
public class FlagDemo { private static volatile boolean running = true; public static void main(String[] args) throws InterruptedException { Thread t = new Thread(() -> { long count = 0; while (running) { count++; } System.out.println("loop exit, count=" + count); }); t.start(); Thread.sleep(1000); running = false; t.join(); } }为什么没有 volatile 会这样？因为每个线程在 CPU 寄存器或本地缓存里持有变量的副本，它不会每一次都去主内存重新读取。你主线程改了值，子线程手里的“旧照片”还没换掉，于是它永远活在旧的认知里。Java 内存模型（JMM）把这种机制抽象成工作内存和主内存：线程操作变量，本质上是先把主内存的值读到自己的工作内存，修改之后再写回。问题在于写回的时机不受控制，其他线程读到的可能始终是旧值。volatile 的作用就是打断这种随意性——读 volatile 变量时，线程必须从主内存重新取；写 volatile 变量时，必须立刻同步回主内存。这种“见者有份”的效果保证了你写的值，其他线程在下一次读取时一定能看到。这是 volatile 第一个核心能力：可见性。
1.2 禁止重排：volatile 是一道栅栏，不是焊死整条流水线
volatile 的第二层语义是禁止指令重排。CPU 和 JIT 编译器为了提高执行效率，会在不改变单线程语义的前提下调整指令的执行顺序。单线程里这种优化是好事，但在多线程环境下，重排可能会带来灾难性的结果。举个我实际见过的场景：一个线程负责加载配置，加载完成后把 ready 标志置为 true，另一个线程检查到 ready 后再去读取配置。如果编译器把“写配置内容”和“写 ready 标志”这两行的顺序调换，另一个线程可能在配置还没写完时就看到了 ready=true，然后读到一半的配置数据。
volatile 的规则很明确：在 volatile 写操作之前的普通读写，不允许被排到写操作之后；在 volatile 读操作之后的普通读写，不允许被排到读操作之前。标记了 volatile 的变量相当于一道栅栏，栅栏两侧的顺序被固定住。这里要强调，“禁止重排”不是把所有指令都焊死，而是划定边界，边界内的优化空间依然保留。这也是为什么 volatile 的性能代价比加锁小得多，它只约束必要的顺序，不把整段逻辑都锁死。
1.3 volatile 不保证原子性，这一点必须刻在脑子里
这一节是重点，也是最多人翻车的地方。volatile 不保证原子性。最经典的反例是 count++。你把它拆开看，底层至少有读 count、加一、写回三步。volatile 能保证每次读写都从主内存走，但两个线程同一时刻都读到了值 0，各自加 1 再写回，最终结果还是 1，而不是 2。这三步操作之间没有锁保护，属于典型的竞态条件。
private static volatile int counter = 0; // 多个线程同时执行 counter++，最终结果大概率小于线程数所以，只要你看到“用 volatile 实现计数器”之类的代码，基本可以断定作者没想清楚。volatile 适合解决“一个线程写、多个线程读”的场景，适合做状态切换标志，但绝不适用于依赖读-改-写复合操作的场景。对这类操作，老老实实上 synchronized，或者用 AtomicInteger 这类基于 CAS 的原子类。判断方法很简单：凡是能把一个操作拆成两个以上底层步骤的，volatile 都管不住。
2. 从 Java 内存模型看 volatile 为什么能生效
2.1 工作内存与主内存的抽象
Java 内存模型是理解并发规范的地基。JMM 规定每个线程有自己的工作内存，保存变量的副本；主内存是所有线程共享的区域。线程之间的通信，必须通过主内存这个中转站。这很像一个团队共用一个公告栏，但每个人手上都有一份复印稿，你更新公告栏容易，难的是让大家手里的复印稿也同步更新。
volatile 的读写规则就建立在 JMM 上：volatile 变量在读的时候，强制走主内存；写的时候，强制刷主内存。从外部看，它就像对 volatile 变量绕过了“工作内存”这一层。这也是为什么 volatile 变量能提供跨线程的可见性保证——它直接操作的是大家都能看到的那个源头，而不是本地副本。
2.2 happens-before 规则里的关键一条
JMM 定义了一套 happens-before 原则，用来判断两个操作是否存在先后关系。其中有一条专门针对 volatile：对一个 volatile 变量的写，happens-before 于后续对同一个变量的读。这句话翻译成大白话就是：写 volatile 的线程在写之前做的所有操作，对之后读到该 volatile 变量的线程来说，都是可见的。
这条规则的价值非常大。它意味着 volatile 不只是让单个变量本身可见，还能起到“传递可见性”的作用。比如线程 A 先给普通变量 x 赋值 100，再写 volatile 变量 flag 为 true；线程 B 读到 flag 为 true 之后，去读 x，那么它一定读得到 100。这就是所谓的内存可见性传递，也是很多并发框架里用 volatile 做“发布”操作的理论依据。理解这一点后，你会发现 volatile 的能力边界比直觉上要大一圈——它不只是管自己，还能顺带管住它前面的那些操作。
2.3 内存屏障与 CPU 落地
在硬件和编译器层面，volatile 的读写会插入内存屏障指令。常用四种屏障：LoadLoad、LoadStore、StoreStore、StoreLoad。写 volatile 变量时插入 StoreStore 和 StoreLoad，读 volatile 变量时插入 LoadLoad 和 LoadStore。对大多数人来说，不需要把屏障的细节死记硬背，但需要理解它背后的直觉：屏障是一种处理器指令，它告诉 CPU 和编译器，屏障前后的内存操作不能越过这条线。顺序性和可见性最终就是靠这些硬件指令落地的。
实际运行时，JIT 会根据目标 CPU 平台做精简。比如 x86 架构本身就带较强的存储一致性，实际插入的屏障数量比理论上少。这就引出一个经验之谈：同样的 volatile 代码，在不同架构下表现有细微差异，本地单核机器上跑一切正常，并不代表部署到多核服务器上依然正常。并发问题的复现难度常常就在这里。
3. volatile 与 synchronized 的选型对比
3.1 语义差异：一个是通知，一个是排他
把 volatile 当成 synchronized 的轻量版，是一个流传很广、也很误导的说法。synchronized 同时提供互斥、可见性和有序性；volatile 只提供可见性和有序性，不提供互斥。synchronized 是锁，靠排他控制保证同一时刻只有一个线程进入临界区；volatile 是“无锁”的变更通知，它管不了谁在写、写了几次。
用 volatile 有一个铁律：至多只有一个线程会写这个变量，其他线程只是读。一旦有多个线程同时写同一个 volatile 变量，即使不涉及复合操作，也可能出现覆盖问题——因为两个线程的写入顺序无法保证，后写的不一定是最新的业务状态。如果你不确定自己的场景是否符合“单写多读”，那就别用 volatile，直接上锁。这个判断上，保守一点远比炫技来得稳。
3.2 性能代价与常见误判
锁的代价主要在线程阻塞和唤醒，涉及操作系统级的上下文切换；volatile 的代价主要是内存屏障导致的流水线约束和缓存失效。高并发场景下两者的差距可以拉得很大，但这也是最容易产生误判的地方。我见过不少项目为了“性能”用 volatile 小心翼翼地替代锁，结果逻辑复杂、难以验证，最后反而引入间歇性 bug。性能优化的第一原则是先测量，不要凭感觉做决定。如果你的场景确实需要多个线程写共享状态，先从设计上改为“单写多读”，或者引入并发容器，往往比纠结用 volatile 还是 synchronized 更有效。
3.3 一张可以直接对照的选型清单
把前面这些内容整理成一张判断清单，写代码前对着过一遍：
- 场景是“单线程写、多线程读状态标志”→ 可以用 volatile 做可见性控制，典型如开关标志、生命周期状态
- 场景是“多个线程都要改同一个值”→ synchronized 或原子变量，volatile 不够用
- 场景是“需要保证读-改-写整体不被穿插”→ 必须上锁，或者用 Atomic 包装的 CAS 操作
- 场景是“既要可见性，又要保证一组操作的执行顺序”→ 锁是唯一稳的选择
这张清单是我在实际开发里踩过坑之后总结出来的，照着选通常不会出大问题。
4. 经典实战拆解：双重检查锁为什么要配 volatile
4.1 经典的坏实现长什么样
单例模式的懒加载写法，无数教程展示过所谓的“双重检查锁”优化：先判断实例是否为空，为空再加锁，锁内再判断一次。这样做既能避免每次调用都加锁的性能损耗，又能在并发下保证只创建一个实例。逻辑看起来天衣无缝，但历史上这个写法在 Java 5 之前是无效的，原因就出在对象创建的指令重排上。
public class Singleton { private static Singleton instance; // 这里漏了 volatile private Singleton() {} public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } }很多老代码里那行 static 变量前没有 volatile，埋下了偶发空指针的种子。这种 bug 最让人头疼的地方在于：低并发时可能完全复现不出来，一到高并发峰值就随机触发一次，没有任何规律可循。
4.2 new 一个对象背后的重排陷阱
new Singleton() 在字节码层面不是一步完成的。至少经历这几个阶段：分配内存空间、初始化对象字段、执行构造函数、把引用赋值给变量。在单线程里，这些步骤的顺序怎么变都不影响最终结果。但在多线程环境下，JIT 和 CPU 完全有可能把“赋值引用”这一步提前到“构造完成”之前。
另一个线程正好在这个时候执行判空逻辑，发现 instance 不为 null，直接拿去用。此时它拿到的是一个内存空间已经分配、但字段还没有完成初始化的“半成品”对象。一旦访问内部字段，就有概率读到默认值，甚至抛出空指针。volatile 在这里起的就是禁止重排的作用：它把“引用赋值”和“对象构造完成”的先后关系固定住，让其他线程要么看到完全构造好的对象，要么看到 null，永远不可能是中间状态。
4.3 修正后的 DCL 与替代方案
正确的写法很简单，就是给 instance 加上 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; } }这里 volatile 解决可见性和重排序问题，synchronized 解决实例只被创建一次的互斥问题，两者各司其职，缺一不可。如果想彻底绕开这套心智负担，还可以用静态内部类的方式，利用类加载器的线程安全机制来保证单例：
public class Singleton { private Singleton() {} private static class Holder { static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }但理解 DCL 的坑仍然有实际价值，因为同样的指令重排问题在别的场景里一样会出现。原理通了，换任何代码都能一眼看出有没有类似隐患。
5. 高频踩坑与排查实录
5.1 volatile 计数器：读改写三步必挂
这是使用频率最高的错误。很多同学写了 volatile 修饰的 int counter，然后在高并发下执行 counter++，发现结果不对，百思不得其解。原因前面已经说过：counter++ 不是单一内存操作，而是读、加、写三步，volatile 不提供原子性。怎么修？如果只是计数，用 AtomicInteger 的 incrementAndGet；如果计数过程中还需要做一致性判断，用 synchronized 保护整个操作块。
我还在一些代码里见过更隐蔽的版本：用 volatile 修饰 long 类型，直接把 64 位变量当成计数器用。这同样不行，因为即使在 64 位 JVM 上，long 的读写也不保证原子性，volatile 只保证可见性，不保证“读这个 long 的过程不会被另一个写操作打断”。
5.2 volatile 修饰引用与对象内部字段的混淆
另一个高频误区是把 volatile 当成对象内部字段的保护伞。volatile 修饰的是变量本身，不是变量指向的那个对象。举个例子，volatile List list 保证的是 list 这个引用变量的可见性和禁止重排，但 list 对象内部的元素变更，不会自动获得同样的保证。你在这个线程往 list 里 add，另一个线程读 list，不加额外同步依然可能看不到新元素。
共享可变集合的正确做法是用 CopyOnWriteArrayList、ConcurrentHashMap 这类并发容器，或者对操作加锁，而不是靠集合引用上的 volatile 自欺欺人。同理，volatile 修饰数组，保证的是数组引用的可见性，不是数组元素的可见性。这两个点一定要分清楚。
5.3 线上可见性问题的定位思路
线上遇到“共享变量改了，另一个线程就是看不到更新”的问题，我的排查顺序是这样的。第一，确认变量是否真的加了 volatile，注意有没有被代理对象或包装对象遮住。第二，看是不是存在多个 JVM 实例，volatile 只能解决进程内的可见性，跨进程无能为力。第三，确认是不是多核服务器上缓存一致性导致的偶发问题。第四，检查读写路径是不是对称的——一个线程只写了不读，另一个只读了不写，中间没有任何同步点。
调试这类问题有个常见误区：用 Thread.sleep 去“等等再看”，这是自欺欺人。可见性问题是机制层面的，等再久也没用。要验证修复是否有效，靠的是并发压测，故意放大线程数和循环次数。用 jstack 看线程状态也有帮助，但可见性问题往往发生在数据层面，线程状态很难直接暴露，真正靠谱的还是代码审查和针对性的压力测试。
6. 评审时反复强调的几个实操心得
最后聊几个我在实际代码评审里反复强调的东西。第一，volatile 不是银弹，它的适用面其实很窄。如果你发现自己在代码里频繁加 volatile，很可能是设计出了问题，说明共享状态被过度暴露了，正确的方向是收敛可变状态，而不是堆同步关键字。
第二，volatile 的最佳使用场景是“状态发布”：一个变量从无到有、从旧到新的切换过程，多线程之间只需要感知到变化即可。比如分布式配置中心里的本地开关、生命周期状态机、连接池的初始化完成标志。这类场景用 volatile 又简洁又高效。
第三，遇到并发 bug 时，第一反应不要是“再加个 volatile 试试”，而是先梳理共享数据的写入者是谁、读取者是谁、以什么顺序操作。把数据流和时序画清楚，绝大多数并发问题在纸上就能想明白，根本不需要碰运气式的修补。我自己的习惯是，任何并发问题都先写一小段最小复现代码，跑不跑得出现象反而次要，重点是在写的过程里被迫把逻辑理清楚。这招帮我解决过好几个看起来很玄的线上偶发问题，希望你也能用上。
