CAS详解及ABA问题的解决

序言

由于最近项目上遇到了高并发问题，而自己对高并发，多线程这里的知识点相对薄弱，尤其是基础，所以想系统的学习一下，以后可能会出一系列的JUC文章及总结 ，同时也为企业级的高并发项目做好准备。

本文是JUC文章的第二篇，如想看以往关于JUC文章，请点击JUC系列总结

此系列文章的总结思路大致分为三部分：

1. 理论（概念）；
2. 实践（代码证明）；
3. 总结（心得及适用场景）。

在这里提前说也是为了防止大家看着看着就迷路了。

CAS大纲

首先，下图是本文的大纲，也就是说在看本文之前，你需要先了解本文到底是讲什么内容，有个整体大观，然后逐个细分到内容层次去讲解。

CAS理论

在上一文中（从代码实践的角度解析volatile关键字），我们介绍了i++的为什么不保证原子性以及i++的一些处理办法，其中有一种方式是采用AtomicInteger类，但是你知道为什么么？

查看AtomicInteger.getAndIncrement()方法，发现其没有加synchronized也实现了同步。这是为什么？

什么是CAS?

CAS的全称是Compare-And-Swap，它是一条CPU并发原语。

正如它的名字一样，比较并交换，它是一种很重要的同步思想。如果主内存的值跟期望值一样，那么就进行修改，否则一直重试，直到一致为止。

而原语的执行必须是连续的，在执行过程中不允许被中断，也就是说CAS是一条CPU的原子指令，不会造成所谓的数据不一致性问题。

它的功能是判断内存某个位置的值是否为预期值，如果是则更改为新的值，这个过程是原子的。

我们来看一段代码：

public class CasDemo {
    public static void main(String[] args) {
        //初始值
        AtomicInteger integer = new AtomicInteger(5);
        //比较并替换
        boolean flag = integer.compareAndSet(5, 10);
        boolean flag2 = integer.compareAndSet(5, 15);

        System.out.println("是否自选并替换 \t"+flag +"\t更改之后的值为："+integer.get());
        System.out.println("是否自选并替换 \t"+flag2 +"\t更改之后的值为："+integer.get());
    }
}

你能猜到答案么？

是否自选并替换 	true 	更改之后的值为：10
是否自选并替换 	false	更改之后的值为：10

第一次修改，期望值为5，主内存也为5，修改成功，为10。

第二次修改，期望值为5，主内存为10，修改失败。

CAS原理

在翻了源码之后，大致可以总结出两个关键点：

1. 自旋；
2. unsafe类。

当点开compareAndSet方法后:

// AtomicInteger类内部
public final boolean compareAndSet(int expect, int update) {
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

通过这个方法，我们可以找出AtomicInteger内部维护了volatile int value和private static final Unsafe unsafe两个比较重要的参数。（注意value是用volatile修饰）

变量valueOffset，表示该变量在内存中的偏移地址，因为Unsafe就是根据内存偏移地址获取数据的。

变量value用volatile修饰，保证了多线程之间的内存可见性。

// AtomicInteger类内部
private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;

    static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    private volatile int value;

然后我们通过compareAndSwapInt找到了unsafe类核心方法：

//unsafe内部类
public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
    }

AtomicInteger.compareAndSwapInt()调用了Unsafe.compareAndSwapInt()方法。Unsafe类的大部分方法都是native的，用来像C语言一样从底层操作内存。

这个方法的var1和var2，就是根据对象和偏移量得到在主内存的快照值var5。然后compareAndSwapInt方法通过var1和var2得到当前主内存的实际值。如果这个实际值跟快照值相等，那么就更新主内存的值为var5+var4。如果不等，那么就一直循环，一直获取快照，一直对比，直到实际值和快照值相等为止。

比如有A、B两个线程

1. 一开始都从主内存中拷贝了原值为3；
2. A线程执行到var5=this.getIntVolatile，即var5=3。此时A线程挂起；
3. B修改原值为4，B线程执行完毕，由于加了volatile，所以这个修改是立即可见的；
4. A线程被唤醒，执行this.compareAndSwapInt()方法，发现这个时候主内存的值不等于快照值3，所以继续循环，重新从主内存获取。
5. 线程A重新获取value值，因为变量value被volatile修饰，所以其他线程对它的修改，线程A总是能够看到，线程A继续执行compareAndSwapInt进行比较替换，直至成功。

ABA问题

所谓ABA问题，其实用最通俗易懂的话语来总结就是狸猫换太子

就是比较并交换的循环，存在一个时间差，而这个时间差可能带来意想不到的问题。

比如有两个线程A、B：

1. 一开始都从主内存中拷贝了原值为3；
2. A线程执行到var5=this.getIntVolatile，即var5=3。此时A线程挂起；
3. B修改原值为4，B线程执行完毕;
4. 然后B觉得修改错了，然后再重新把值修改为3；
5. A线程被唤醒，执行this.compareAndSwapInt()方法，发现这个时候主内存的值等于快照值3，（但是却不知道B曾经修改过），修改成功。

尽管线程A CAS操作成功，但不代表就没有问题。有的需求，比如CAS，只注重头和尾，只要首尾一致就接受。但是有的需求，还看重过程，中间不能发生任何修改，这就引出了AtomicReference原子引用。

AtomicReference原子引用

AtomicInteger对整数进行原子操作，如果是一个POJO呢？可以用AtomicReference来包装这个POJO，使其操作原子化。

User user1 = new User("Jack",25);
User user2 = new User("Lucy",21);
AtomicReference<User> atomicReference = new AtomicReference<>();
atomicReference.set(user1);
System.out.println(atomicReference.compareAndSet(user1,user2)); // true
System.out.println(atomicReference.compareAndSet(user1,user2)); //false

本质是比较的是两个对象的地址是否相等。

使用场景：

一个线程使用student对象，另一个线程负责定时读表，更新这个对象。那么就可以用AtomicReference

AtomicStampedReference和ABA问题的解决

使用AtomicStampedReference类可以解决ABA问题。这个类维护了一个“版本号”Stamp，其实有点类似乐观锁的意思。

在进行CAS操作的时候，不仅要比较当前值，还要比较版本号。只有两者都相等，才执行更新操作。

AtomicStampedReference.compareAndSet(expectedReference,newReference,oldStamp,newStamp);

CAS总结

任何技术都不是完美的，当然，CAS也有他的缺点：

CAS实际上是一种自旋锁，

1. 一直循环，开销比较大。
2. 只能保证一个变量的原子操作，多个变量依然要加锁。
3. 引出了ABA问题（AtomicStampedReference可解决）。

而他的使用场景适合在一些并发量不高、线程竞争较少的情况，加锁太重。但是一旦线程冲突严重的情况下，循环时间太长，为给CPU带来很大的开销。