做Java开发这些年我发现一个规律不管校招社招并发编程这块几乎必考问来问去绕不开synchronized、volatile和CAS。很多人把这几个名词当成八股文在背面试的时候能说出定义但被追问“为什么这么用”“不用行不行”就卡住了。这篇文章就围绕这三个关键词把底层原理、对比、适用场景一次讲透。如果你正在准备Java面试或者刚接触多线程读完可以建立一套完整的并发认知如果你已经工作了重点看第三节的锁升级和第五节的场景选择逻辑很多线上疑难问题其实都是“用错了工具”导致的。1. 并发三剑客面试必问的底层逻辑1.1 三个概念解决的是同一个问题CPU、内存、磁盘在速度上差了好几个数量级所以现代计算机体系基本都是“CPU高速缓存 主内存 磁盘”的分层结构。Java线程在真正执行代码时不是每次都直接操作主内存而是会先把变量拷贝到自己的工作内存可以近似理解为CPU缓存操作完之后再同步回主内存。这个设计能大幅提升性能但也带来了三个并发编程的核心问题原子性、可见性、有序性。原子性一个操作要么全部执行要么完全不执行中间不能被其他线程打断。典型例子就是i它其实是“读-改-写”三步不是原子操作。可见性一个线程修改了共享变量其他线程能不能立刻看到。由于工作内存的存在修改不一定马上刷回主内存此时其他线程读到的就是旧值。有序性为了优化编译器和CPU可能会对指令进行重排序。在单线程下结果没问题但多线程环境下乱序执行可能导致逻辑错误。volatile、synchronized、CAS这三个工具本质上就是在解决这三个问题。volatile解决可见性和部分有序性synchronized通过锁机制解决原子性CAS则是一种硬件级的原子操作。面试官问这三个东西不是想听定义而是想看你能不能把“并发问题的本质”和“解决手段”对上号。1.2 面试官到底想考察什么面试官问“synchronized、volatile、CAS的区别”表面上是考知识点实际上是在考察两件事第一你知不知道 Java 内存模型 JMM第二遇到真实并发场景时你能不能做出合理的技术选型。JMM 是 Java 并发编程的理论地基。只要你搞懂了 JMM 里的主内存和工作内存再去看volatile和synchronized基本就不会懵。比如volatile的语义是对一个volatile变量的写操作会立刻刷回主内存对一个volatile变量的读操作会直接从主内存读取。这句话本质上就是在规定工作内存和主内存之间的交互行为。很多初学者容易陷入“背结论”的误区volatile性能好、synchronized性能差、CAS性能最好。实际上性能是相对的它跟竞争程度、临界区大小、硬件环境都有关系。面试官更希望听到你基于场景做判断而不是背一个绝对结论。2. volatile的真相不是万能的可见性保证2.1 volatile 到底干了什么volatile关键字在 Java 里是一个轻量级的同步机制它的核心能力有两个保证可见性以及禁止指令重排序。先看一个非常经典的例子public class VolatileDemo { 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(线程停止count count); }); t.start(); Thread.sleep(100); running false; // 主线程修改状态 System.out.println(主线程已将 running 置为 false); } }如果running不加volatile这段程序很可能永远不退出。原因是子线程的while循环一直在读自己的工作内存里的running主线程对running的修改没有及时同步过去子线程看到的永远是旧值。加上volatile之后子线程每次读running都会强制从主内存拉取最新值程序立刻就能停下来。volatile还会通过插入内存屏障来禁止重排序。也就是说CPU 在编译和执行时不能随便把volatile变量前后的代码调换顺序。这一点最典型的应用就是双重检查锁单例在后面我会专门展开。2.2 volatile 能保证什么不能保证什么volatile最容易被误解的点就是它不能保证原子性。看这段代码public class Counter { private volatile int count 0; public void increment() { count; // 这里有问题 } public int getCount() { return count; } }count看着像一行代码但它底层包含三步读取 count - count1 - 写回 count。多个线程同时执行时可能同时读到同一个旧值各自加一后写回导致最终结果比期望值小。volatile只能保证每一步的读取和写入是可见的不能保证“读-改-写”这个整体操作是原子的。所以在面试时如果面试官问“volatile 能保证原子性吗”一定要斩钉截铁地回答不能。如果你想保证原子性有两个方向一是用synchronized把整个临界区包起来二是用AtomicInteger等原子类底层走的就是 CAS。2.3 什么场景适合用 volatilevolatile最适合的场景是“单个线程写、多个线程读”的状态标志位。用volatile boolean控制线程的启动和停止。用volatile变量保存一些全局配置开关比如功能灰度开关。在单例模式的双重检查锁中用volatile修饰单例对象避免拿到未初始化完毕的“半成品”对象。不适合的场景也很明确多个线程同时写同一个变量、复合操作依赖于当前值、计数累加等。这些场景强行用volatile表面上代码能跑实际上问题会在高并发下随机出现排查成本极高。记住一句话volatile是廉价的可见性方案但它不是万能锁。3. synchronized的升级之路从重量级锁到无锁优化3.1 synchronized 到底锁的是什么synchronized是 Java 提供的内置锁也叫监视器锁Monitor Lock。它锁的不是代码而是对象。代码只是附加在某个对象上的临界区。最常见的三种写法public class SynchronizedDemo { // 1. 锁当前实例对象 public synchronized void instanceMethod() { // 同一实例下互斥 } // 2. 锁 Class 对象 public static synchronized void staticMethod() { // 同一类下互斥 } // 3. 锁指定对象 private final Object lock new Object(); public void blockMethod() { synchronized (lock) { // 锁 lock 对象 } } }第一种锁的是this第二种锁的是SynchronizedDemo.class第三种锁的是我们自己传入的lock对象。很多人面试答不上来“synchronized 锁的是什么”就是因为他只记住了关键字不理解对象监视器这个概念。3.2 锁升级过程JDK 对 synchronized 做的最大优化早期的synchronized确实性能很差因为它直接依赖操作系统的互斥量Mutex线程获取不到锁时会进入内核态阻塞涉及用户态和内核态的切换开销很大。所以很多时候它被称为“重量级锁”。但从 JDK 6 开始HotSpot 对synchronized做了大量优化引入了锁升级机制。在无竞争、低竞争的情况下synchronized并不一定会直接变成重量级锁。整个过程大致是无锁对象没有竞争没有任何线程尝试获取锁。偏向锁只有一个线程反复进入同步块时JVM 会在对象头记录线程 ID避免每次都用 CAS 去抢锁。轻量级锁一旦出现第二个线程竞争偏向锁撤销JVM 会通过 CAS 尝试竞争抢不到就短暂自旋。重量级锁自旋超过阈值或者竞争非常激烈时锁会升级为重量级锁线程真正进入阻塞状态。需要说明的是偏向锁在多个 JDK 版本中已经逐渐调整甚至默认关闭因为偏向锁的撤销过程本身也很耗时在如今很多高并发服务里收益并不明显。但“锁可以升级”这个思路依然是 JDK 对synchronized做过的核心竞争力提升。这带给我们的面试启示是不要再说synchronized一定是重量级锁。在低竞争场景下它的性能其实非常好而且使用简单、自动释放不容易出内存泄漏问题。3.3 synchronized 的优劣势与使用技巧synchronized最大的优点是简单可靠。它不会像手动加锁那样忘记解锁执行完同步块或者抛异常时JVM 会自动释放锁。同时它支持可重入同一个线程可以多次进入同一个锁的临界区不会把自己锁死。它的缺点也明显获取锁的线程如果一直不释放其他线程只能干等重量级锁状态下阻塞和唤醒的开销不小不能响应中断也不能设置超时时间。如果等待时间可能很长而且需要灵活中断可以换ReentrantLock或LockSupport来解决问题。实际开发中我建议你这样做尽量缩小同步范围不要直接在方法上无脑加synchronized。比如一个方法里只有三行代码需要保护其他代码全是在做耗时 IO那么就应该把同步代码块放在那三行上避免其他线程长时间被阻塞。还要注意锁对象不要随便暴露比如用synchronized (this)时外部类如果也拿这个对象当锁就可能出现意想不到的互相阻塞。内部模块我习惯用一个私有final Object lock new Object()把锁细节封装起来。4. CAS机制乐观锁在Java中的落地4.1 CAS 是什么底层怎么运作CAS 全称是 Compare And Swap翻译过来就是“比较并交换”。它是一条 CPU 指令级的原子操作比如 x86 上的cmpxchg指令。操作逻辑很简单比较内存中的当前值和期望值是否相等如果相等就把新值写进去如果不相等就说明有其他线程修改过了本次操作失败由调用方决定是否重试。Java 里的java.util.concurrent.atomic包就是基于 CAS 实现的。比如最常见的AtomicIntegerAtomicInteger counter new AtomicInteger(0); // 相当于 counter counter.incrementAndGet();如果自己用 CAS 实现一个累加大概长这样public class CasCounter { private AtomicInteger value new AtomicInteger(0); public void increment() { int expected; int next; do { expected value.get(); next expected 1; } while (!value.compareAndSet(expected, next)); } public int get() { return value.get(); } }先读取当前值作为期望值然后计算新值最后调用compareAndSet。如果失败说明值已经被别人改了那就循环重新读、重新算、重新尝试。这种“乐观”的思路默认冲突很少所以不加锁而是靠循环重试来保证正确性。4.2 ABA 问题与解决思路CAS 有一个出名的问题叫 ABA 问题。假设内存中的值是 A线程 1 准备把 A 改成 B但执行路径比较长。这段时间里线程 2 把 A 改成了 B又改回了 A。等线程 1 真正执行 CAS 时它发现内存中的值还是 A跟期望值一致于是 CAS 成功。但这个 A 已经不是原来的 A 了中间发生过其他修改线程 1 不知道。ABA 在“只关心当前值”的场景下影响不大比如计数器累加但在“关心过程中是否被改过”的场景下可能会造成严重问题比如无锁栈的节点复用。解决思路一般是加版本号每次修改不仅更新值还更新一个版本号。Java 里可以用AtomicStampedReference或AtomicMarkableReferenceAtomicStampedReferenceInteger ref new AtomicStampedReference(100, 0); int[] stampHolder new int[1]; Integer current ref.get(stampHolder); int stamp stampHolder[0]; // 比较值 版本号 boolean success ref.compareAndSet(current, 200, stamp, stamp 1);stamp可以理解成一个变化的“脚印”只要值变化过版本号就变化。这样即使值绕回原点CAS 也能发现版本对不上从而让操作失败避免误更新。4.3 CAS 的开销与 LongAdder 的设计思想CAS 比synchronized高效的关键在于它没有线程阻塞和唤醒。但 CAS 也有自己的开销而且这个开销很有意思它是“让 CPU 空转”。当多个线程同时对一个共享变量做 CAS 操作时只有一个线程能成功其余线程都会失败并重试。如果竞争非常激烈CPU 会一直循环执行 CAS占用大量计算资源形成类似“自旋锁风暴”的问题。JDK 团队也很早就意识到了这一点所以推出了LongAdder。它的核心思路是不要所有线程都去抢同一个变量而是维护一个Cell[]数组每个线程优先更新自己分配的 Cell最后再汇总求和。这样即使并发很高也把竞争压力分散到了多个单元格上从“大家抢一把锁”变成了“各写各的账本”。这也是我在回答“CAS 什么时候不适合用”时经常提到的例子如果竞争激烈单纯的 CAS 并不一定比synchronized好分段思想往往更实用。5. 三者横向对比与典型应用场景5.1 一张表看懂核心区别面试时如果能现场画出这样一张对比表会比背一长段文字更有说服力对比维度volatilesynchronizedCAS底层机制内存屏障 禁止重排序对象监视器 MonitorCPU 指令 cmpxchg原子性不保证复合操作保证临界区原子性只保证单步操作原子性可见性保证保证需配合 volatile 变量有序性有限保证保证临界区内有序需要配合内存屏障线程阻塞不阻塞竞争升级后可能阻塞不自挂但可能自旋空转代码侵入低中低适用场景状态标志、单例 DCL多线程写共享资源计数器、无锁队列、AQS注意一个关键点CAS 本身并不能保证可见性。AtomicInteger里的value字段本身就声明为volatile int所以它既能通过 CAS 保证原子更新又能通过 volatile 语义保证读写的可见性。这也是为什么我们会说“JUC 原子类 volatile CAS”。5.2 场景题计数器、单例、状态开关面试官经常把这三个概念放在具体场景里让你选最常见的三个就是计数器、单例、状态开关。计数器如果只是多线程累加一个整数首选AtomicInteger或LongAdder不用加synchronized。但如果除了计数后面还要做一系列一致性操作那就要考虑用synchronized把整个操作包起来或者用数据库事务、分布式锁来控制。单例双重检查锁 DCL 是必考场景。代码长这样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因为new Singleton()不是一步完成的它包含分配内存、初始化对象、把引用指向对象这几个步骤。如果没有volatile编译器和 CPU 可能把“分配内存”和“把引用指向接口”重排到“初始化对象”之前。另一个线程在第一个线程还没初始化完时就可能看到非空的instance然后直接拿去用拿到一个半成品的对象。状态开关用volatile boolean控制工作线程的运行状态是最典型的应用。线程在每次循环时读取最新状态主线程通过修改状态来停止任务性能开销很小也没必要上锁。5.3 组合用法JUC 源码里的“三剑客”这三者不是互斥的很多高性能并发组件都在组合使用它们。最典型的就是AbstractQueuedSynchronizer也就是 AQS。AQS 里有一个volatile int state字段用来表示同步状态修改 state 时用compareAndSetState这就是 CAS如果抢锁失败线程会被包装成 Node 放进等待队列然后通过LockSupport挂起这本质上又是一个“阻塞”的过程。ConcurrentHashMap在并发计数时也用了类似LongAdder的 CounterCell 数组思想避免所有线程都去竞争同一个原子变量。它的很多更新操作也会优先使用 CAS只有 CAS 难以覆盖的复杂复合操作才会去加synchronized锁。这说明一个问题volatile、synchronized、CAS是同一套并发体系的三个工具综合使用才能写出既有性能又有正确性的代码。面试时如果能举出 JUC 组件里的实际用法会显得你并不是只会背概念而是真的研究过源码。6. 面试答题话术与避坑指南6.1 如何把答案组织得有条理面试官问“synchronized、volatile、CAS 有什么区别”时不要一上来就背定义。比较好的回答框架是先抛出并发三大特性再逐个对比。我的习惯是这样组织“这三个工具解决的是并发编程里的原子性、可见性、有序性问题。volatile 主要解决可见性和禁止重排序但它不保证原子性适合用在线程状态控制、双重检查锁这类场景。synchronized 是 JVM 内置的监视器锁能保证临界区的原子性、可见性和有序性缺点是重量级锁下阻塞唤醒开销大但 JDK 6 之后有锁升级优化竞争不激烈时性能并不差。CAS 是 CPU 层面的原子操作配合 volatile 变量可以实现无锁更新比如 AtomicInteger但它有 ABA 问题和自旋开销竞争激烈时会空转 CPU。”这样回答的优点是逻辑线清晰顺着“问题 - 工具 - 场景”走面试官想追问哪里都能接得住。6.2 常见的翻车点我在实际面试候选人和带新人时发现下面几个错误出现频率非常高把 volatile 说成能保证原子性。这是最致命的错误一句话就能让面试官对你打问号。说 synchronized 一定比 CAS 慢。没有上下文谈性能就是耍流氓低竞争下 synchronized 经过优化后和 CAS 差距很小代码可读性还好很多。说 CAS 是完全无锁的。CAS 不会让线程阻塞但它会自旋重试本质上是把线程调度的开销转移成了 CPU 循环开销。混淆偏向锁、轻量级锁、重量级锁的触发条件。锁升级不是每次都走完整个链路JVM 有各种阈值和自适应策略。不知道 ABA 问题怎么解决。只背出“有 ABA 问题”但说不出AtomicStampedReference的做法等于白背。还有一点容易被忽略volatile变量读写的 happens-before 规则。在 JMM 里对一个 volatile 变量的写操作 happens-before 后续对同一个 volatile 变量的读操作。也就是说如果线程 A 写了一个 volatile 变量线程 B 随后读到了这个变量那么 A 在写之前做的其他操作对 B 也是可见的。这个规则经常被拿来解释为什么双重检查锁里加volatile就够了。6.3 我的一点实战建议我早期准备面试时也走过弯路把这三个概念的定义背得滚瓜烂熟但一遇到“线上环境 CPU 飙高”“数据不一致”的问题就懵。后来我去查 JUC 源码、用压测工具跑并发基准测试才真正理解它们之间的差别。如果你时间有限我建议你做两件事第一把AtomicInteger的incrementAndGet和 AQS 的compareAndSetState源码读一遍看看 volatile 字段和 CAS 是怎么配合的第二自己写一个多线程累加的小程序分别用synchronized、AtomicInteger、LongAdder实现然后用不同线程数压测感受一下竞争强度对性能的影响。面试官最后问你“怎么记这三个东西”时我最常用的答案是volatile管可见synchronized管临界区CAS管无锁更新。但真正的高手不会只停在口号上而是能把这一句话展开成完整的原理、场景和源码证据。把这篇文章里的内容吃透遇到相关题目就不会再慌了。