volatile、synchronized与Atomic深度对比：并发编程选型指南

1. 一次线上事故让我重新审视 volatile

先讲个真实经历。去年我维护的一个库存服务，在某次大促前压测时出现了超卖。代码逻辑并不复杂，一个 volatile boolean 作为活动开关，判断活动是否开启，开启后才允许扣减库存。压测脚本一跑，TPS 上来之后，超卖数据就出现了。当时第一反应是 Redis 扣减逻辑出了问题，排查了大半天，最后定位到问题竟然出在这个我深信不疑的 volatile 上。

为什么说“深信不疑”？因为网上太多文章告诉我们：volatile 保证可见性，保证线程间变量的修改能被其他线程立即看到。我当时的理解是：既然活动开关能被立即看到，那库存数量的变化也应该是安全的。这个错误认知导致我浪费了一整天。也正是这次事故，让我下定决心把 volatile、synchronized、Atomic 这三者之间的边界彻底搞清楚。

经过这两年不断的踩坑和实践，我越来越觉得：很多并发 bug 的根本原因，不是开发者不知道某个关键字，而是不知道这三个工具的能力边界在哪里。选对了工具，代码简洁高效；选错了工具，轻则性能损耗，重则线上事故。这篇文章我就把自己对这三者的理解做一个系统性梳理，重点讲清楚它们的核心差异、底层原理、选型依据，以及我在实际项目中总结的避坑经验。

2. 先搞清楚 volatile 到底解决了什么问题

2.1 从 JMM 说起：为什么会出现“看不见”的变量

要理解 volatile，必须先理解 Java 内存模型（Java Memory Model，JMM）。JMM 规定所有变量存储在主内存中，每个线程有自己的工作内存（可以类比为 CPU 缓存）。线程对变量的所有操作，都必须在工作内存中进行，不能直接读写主内存。不同线程之间无法直接访问对方的工作内存，线程间变量值的传递需要通过主内存来完成。

用个生活化的类比：主内存是公司公告栏，每个线程是独立办公室的员工。员工看公告栏上的信息，不会每次都跑过去看，而是把内容抄一份贴在自己办公桌上。当员工修改了某个数据，先改自己桌上的版本，什么时候同步回公告栏，什么时候再去公告栏刷新，JMM 只给了一个“尽最大努力”的保证，并没有强制实时同步。

这就带来两个经典问题：

• 可见性问题：线程 A 修改了变量，线程 B 可能还在读自己工作内存里的旧值，读不到 A 的修改。
• 重排序问题：编译器和 CPU 为了优化执行效率，可能对指令进行重排。在单线程环境下，重排序不影响最终结果，但在多线程环境下，重排序可能导致其他线程看到不符合预期的执行顺序。

volatile 就是针对这两个问题给出的解决方案。当一个变量被声明为 volatile 后，JMM 会为其建立两条内存屏障规则：写操作时，会强制将工作内存中的最新值刷新到主内存；读操作时，会强制从主内存中重新加载值到工作内存。同时，volatile 的读写操作会插入内存屏障，禁止编译器重排序和处理器重排序。

2.2 volatile 的两个铁律，很多人只知道一半

我在面试候选人和给团队做培训时，发现一个普遍现象：绝大多数人都知道 volatile 能保证可见性，但说不清它不能做什么。这里必须把 volatile 的两个能力和一个边界说透：

能力一：保证可见性。 一个线程修改了 volatile 变量，其他线程能立刻看到这个修改。这是 volatile 最核心的价值。

能力二：禁止指令重排序。 volatile 读写操作前后会插入内存屏障，禁止指令重排序。这个特性在单例模式的双重检查锁（DCL）中发挥了关键作用，后面会有详细案例。

边界：不保证原子性。 这句话很多人背得滚瓜烂熟，但真正理解的人不多。所谓原子性，是指一个操作是不可中断的，要么全部执行成功，要么全部不执行。volatile 只保证了“读到的值是最新的”，但无法保证“读到-修改-写回”这个过程不被其他线程打断。

我画个简单的场景来说明这个边界：

code复制线程 A：读 count（值为 1） → 执行 count+1 → 写回 count（值为 2）
线程 B：读 count（值为 1） → 执行 count+1 → 写回 count（值为 2）

