当前位置：首页 > news >正文

Java并发——CAS（比较并替换）

news 2026/5/12 13:48:18

在多线程编程中，如何安全地修改共享变量是永恒的课题。传统的synchronized关键字虽然保证了线程安全，但基于互斥锁的机制会导致线程阻塞、上下文切换，在竞争激烈的场景下可能成为性能瓶颈。于是，一种更轻量的同步方案——CAS（Compare And Swap）应运而生，它承载了无锁并发思想的落地实践。

本文将带你系统了解CAS的核心原理、底层实现、在Java中的应用以及必须面对的挑战，帮助你真正掌握这把并发编程的利器。

一、什么是CAS？

CAS的全称是Compare And Swap（比较并交换），它是一种CPU原语级的原子操作，用于实现多线程环境下共享变量的无锁修改。它包含三个核心参数：

V：主内存中的当前值（变量实际存储的位置）
A：线程预期的旧值（线程从主内存读取后保存在本地的副本）
B：线程希望写入的新值

CAS的执行过程极其简单：

如果 V == A，则将 V 更新为 B；否则不做任何操作。整个“比较+交换”过程由CPU硬件保证原子性，不会被任何其他线程中断。

从宏观上看，CAS是一条乐观的指令：它假定在读取之后到更新之前，没有其他线程修改过该变量；如果检测到被修改过，就失败重试。这种“失败则重试”的模式被称为自旋。

二、为什么需要CAS？

考虑一个经典的计数器累加场景：

private int count = 0; public void increment() { count++; }

count++在字节码层面被拆分为“读取-修改-写回”三步，多线程并发执行时必然出现数据覆盖，最终结果小于预期。传统的解决方案是使用synchronized：

public synchronized void increment() { count++; }

但synchronized是悲观锁，无论是否有竞争都会加锁，线程获取锁失败时会进入阻塞状态，触发操作系统级别的上下文切换，开销较大。

CAS提供了一种乐观的替代方案：它假设大多数情况下没有冲突，只在更新时检查，失败则重试，避免了线程挂起和唤醒的开销。在竞争不激烈的场景下，CAS的性能远优于synchronized。

三、CAS的底层实现

1. CPU层面的支持

CAS的原子性依赖于CPU提供的特殊指令。以x86架构为例，它提供了CMPXCHG指令，该指令可以完成“比较并交换”的操作。在多核环境下，该指令前会加上LOCK前缀，确保执行期间锁住总线或缓存行，防止其他核心同时访问该内存地址，从而保证原子性。

ARM架构则使用LDXR/STXR指令对，通过独占监视器实现类似的原子操作。

2. Java中的Unsafe类

在Java中，CAS操作由sun.misc.Unsafe类提供支持。该类是一个不安全的底层操作类，能够直接操作内存地址、执行CAS操作等。典型的CAS方法如下：

public final native boolean compareAndSwapInt(Object obj, long offset, int expect, int update);

其中offset是字段在对象中的内存偏移量，可以通过objectFieldOffset获取。普通开发者不应直接使用Unsafe，而是通过JDK提供的封装类——java.util.concurrent.atomic包下的原子类——来安全使用CAS。

3. AtomicInteger的源码解析

以AtomicInteger.incrementAndGet()为例，我们看一下CAS的典型应用：

public final int incrementAndGet() { return unsafe.getAndAddInt(this, valueOffset, 1) + 1; }

而getAndAddInt的实现是典型的自旋CAS：

public final int getAndAddInt(Object obj, long offset, int delta) { int current; do { current = this.getIntVolatile(obj, offset); // 获取当前值 } while (!this.compareAndSwapInt(obj, offset, current, current + delta)); return current; }

整个过程不断循环，直到CAS成功才退出。value字段被volatile修饰，保证了可见性，使得每次读取都能获取到最新的值。

四、CAS在Java中的应用

CAS是Java并发包（JUC）的基石，它的身影无处不在：

应用场景	典型类	说明
原子类	`AtomicInteger`、`AtomicLong`、`AtomicReference`	通过CAS实现线程安全的单变量操作
高性能计数器	`LongAdder`	采用分段累加思想，将热点分散，减少CAS冲突
并发集合	`ConcurrentHashMap`	初始化桶、更新计数器时使用CAS
同步器	`ReentrantLock`、`Semaphore`、`CountDownLatch`	AQS（AbstractQueuedSynchronizer）的state状态通过CAS维护

五、CAS的三大挑战与解决方案

任何技术都不是银弹，CAS也存在一些固有的缺陷，需要我们在使用时加以注意。

1. ABA问题

问题描述：一个变量的值从A变为B，又从B变回A。此时CAS检查时发现值仍为A，就会误认为没有被修改过，从而执行更新。在某些业务场景（如栈操作、银行转账）中，这种“中间过程”可能导致严重错误。

解决方案：引入版本号或时间戳。Java提供了AtomicStampedReference，它在比较时同时检查“值”和“版本号”，只有两者都匹配才更新。

AtomicStampedReference<String> ref = new AtomicStampedReference<>("A", 1); // 同时比较值和版本号 ref.compareAndSet("A", "B", 1, 2);

2. 循环时间长开销大（自旋消耗CPU）

问题描述：CAS通常配合自旋（无限循环）使用。在高并发下，大量线程同时争抢一个变量，频繁失败重试，会导致CPU占用率飙升。

解决方案：

限制自旋次数，超过一定次数后使用其他策略（如直接阻塞）。
使用LongAdder等分段累加工具，将单点竞争分散到多个Cell上，减少冲突。
JVM自适应自旋（在锁升级中应用），根据历史成功率动态调整自旋次数。

3. 只能保证一个共享变量的原子操作

问题描述：CAS一次只能对一个内存地址进行原子操作，如果需要同时更新多个变量，则无法保证原子性。

解决方案：

将多个变量封装成一个对象，使用AtomicReference进行原子更新。
使用传统的锁（synchronized或ReentrantLock）保护临界区。

六、CAS vs synchronized：如何选择？

对比维度	CAS	synchronized
实现方式	CPU原子指令（无锁）	Monitor互斥锁
线程状态	失败则自旋，不阻塞	失败则阻塞，挂起唤醒开销大
适用场景	低竞争、单变量简单操作	高竞争、多变量复杂逻辑
可重入性	不支持（需自行封装）	支持
性能特点	无竞争时极快，高竞争时自旋消耗CPU	低竞争时一般，高竞争时性能下降但可控