深入理解CAS
一、什么是CAS?
CAS(Compare and Swap，比较与交换)，通常指的是一种原子操作：针对一个变量，首先比较它内存中的值与期望值与是否相同，如果相同，就给它赋一个新值。
CAS的逻辑用伪代码实现如下：
if(value == expectedValue){
value = newValue;
}
上面的伪代码展示了CAS操作是由比较和交换组成的复合操作，但CAS是一个不可分割的操作，即CAS对应的两步操作是一个原子性的，其原子性是由硬件层面来得以保证的，我们只需要知道了CAS的比较和交换是一个原子操作即可。
CAS可以看作是一种乐观锁的实现，它不需要加锁就可以实现多线程之间变量的同步，Java原子类中的递增操作都是通过CAS自旋来完成的。
二、CAS应用
在Java中，CAS操作由Unsafe类提供支持，该类定义了针对不同类型变量的CAS操作
public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);
它们都是native方法，由Java虚拟机提供具体实现，这意味着不同的虚拟机实现可能会有所不同
以compareAndSwapObject()方法为例，该方法接收四个参数：对象实例、内存偏移量、字段期望值、字段新值。该方法会针对指定对象实例中的相应偏移量的字段执行CAS操作。
2.1 根据偏移量修改属性值
下面我们从代码的角度来理解CAS的具体操作，下面这段代码展示了如何获取一个Unsafe实例和某个类中变量的偏移量
public static Unsafe getUnsafe(){
try {
Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
theUnsafe.setAccessible(true);
return (Unsafe) theUnsafe.get(null);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
public static long getFieldOffset(Unsafe unsafe,Class clazz,String fieldName){
try {
return unsafe.objectFieldOffset(clazz.getDeclaredField(fieldName));
} catch (NoSuchFieldException e) {
throw new Error(e);
}
}
下面的代码展示了获取Entity类中x变量的偏移量，在一个对象中，包含了对象头和压缩指针，其中对象头占8字节，压缩指针占用4字节，所以在Entity类中，x属性的偏移量为12，如果在x后面定义一个y属性，由于x为int类型占用4字节，所以y的偏移量就是16
public class OffsetTest {
public static void main(String[] args) {
Unsafe unsafe = UnsafeFactory.getUnsafe();
long offset = UnsafeFactory.getFieldOffset(unsafe, Entity.class, "x");
System.out.println(offset);
}
}
class Entity{
int x;
}
通过下面代码就可以修改Entity对象中x属性的值
Entity entity = new Entity();
Unsafe unsafe = UnsafeFactory.getUnsafe();
long offset = UnsafeFactory.getFieldOffset(unsafe, Entity.class, "x");
boolean result = unsafe.compareAndSwapInt(entity, offset, 0, 3);
System.out.println(result+":"+entity.x);
2.2 使用CAS实现同步功能
下面的代码，如果没有进行任何的同步处理，最后得到的结果肯定不等于100000
public static int sum = 0;
@SneakyThrows
public static void main(String[] args) {
for (int i = 0; i < 10; i++){
new Thread(() ->{
for (int n = 0; n < 10000; n++){
sum++;
}
}).start();
}
Thread.sleep(1000);
System.out.println(sum);
}
我们可以通过Synchronized和Lock来实现同步，在使用Lock时需要注意一定要有try-finally代码块，在finally块中去释放锁，防止出现异常时，锁不能释放，其他线程永远处于阻塞状态
static Object object = new Object();
for (int i = 0; i < 10; i++){
new Thread(() ->{
synchronized (object){
for (int n = 0; n < 10000; n++){
sum++;
}
}
}).start();
}
static ReentrantLock lock = new ReentrantLock();
for (int i = 0; i < 10; i++){
new Thread(() ->{
lock.lock();
try {
for (int n = 0; n < 10000; n++){
sum++;
}
} finally {
lock.unlock();
}
}).start();
}
上面两种方式虽然能够得到线程安全的效果，但会有线程上下文的切换，开销是很大的，如果在高并发的情况的使用这种方式来进行自增操作，性能会有很大的影响，我们可以使用CAS自选达到同样的目的
首先我们定义了一个CASLock的类，这个类的cas()方法就实现了类似加锁的功能，如果cas()方法执行成功了，其他线程就没法再去修改state属性的值，直到该线程执行完成之后，把state属性值再改为0，其他线程才可以继续去尝试修改state的值，需要特别注意的是CAS操作的变量为了保证可见性需要加volatile关键字
public class CASLock {
// 加锁标志
private volatile int state;
private static final Unsafe UNSAFE;
private static final long OFFSET;
static {
UNSAFE = UnsafeFactory.getUnsafe();
OFFSET = UnsafeFactory.getFieldOffset(UNSAFE,CASLock.class,"state");
}
public boolean cas(){
return UNSAFE.compareAndSwapInt(this,OFFSET,0,1);
}
public int getState(){
return state;
}
public void setState(int state){
this.state = state;
}
}
这样我们就可以去修改一下上面自增的代码，当state的状态为0时，所以线程都可以去进行CAS操作，但只有一个线程会成功，相当于只有一个线程会获得锁，其他CAS失败的线程就一直自旋，直到state的状态变为0后，再去进行CAS操作，所以当CAS操作成功的线程执行完代码后，需要把state的状态再改为0，让其他线程再去抢占CAS操作。通过这种CAS自选的方式就得到与锁一样的效果，并且没有线程上下文的切换，所有线程都自选等待。
public static int sum = 0;
static CASLock casLock = new CASLock();
for (int i = 0; i < 10; i++){
new Thread(() ->{
for (;;){
if (casLock.getState() == 0 && casLock.cas()){
try {
for (int n = 0; n < 10000; n++){
sum++;
}
} finally {
casLock.setState(0);
}
break;
}
}
}).start();
}
三、CAS底层原理
仍然以compareAndSwapInt()方法为例，Hotsopt虚拟机对其实现如下：
#unsafe.cpp
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
UnsafeWrapper("Unsafe_CompareAndSwapInt");
oop p = JNIHandles::resolve(obj);
// 根据偏移量，计算value的地址
jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
// Atomic::cmpxchg(x, addr, e) cas逻辑 x:要交换的值 e:要比较的值
//cas成功，返回期望值e，等于e,此方法返回true
//cas失败，返回内存中的value值，不等于e，此方法返回false
return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
其中核心的逻辑在Atomic::cmpxchg方法中，这个根据不同的操作系统和不同CPU会有不同的实现，这里以linux_x86为例，查看该方法的实现
#atomic_linux_x86.inline.hpp
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
//判断当前执行环境是否为多处理器环境
int mp = os::is_MP();
//LOCK_IF_MP(%4) 在多处理器环境下，为 cmpxchgl 指令添加 lock 前缀，以达到内存屏障的效果
//cmpxchgl 指令是包含在 x86 架构及 IA-64 架构中的一个原子条件指令，
//它会首先比较 dest 指针指向的内存值是否和 compare_value 的值相等，
//如果相等，则双向交换 dest 与 exchange_value，否则就单方面地将 dest 指向的内存值交给exchange_value。
//这条指令完成了整个 CAS 操作，因此它也被称为 CAS 指令。
__asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
: "=a" (exchange_value)
: "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
: "cc", "memory");
return exchange_value;
cmpxchgl的详细执行过程：
首先，输入是"r" (exchange_value), “a” (compare_value), “r” (dest), “r” (mp)，表示compare_value存入eax寄存器，而exchange_value、dest、mp的值存入任意的通用寄存器。嵌入式汇编规定把输出和输入寄存器按统一顺序编号，顺序是从输出寄存器序列从左到右从上到下以“%0”开始，分别记为%0、%1···%9。也就是说，输出的eax是%0，输入的exchange_value、compare_value、dest、mp分别是%1、%2、%3、%4。
因此，cmpxchg %1,(%3)实际上表示cmpxchg exchange_value,(dest)
需要注意的是cmpxchg有个隐含操作数eax，其实际过程是先比较eax的值(也就是compare_value)和dest地址所存的值是否相等，
输出是"=a" (exchange_value)，表示把eax中存的值写入exchange_value变量中。
Atomic::cmpxchg这个函数最终返回值是exchange_value，也就是说，如果cmpxchgl执行时compare_value和dest指针指向内存值相等则会使得dest指针指向内存值变成exchange_value，最终eax存的compare_value赋值给了exchange_value变量，即函数最终返回的值是原先的compare_value。此时Unsafe_CompareAndSwapInt的返回值(jint)(Atomic::cmpxchg(x, addr, e)) == e就是true，表明CAS成功。如果cmpxchgl执行时compare_value和(dest)不等则会把当前dest指针指向内存的值写入eax，最终输出时赋值给exchange_value变量作为返回值，导致(jint)(Atomic::cmpxchg(x, addr, e)) == e得到false，表明CAS失败。
现代处理器指令集架构基本上都会提供 CAS 指令，例如 x86 和 IA-64 架构中的 cmpxchgl 指令和 comxchgq 指令，sparc 架构中的 cas 指令和 casx 指令。
不管是 Hotspot 中的 Atomic::cmpxchg 方法，还是 Java 中的 compareAndSwapInt 方法，它们本质上都是对相应平台的 CAS 指令的一层简单封装。CAS 指令作为一种硬件原语，有着天然的原子性，这也正是 CAS 的价值所在。
四、CAS缺陷
CAS虽然高效的解决了原子操作，但它本身也有一些缺陷，主要体现在三个方面：
- 自旋CAS长时间不成功，则会给CPU带来非常大的开销
- 只能保证一个共享变量原子操作
- ABA问题
4.1 ABA问题概述
前两个缺陷都比较好理解，主要介绍一下ABA问题以及解决方法
我们在上面使用CAS自旋实现共享变量同步时，包括两步操作，先获取变量的值，再进行CAS操作，而这两个步骤并不是原子性的，就会出现一个问题，当线程A获取共享变量后，假设变量值为3，还没有进行CAS操作，此时线程A的CPU时间片用完了。两外有两个线程B和C，线程B讲共享变量从3改成了5，而线程C又把共享变量从5改成了3，此时当线程A进行CAS操作时，之前获取的共享变量值与现在内存中的值是一样，所以CAS操作可以成功，在这个过程中线程A没有感知共享变量的任何其他操作。
下面的代码可以展示ABA问题，线程1没有感知到中间对变量的修改
@Slf4j
public class ABATest {
public static void main(String[] args) {
AtomicInteger atomicInteger = new AtomicInteger(1);
new Thread(()->{
int value = atomicInteger.get();
log.debug("Thread1 read value: " + value);
// 阻塞1s
LockSupport.parkNanos(1000000000L);
// Thread1通过CAS修改value值为3
if (atomicInteger.compareAndSet(value, 3)) {
log.debug("Thread1 update from " + value + " to 3");
} else {
log.debug("Thread1 update fail!");
}
},"Thread1").start();
new Thread(()->{
int value = atomicInteger.get();
log.debug("Thread2 read value: " + value);
// Thread2通过CAS修改value值为2
if (atomicInteger.compareAndSet(value, 2)) {
log.debug("Thread2 update from " + value + " to 2");
// do something
value = atomicInteger.get();
log.debug("Thread2 read value: " + value);
// Thread2通过CAS修改value值为1
if (atomicInteger.compareAndSet(value, 1)) {
log.debug("Thread2 update from " + value + " to 1");
}
}
},"Thread2").start();
}
}
4.2 ABA问题解决方案
数据库有个锁成为乐观锁，是一种基于数据库事务版本实现数据同步的机制，每修改一次数据，版本就会进行累加。
同样，Java也提供了相应的原子应用类AtomicStampedReference
通过内部类Pair来封装版本号和变量值，reference即为实际存储的变量的值，stamp为版本号，每次修改可以通过版本号+1来保证唯一性。这样就可以保证每次修改之后的版本号也会递增
public class AtomicStampedReference<V> {
private static class Pair<T> {
final T reference;
final int stamp;
private Pair(T reference, int stamp) {
this.reference = reference;
this.stamp = stamp;
}
static <T> Pair<T> of(T reference, int stamp) {
return new Pair<T>(reference, stamp);
}
}
private volatile Pair<V> pair;
……
}
AtomicStampedReference的compareAndSet()方法源码如下，先对数据进行基本的比较，然后再将通过CAS操作来完成Pair对象的替换
public boolean compareAndSet(V expectedReference,
V newReference,
int expectedStamp,
int newStamp) {
Pair<V> current = pair;
return
expectedReference == current.reference &&
expectedStamp == current.stamp &&
((newReference == current.reference &&
newStamp == current.stamp) ||
casPair(current, Pair.of(newReference, newStamp)));
}
private boolean casPair(Pair<V> cmp, Pair<V> val) {
return UNSAFE.compareAndSwapObject(this, pairOffset, cmp, val);
}
其中AtomicMarkableReference可以看作是AtomicStampedReference的简化版实现，它只关注值是否发生了修改，而不是通过版本号记录修改了几次，所以使用一个boolean类型的mark属性来记录
public class AtomicMarkableReference<V> {
private static class Pair<T> {
final T reference;
final boolean mark;
private Pair(T reference, boolean mark) {
this.reference = reference;
this.mark = mark;
}
static <T> Pair<T> of(T reference, boolean mark) {
return new Pair<T>(reference, mark);
}
}
private volatile Pair<V> pair;
……
}