如果 count 被声明为 volatile，线程 A 和线程 B 同时执行 count++，最终结果可能是 2，而不是我们期望的 3。因为“count++”本质上是三条指令：读取、加一、写回。volatile 保证的是每次读取都能拿到最新的值，但无法保证两个线程不会同时拿到相同的值。

2.3 volatile 的典型适用场景：状态标志位和开关

那么 volatile 到底适合做什么？我在实际项目中最常用到 volatile 的场景有两类：

场景一：状态标志位。 最典型的就是布尔类型的开关变量。比如系统是否允许写入、任务是否需要停止。这类场景的特点是：只有一个线程负责修改这个变量，其他线程只负责读取。

java复制public class TaskManager {
    private volatile boolean running = true;
    
    public void stop() {
        running = false;  // 由控制线程调用
    }
    
    public void run() {
        while (running) {
            // 执行任务
        }
    }
}

这个例子中，控制线程调用 stop() 方法修改 running 的值，worker 线程在 run() 方法中不断读取 running。没有 volatile 的话，worker 线程可能一直读到自己工作内存中的旧值，导致任务无法停止。

场景二：双重检查锁（DCL）中的实例字段。

java复制public class Singleton {
    private static volatile Singleton instance;
    
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

这里 volatile 的作用是防止指令重排序。new Singleton() 这个操作不是原子的，它包含三步：分配内存、初始化对象、将引用指向内存地址。如果没有 volatile，JVM 可能先将引用指向内存地址（此时对象还没初始化完成），另一个线程读到这个非 null 的引用后，直接返回，使用尚未初始化完成的对象，就会抛出异常。

提示：虽然 synchronized 也能保证可见性，但如果没有 volatile，DCL 单例仍然存在隐患。因为 synchronized 只能保证锁内代码的可见性，而第一次判空（instance == null）发生在锁外，无法被 synchronized 保护。

3. synchronized 的本事：它到底锁住了什么

3.1 synchronized 的核心能力是互斥和原子性

synchronized 是 Java 内置的同步机制，它的核心能力有两个：互斥执行和内存可见性。

互斥执行的意思是：当一个线程获取了某个对象的监视器锁（monitor），其他尝试获取同一把锁的线程必须阻塞等待，直到锁被释放。这种互斥性保证了被 synchronized 修饰的代码块在同一时刻只能被一个线程执行。由于代码块是串行执行的，也就不存在多个线程同时修改共享变量的情况，因此 synchronized 能够保证原子性。

内存可见性的意思是：线程释放锁时，会把工作内存中的修改强制刷新到主内存；线程获取锁时，会让工作内存中的值失效，从主内存重新加载。这就是所谓的 happens-before 规则中的监视器锁规则。

我曾经在一个项目里遇到过这样的代码：

java复制public class Counter {
    private int count = 0;
    
    public synchronized void increment() {
        count++;
    }
    
    public int getCount() {
        return count;
    }
}

这段代码是有问题的。increment() 是同步方法，保证了 count++ 的原子性。但 getCount() 不是同步方法，它读到的 count 可能不是最新值。因为读线程没有获取锁，没有触发工作内存失效和主内存刷新机制。

这个例子很好地说明了：synchronized 的可见性是通过锁的获取和释放实现的，不是自动附加在所有变量上的。 要么读和写都加锁，要么都不加锁，否则就会出问题。这是一个非常隐蔽的坑，也是我在 code review 中经常发现的错误。

3.2 synchronized 的锁升级过程：无锁→偏向锁→轻量级锁→重量级锁

说到这里，我想花点篇幅讲一下 synchronized 的底层实现。因为理解锁升级的过程，是理解“为什么 synchronized 在低竞争场景下没有那么慢”的关键。

很多人对 synchronized 的印象还停留在“重量级锁，性能差”的时代。实际上，从 JDK 1.6 开始，JVM 对 synchronized 做了大量优化，引入了锁升级机制。synchronized 的锁状态可以分为四个级别：

偏向锁的核心思想是：如果一个线程获得了锁，那么锁就进入偏向模式。当这个线程再次请求锁时，无需做任何同步操作，直接获取。这极大降低了同一个线程重复获取锁的代价。

轻量级锁的核心思想是：当第二个线程竞争锁时，偏向锁会升级为轻量级锁。这个线程会通过 CAS 尝试获取锁，如果获取失败，会进行自旋（循环尝试获取），而不是立即阻塞。自旋的好处是避免了线程阻塞和唤醒带来的上下文切换开销，坏处是自旋会占用 CPU 时间。

重量级锁是最后的手段：当自旋超过一定次数（默认 10 次）或自旋线程数超过 CPU 核数一半时，轻量级锁会升级为重量级锁。重量级锁通过操作系统的互斥量实现，线程获取不到锁时会进入阻塞状态，涉及用户态和内核态的切换，开销最大。

这就是为什么在高并发、高竞争的锁场景下，synchronized 的性能可能不如某些乐观锁方案。但在竞争不激烈的场景下，由于偏向锁和轻量级锁的存在，synchronized 的开销其实已经非常小了。

3.3 synchronized 的局限性

说完了 synchronized 的优点，必须说说它的局限性，这关系到选型：

• 无法中断等待锁的线程。 一个线程获取不到锁时，会一直阻塞等待，不能响应中断。
• 无法设置获取锁的超时时间。 如果某个线程长期持有锁不释放，其他线程只能无限期等待。
• 锁的释放只能发生在退出同步代码块或抛出异常时。 必须在正确的位置设置边界，否则可能提前释放或长期持有的问题。
• 性能受竞争程度影响显著。 高竞争场景下，线程的阻塞和唤醒会带来较大的上下文切换开销。

这些局限性，正是我们后面要讨论的 Atomic 类在某些场景下能取代 synchronized 的原因。

4. Atomic 类：乐观锁思路下的无锁并发

4.1 从 CAS 说起：Atomic 的底层基石

Atomic 类（如 AtomicInteger、AtomicLong、AtomicReference）的核心底层机制是 CAS（Compare And Swap）。CAS 的操作逻辑很简单：包含三个操作数——内存位置 V、预期原值 A 和新值 B。仅当 V 的值等于 A 时，CAS 才用 B 更新 V 的值，否则不执行任何操作。

CAS 是硬件级别的原子指令（例如 x86 架构中的 LOCK CMPXCHG），通过 CPU 指令保证了比较和交换操作的原子性。这意味着 CAS 本身不会被线程调度打断，天然具备原子性。

用生活化的类比来解释 CAS：想象你在自助储物柜前存东西。你先看了一眼柜门上的号码牌（预期值 A），然后你拿出手机拍照（这是可选的操作），准备把新号码牌贴上去（新值 B）。在贴上去之前，你会再确认一下柜门上的号码牌还是 A。如果是，就贴上 B；如果不 是，说明别人已经改过了，这次操作失败，需要重新读取新值再试。

JDK 中的 java.util.concurrent.atomic 包就是基于 CAS 实现的一系列原子操作类。它们包含了 AtomicInteger、AtomicLong、AtomicBoolean、AtomicReference、AtomicIntegerArray、AtomicReferenceFieldUpdater 等。这些类的共同特点是：通过 CAS 自旋实现线程安全的读改写操作，不需要加锁，因此被称为“无锁并发”或“非阻塞算法”。

4.2 AtomicInteger 的核心方法解析

拿最简单的 AtomicInteger 来拆解。它最主要的方法是 incrementAndGet()，对应 i++ 然后返回新值的操作。源码层面本质上是以下三步的循环：

1. 读取当前值（value）
2. 计算新值 = 当前值 + 1
3. 调用 compareAndSet(当前值, 新值)，如果成功则返回新值；如果失败（说明有其他线程抢先修改了值），回到第 1 步重新读取

这个“失败就重试”的策略就是 自旋。在多线程竞争不激烈的场景下，自旋通常很快就能成功；但在竞争非常激烈的场景下，线程会频繁地自旋重试，导致 CPU 占用率飙升。

再来看几个常用的方法：

java复制AtomicInteger count = new AtomicInteger(0);

// 先加后返回
int newValue = count.incrementAndGet();

// 先返回后加
int oldValue = count.getAndIncrement();

// 如果当前值为 5，则设置为 10
boolean success = count.compareAndSet(5, 10);

// 累加指定的值
int result = count.addAndGet(3);

还有一个容易被忽视但非常重要的一点：AtomicInteger 内部维护的 value 是被声明为 volatile 的。也就是说，Atomic 类是 volatile 的可变性 + CAS 的原子性 的组合体。CAS 保证了“读-改-写”的原子性，volatile 保证了变量的可见性。

4.3 Atomic 类的性能真相：无锁不代表无代价

我在一线写并发代码多年，最深的一个体会是：“无锁”这个词非常有误导性，它让人误以为 Atomic 类零成本、任意场景都快。实际上 Atomic 的性能高度依赖竞争程度。

在低竞争场景下，Atomic 的性能几乎总是优于 synchronized。这点好理解，没有线程阻塞唤醒，没有上下文切换。

但在高竞争场景下，Atomic 的性能可能并不比 synchronized 好。因为大量线程同时 CAS 失败，陷入长时间自旋，白白消耗 CPU 资源。此时 synchronized 已经升级到重量级锁，让获取不到锁的线程直接阻塞，释放 CPU 资源，反而表现更好。

从这个角度看，JDK 8 引入的 LongAdder 和 LongAccumulator 就很有价值了。LongAdder 的思想是把热点 value 拆分成一个 base 变量加一个 cell 数组，多个线程各自在不同的 cell 上累加，最后再汇总。这大大降低了竞争粒度，在高竞争场景下比 AtomicInteger 更高效。如果你需要高并发场景下的计数器和累加器，建议优先考虑 LongAdder 而不是 AtomicInteger。

5. 三者的底层逻辑差异：从总线锁到内存屏障

5.1 volatile 的关键字机制：内存屏障 + 禁止重排序

这一节我想把三个关键字的底层机制放在一起对比，因为只有理解了底层的指令执行逻辑，才能真正明白它们为什么有不同的能力和性能特征。

volatile 的实现依赖于两个底层机制：

第一是内存屏障（Memory Barrier）。 volatile 变量的读写操作会在指令序列中插入屏障指令，分为四种：

• LoadLoad 屏障：禁止上面的读操作和下面的读操作重排序
• StoreStore 屏障：禁止上面的写操作和下面的写操作重排序
• LoadStore 屏障：禁止上面的读操作和下面的写操作重排序
• StoreLoad 屏障：禁止上面的写操作和下面的读操作重排序

对于 volatile 写操作，JMM 要求在其前后分别插入 StoreStore 和 StoreLoad 屏障；对于 volatile 读操作，要求在其前后分别插入 LoadLoad 和 LoadStore 屏障。这些屏障保证了 volatile 操作不会被编译器和 CPU 随意重排。

第二是缓存一致性协议。 目前主流的 CPU 都实现了缓存一致性协议（如 x86 的 MESI 协议）。当 CPU 写入一个 volatile 变量时，会触发缓存行的状态变更，其他 CPU 核心如果缓存了同一地址的数据，会将自己的缓存行标记为失效。当它们再次读取这个变量时，发现缓存行失效，就会重新从主内存加载。

5.2 synchronized 的锁机制：Monitor 与操作系统的互斥量

synchronized 的底层实现是依赖于对象的 Monitor 锁。在 JVM 的 HotSpot 实现中，每个对象都有一个关联的 Monitor 对象（也称为管程或监视器锁）。

当一个线程要进入 synchronized 代码块时，它必须首先获取对象的 Monitor。Monitor 内部包含了持有者线程的引用、等待队列、条件变量等信息。如果 Monitor 已经被其他线程持有，当前线程就进入阻塞状态，加入等待队列。

JDK 6 之后的锁升级过程，我在前面已经详细介绍过。从底层指令的角度来看，synchronized 最终涉及 monitorenter 和 monitorexit 两条字节码指令。当升级到重量级锁时，这两条指令会调用操作系统提供的互斥量（mutex）和条件变量（condition variable）相关函数，从而引起用户态到内核态的切换。

5.3 Atomic 的 CAS 机制：CPU 级别的原子指令

Atomic 类的实现关键在于 Unsafe 类（或 JDK 9 之后的 VarHandle）提供的 compareAndSwapInt 等方法。这些方法最终映射到 CPU 的原子指令上。

以 x86 架构为例，CAS 对应的指令是 LOCK CMPXCHG。其中 CMPXCHG 是比较并交换指令，LOCK 前缀的作用是锁定总线或锁缓存行，确保在多核 CPU 环境下，比较和交换这两个操作是原子执行的。

三种方案底层实现对比表格：

5.4 一个容易被忽略的细节：指令重排的实际危害

前面提到的 volatile 禁止指令重排，很多人觉得这只是理论上的概念，实际开发中不太会遇到。这是一个很大的误区。我在实际项目中就遇到过一个因为重排序引发的诡异问题。

场景是这样的：我们在做一个异步消息处理系统，接收到消息后，先把消息内容写入本地队列，然后设置一个可见性标志位 ready = true。消费线程不断检查 ready 标志，如果为 true 就从队列里取消息处理。

最初没有声明 ready 为 volatile：

java复制public class MessageProcessor {
    private boolean ready = false;
    private Queue<String> messageQueue = new ConcurrentLinkedQueue<>();
    
    public void receive(String message) {
        messageQueue.offer(message);
        ready = true;  // 写入标志位
    }
    
    public void process() {
        while (!ready) {
            // 自旋等待
        }
        // 从队列取消息处理
        String message = messageQueue.poll();
        // ...
    }
}

这里有一个隐藏很深的 bug：由于编译器和 CPU 允许指令重排序，ready = true 这条语句可能被提前执行，在 messageQueue.offer(message) 执行之前就执行了。这样一来，消费线程看到 ready 为 true 后，就开始从队列中取消息，而此时队列中可能还没有消息（offer 还没执行），导致消息丢失。

加入 volatile 后，volatile boolean ready 会插入内存屏障，禁止 ready 的写操作与其前面的 offer 操作进行重排序，从而保证了消息一定先入队，再设置标志位。

注意：这个例子中的 messageQueue 使用了 ConcurrentLinkedQueue，它是线程安全的，保证了 offer 和 poll 操作的原子性。但如果换成普通 ArrayList，即使加了 volatile 也无法保证线程安全。这就引出了下一个问题：如何根据业务需求选择正确的并发工具。

6. 三个核心维度的代码级对比

6.1 可见性对比：一个反直觉的 while 循环

在谈原子性之前，我先把可见性问题用一段代码说透。很多人有一个误区：认为 synchronized 和 Atomic 天然就“覆盖”了 volatile 的功能，所以只要用了更重的工具，可见性就一定没问题。这个理解在大多数情况下是对的，但有例外。

先看 volatile 如何保证停止标志的可见性：

java复制public class VisibilityExample {
    private volatile boolean flag = true;
    
    public void shutdown() {
        flag = false;
    }
    
    public void doWork() {
        while (flag) {
            // 干活
        }
        System.out.println("线程停止");
    }
}

如果把这里的 volatile 去掉，这段代码在 Server 模式的 JVM 下很有可能永远无法退出循环。原因是 doWork() 方法中的 while 循环会频繁读取 flag，JIT 编译器可能将其优化成只读一次寄存器中的值，之后就不再从内存中重新读取。这个优化在单线程环境下是安全的，但在多线程环境下就成了 bug 的温床。

再来看如果用 synchronized 该如何实现同样的功能：

java复制public class VisibilityExample2 {
    private boolean flag = true;
    
    public synchronized void shutdown() {
        flag = false;
    }
    
    public synchronized boolean isFlag() {
        return flag;
    }
    
    public void doWork() {
        while (isFlag()) {
            // 干活
        }
    }
}

doWork() 中的 while 循环每次调用 isFlag() 都是同步方法，每次调用都会获取锁，锁的获取会触发工作内存失效和主内存刷新，所以线程能看到 flag 的最新值。

但这带来了一个关键问题：每个循环都要进行一次锁的获取和释放。 虽然偏向锁和轻量级锁能降低开销，但本质上还是比 volatile 的读操作要重。在循环次数达到百万级、千万级的场景下，二者的性能差距会被显著放大。

Atomic 方案同样可以实现标志位的功能，但显然有点“杀鸡用牛刀”了：

java复制public class VisibilityExample3 {
    private AtomicBoolean flag = new AtomicBoolean(true);
    
    public void shutdown() {
        flag.set(false);
    }
    
    public void doWork() {
        while (flag.get()) {
            // 干活
        }
    }
}

这个方案可以工作，AtomicBoolean.get() 方法内部读取的其实就是一个被 volatile 修饰的 value。但说实话，如果只是需要可见性，不需要原子性，直接用 volatile 更简洁直观，没必要引入 AtomicBoolean。

6.2 原子性对比：count++ 的三种写法，三种结局

可见性问题讲完了，现在来聊最核心的原子性问题。下面这个例子是并发编程中最经典的案例——计数器。同样实现一个多线程环境下的计数器，三种方案的表现截然不同。

方案一：volatile 实现（错误示范）

java复制public class VolatileCounter {
    private volatile int count = 0;
    
    public void increment() {
        count++;  // 非原子操作！
    }
    
    public int getCount() {
        return count;
    }
}

这个方案看着简单，但在多线程环境下结果是完全错误的。原因前面已经分析过：count++ 在底层是读、加、写三步操作，volatile 保证不了这三步的原子性。10 个线程各执行 1000 次 increment，最后 count 大概率不是 10000，而是小于 10000 的某个数。

方案二：synchronized 实现（正确但可能不是最优）

java复制public class SynchronizedCounter {
    private int count = 0;
    
    public synchronized void increment() {
        count++;
    }
    
    public synchronized int getCount() {
        return count;
    }
}

increment 和 getCount 都是同步方法，保证了对 count 的所有读写都是互斥的。10 个线程各执行 1000 次，结果是精确的 10000。

注意这里有一个细节：getCount() 也必须是 synchronized 的。如果 getCount() 不加锁，读操作可能读到旧值（工作内存中的数据未刷新）。读锁的开销虽然比写锁小，但如果读取频繁、竞争不激烈，这种读锁其实是可以通过别的方式来规避的，比如使用 AtomicInteger。

方案三：Atomic 实现（正确且高效）

java复制public class AtomicCounter {
    private AtomicInteger count = new AtomicInteger(0);
    
    public void increment() {
        count.incrementAndGet();
    }
    
    public int getCount() {
        return count.get();
    }
}

AtomicInteger 的 incrementAndGet 通过 CAS 自旋保证了读改写操作的原子性，getCount() 直接读取 volatile 变量，开销很小。在低竞争场景下，这个方案通常具有最好的性能。

6.3 复合操作场景：为什么这时候只能选 synchronized

如果业务逻辑是对单个变量的简单自增、自减，Atomic 类完全可以胜任。但现实业务中，很多并发操作是“一组操作必须捆绑在一起完成”的复合操作，这时候 Atomic 就无能为力了。

举一个典型的复合操作场景：转账操作。假设有两个账户 A 和 B，需要从 A 转 100 元到 B。这个操作包含两个步骤：扣减 A 的余额、增加 B 的余额。这两个步骤必须作为一个整体原子执行——要么都成功，要么都失败，不能出现 A 扣了钱但 B 没到账的情况。

如果用 Atomic 类分别维护余额：

java复制AtomicLong balanceA = new AtomicLong(1000);
AtomicLong balanceB = new AtomicLong(1000);

// 转账：从 A 转 100 到 B
boolean success = tryTransfer(100);

tryTransfer 内部需要先判断 A 的余额是否充足，然后扣减 A、增加 B。这个判断和两个操作之间有依赖关系，很难单纯通过 CAS 来保证整体原子性。虽然理论上可以通过循环加 CAS 结合其他标记位实现，但代码复杂度会急剧上升，且容易出现肉眼难以发现的逻辑漏洞。

相比之下，synchronized 处理这种场景就非常简单：

java复制private final Object lock = new Object();
private long balanceA = 1000;
private long balanceB = 1000;

public void transfer(long amount) {
    synchronized (lock) {
        if (balanceA < amount) {
            throw new IllegalArgumentException("余额不足");
        }
        balanceA -= amount;
        balanceB += amount;
    }
}

synchronized 将整段代码作为临界区执行，同一时刻只有一个线程能够执行转账逻辑，天然保证了复合操作的原子性。虽然简单粗暴，但在这个场景下它是最直接、最不容易出错的选择。

这也是我在实际项目中的一个核心选型原则：单变量的简单并发操作，优先考虑 Atomic；多变量的复合操作，不要犹豫，直接用 synchronized 或锁。

7. 一张表看懂三者的选型边界

7.1 四大核心维度的横向对比

为了让大家在写代码时能快速决策，我把三个工具在关键维度上的差异整理成了一张表。这张表是我在做技术评审时拿来即用的：

这张表的关键点在于第三行——“复合操作”。这是我判断该用哪个工具的“第一性原理”。先判断业务逻辑是单变量操作还是多变量复合操作，再考虑可见性和原子性的需求，基本就能锁定正确的工具。

7.2 按场景直接给出选型建议

基于上面的分析，我总结了实际开发中最常用的几个场景，直接给出结论：

1. 双检锁中的实例引用字段

java复制private static volatile Singleton instance;

选 volatile。需要的是阻止指令重排序，保证发布对象的可见性。

2. 停止线程的开关标志

code复制private volatile boolean shutdown;

选 volatile。只有一个线程写，其他线程读，天然契合 volatile 的特征。

3. 请求计数器、指标统计

java复制AtomicLong requestCount = new AtomicLong(0);
requestCount.incrementAndGet();

选 Atomic。高频的读改写操作，无锁自旋即可完成，不加锁，也更轻量。如果是超高并发下的统计类需求，改用 LongAdder 效果更好。

4. 多字段状态下的一致性变更

比如订单状态的流转，需要同时校验状态并更新多个字段。选 synchronized 或显式锁（如 ReentrantLock），确保复合操作的原子性。

java复制public void cancelOrder(Order order) {
    synchronized (order) {
        if (order.getStatus() != Status.PAID) {
            throw new IllegalStateException("只能取消已支付订单");
        }
        order.setStatus(Status.CANCELED);
        order.setCancelTime(new Date());
    }
}

7.3 那些让我印象深刻的“选错工具”案例

最后分享两个我在实际项目中见过的选型失误案例，都是能直接复现的教训。

案例一：用 volatile 修计数器，导致线上数据不准。 某团队在做运营活动抽奖时，用 volatile int count 记录剩余奖品数量，剩余 0 时停止抽奖。结果活动上线后，出现了严重超发——剩余奖品数量变成了负数。这正是不保证原子性导致的结果：多个线程同时将 count 从 1 减到 0，又从 0 减到 -1。换成 AtomicInteger 后问题立刻解决。

案例二：用 AtomicReference 实现复杂状态机，代码读不懂也调不动。 某个支付系统的退款状态流转，开发同学想当然地用了 AtomicReference<RefundState>，希望通过 CAS 保证状态转移的原子性。但退款逻辑远不止改一个状态，还需要同时更新退款金额、操作人、退款时间等字段，并且当状态转移失败时还需要触发外部系统的补偿逻辑。最后这套代码充满了 for 循环和无数个 compareAndSet，bug 频出。我后来用 synchronized 包住整个状态机转移方法，代码量砍掉一半，逻辑清晰易懂，问题迎刃而解。

这两个案例非常典型：选型不是选“性能最好的工具”，而是选“能力恰好匹配需求的工具”。 volatile 能力有限，硬拿来做计数器是不可行的。Atomic 虽然灵活，但不适合复杂复合操作。真正成熟的开发者，会根据操作的特征选择最恰当的工具，而不是一味追求花哨。

8. 扩展思考：从 Java 到 C++ 的 volatile 对比

我在和一些做 C++ 的朋友交流时发现一个有趣的现象：Java 和 C++ 中都有 volatile 关键字，但它们的行为和能力完全不同。如果你是一名跨语言开发者，这个差异必须搞清楚，否则在切换语言时对 volatile 的理解带过去，会出大问题。

8.1 C++ 的 volatile 更多是阻止编译器优化

C++ 标准中，volatile 的作用被定义为：告诉编译器，这个变量的值可能在程序控制之外被改变（比如被硬件设备、被信号处理器、被另一个线程修改），因此编译器不能对这个变量的访问进行优化。

具体来说，C++ 的 volatile 确保：

• 每次访问该变量时，编译器都会生成读取该变量内存的指令，而不是使用寄存器中缓存的副本。
• 对 volatile 变量的读写操作，不会被编译器随意删除或合并。

但请注意：C++ 的 volatile 不保证原子性，也不保证多线程之间的可见性（在非 x86 架构上尤其如此）。 C++ 标准甚至明确说了，除非硬件平台本身保证，否则 volatile 不能用于线程间同步。

8.2 C++ 多线程同步的正确选择：std::atomic

要在 C++ 中实现 Java volatile 类似的效果，应该使用 <atomic> 头文件提供的 std::atomic。std::atomic 不仅保证原子性，还支持内存序参数（memory_order），可以精确控制内存可见性的边界。

例如，C++ 中的原子标志位：

cpp复制#include <atomic>

std::atomic<bool> flag{true};

void shutdown() {
    flag.store(false, std::memory_order_release);
}

void doWork() {
    while (flag.load(std::memory_order_acquire)) {
        // 干活
    }
}

这里就对应了 Java 里 volatile 的可见性语义。相比之下，Java 的 volatile 在底层相当于默认了最强的内存序（sequential consistency），而 C++ 的 std::atomic 允许你显式设置更弱的内存序，从而获得更好的性能。

了解了这点后，你就能理解热搜词里为什么会出现 std::atomic 了。很多 C++ 程序员也在纠结 volatile 到底能不能用于多线程，答案是不能，要用 std::atomic。

8.3 跨语言经验谈：理解语言设计的语境

从跨语言的视角来看，我认为最核心的一个认知是：每种语言的并发模型和工具链，都是为该语言的生态和使用场景设计的。 Java 把 volatile 做成一个多线程可见性关键字，是因为 JVM 屏蔽了底层平台差异，可以提供统一的内存模型。C++ 把 volatile 定位为“防止优化”的机制，是因为 C++ 需要兼容嵌入式开发、驱动开发等需要直接操作硬件的场景。两种语言对编译优化和内存模型的基本假设不一样，导致同样的关键字，语义不能简单互通。

这条经验在我日常工作中非常实用。团队里如果有 C++ 经验丰富的同学转做 Java，或者 Java 经验丰富的同学去写 C++，最需要做的不是背 API，而是在意识层面重新建立对关键字和工具语义的认知模型。 否则很容易出现“带着 C++ 的思维写 Java”或“带着 Java 的思维写 C++”的尴尬局面。

9. 站在实战角度的三点体会

9.1 先在纸上画出“线程-变量-操作”的图，再写代码

我见过太多并发 bug，归根结底是开发者在动手写代码前，没有完整地梳理清楚线程之间如何交互。我的个人习惯是：写并发代码前，先在纸上画出有多少个线程会访问这个共享变量，每个线程执行什么操作，读写次数大概多少，操作之间是否有依赖关系。

画完之后通常会得到三类结论：

• 只有一个线程写、多个线程读 → volatile 足够
• 多个线程写同一个变量，但操作是简单的自增自减 → Atomic 合适
• 多个线程执行复合操作，需要整体原子性 → synchronized 或显式锁

这个方法朴素但有效。我经常建议团队里的年轻工程师，不要把并发编程的困难想得过于抽象，很多时候问题的答案就藏在“谁在写、谁在读、怎么组合”这三个问题的答案里。

9.2 不要一开始就考虑“性能优化”，先保证正确性

在技术社区经常看到类似的问题：“AtomicInteger 和 synchronized 哪个性能好？我要不要用 AtomicInteger 来优化这段 synchronized 代码？”

我的回答通常很直接：先把正确性问题搞清楚，再考虑性能优化的合理性。如果你连这个共享变量的可见性、原子性、复合操作边界都没搞清楚，就盲目追求用 Atomic 替代 synchronized，最后得到的可能是一段性能稍好但正确性存疑的代码。

一个很重要的工程经验是：并发 bug 的定位成本远高于同步机制带来的性能开销。 一个 synchronized 方法，如果只是偶尔被调用，即使竞争激烈，性能影响也微乎其微。但如果因为盲目用 Atomic 实现而引入了隐藏的复合操作缺陷，线上事故的修复成本将远超那点性能收益。

9.3 把三个工具联合使用，而不是对立起来

最后想强调一个容易被忽略的观点：volatile、synchronized、Atomic 不是互相排斥的，它们完全可以联合使用，各自发挥擅长的一面。

举一个实际例子。在某个项目里，我们需要维护一个最新配置的快照，多个线程读配置，一个线程更新配置。我的实现思路是：

• 配置数据本身用 volatile ConfigData 引用，保证发布时可见性
• 配置数据的内部字段保证不可变性（只读，通过构造函数初始化）
• 更新配置的整个逻辑使用 synchronized 保护，防止并发更新导致的竞态条件
• 统计配置更新次数的指标使用 AtomicLong

这样一种组合，让每个工具都做了它最擅长的事。volatile 负责高效发布不可变对象，synchronized 负责保护临界区的复合更新逻辑，AtomicLong 负责高频计数。这种分工，比任何一种“单键打天下”的方案都更健壮、更高效。

说到底，选择并发工具不是在选“最好的”，而是在选“最合适的”。工具之间没有绝对的优劣，只有与业务场景匹配与否的差别。理解和掌握这些差异，比死记 API 重要得多。希望这篇文章能帮你在下次面对 volatile、synchronized、Atomic 的选择时，少一些犹豫，多一些底气。