基于atomic包分析CAS原理

大家都知道，多线程下操作共享变量，会出现所谓的“线程安全问题”从而不能得到我们预期的结果，为了解决这种问题，在早期的JDK版本中，提供的synchronized关键字来解决这种线程安全问题，而在JDK1.5以后的java.util.concurrent包中，里面大量使用了一种叫CAS的技术，提供了一种不用synchronized的前提下解决线程安全问题的方案。本文将从AtomicInteger包入手，讲解CAS的原理和使用、以及CAS可能出现的问题

先来一个小demo

不想上来就贴上来千篇一律的各种概念，懂得人我不说也懂，不懂得看完概念依然不懂，用码说话，先看个小demo，开五个线程，每个线程累计1000次操作共享变量，共享变量分别使用int和基于CAS的AtomicInteger

public class AtomicTest {

    int count = 0;
    AtomicInteger atomicInteger = new AtomicInteger(0);

    // 加1操作
    public void add() {
        count++;
        atomicInteger.addAndGet(1);
    }

    public static void main(String[] args) throws InterruptedException {
        AtomicTest atomicTest = new AtomicTest();
        List<Thread> threads = new ArrayList<>();
        // 开5个线程
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(() -> {
                // 每个线程执行1000次add方法
                for (int num = 0; num < 1000; num++) {
                    atomicTest.add();
                }
            });
            threads.add(thread);
            thread.start();
        }
        // 保证上面开启的五个线程执行在main线程之前
        for (Thread thread : threads) {
            thread.join();
        }
        System.out.println("count-->" + atomicTest.count);
        System.out.println("atomic-->" + atomicTest.atomicInteger);
    }
}

结果可能每次都不一样，但是使用AtomicInteger的值每次必是5000

count-->3670
atomic-->5000

Process finished with exit code 0

点进源码看一下

（基于JDK1.8，不用版本可能稍有不同） 点进atomicInteger.addAndGet(1);

/**
     * Atomically adds the given value to the current value.
     *
     * @param delta the value to add
     * @return the updated value
     */
    public final int addAndGet(int delta) {
        return unsafe.getAndAddInt(this, valueOffset, delta) + delta;
    }

只有一行代码，然后调用了unsafe的getAndAddInt，传参分别是当前对象引用，valueOffset和我们要增加的值delta，valueOffset我们一会详细说一下，现在先点到unsafe.getAndAddInt(this, valueOffset, delta)中看一下

 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;
    }

我们看到，进入了一个叫Unsafe的类中，首先先调取this.getIntVolatile(var1, var2);，这是一个native方法，通过传入的var1（也就是上面AtomicInteger的this）和var2，从内存中获取到最新的值，然后执行compareAndSwapInt(var1, var2, var5, var5 + var4)方法，就是我们的主角CAS（Compare and Swap），依然是native方法，实现原理是拿当前获取到的值（var5）通内存的值比较，如果值相同，则将内存的值更新为新的值（var5+var4，var4也就是我们上面传入的delta），如果与内存中的值不同，则继续执行do中的逻辑，获取最新的var5并继续执行compareAndSwap操作，直至成功。 其实CAS直至JDK1.5才被广泛使用的原因是，CAS是需要硬件支持的，随着处理器的发展，逐渐提供了将一系列操作原子操作的指令，其中CAS底层使用的就是CMPXCHG指令。 回到上面这段代码，看到最后return的值为var5，并不是执行操作后最新的值，当返回var5后，addAndGet(int delta)中，再加上delta，其实大家想一想，这样操作，虽然能保证AtomicInteger内部每次操作都是原子性的，却不能保证每次调用addAndGet方法返回的数据是顺序的，换句话说，它能保证结果的最终一致性，但是并不能保证每条线程中间状态的一致性，这也是为什么atomic包的类适合计数，但并不适合做例如生成订单号等要求强顺序的业务操作。

重点说下valueOffset

回过头来，看下刚刚还没解释的valueOffset，是个啥。valueOffset，存于AtomicInteger的成员变量中，在静态代码块中初始化

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

然后整个AtomicInteger中并没有修改它的地方。说明这个值在整个JVM中是唯一的，一个唯一的值，还被频繁传到各种native方法中，有什么意义的？当我们创建了一个对象之后，在内存中开辟了一片空间，但是这个对象的这片空间中，也是存放了各种数据的，这些对象怎么存放样式，被称作“布局”，而这个valueOffset，就是获取的一个字段在这个布局中的一个相对位置，叫着“偏移量”，根据上面代码我们看到获取的是value，这样，通过当前对象和value的偏移量，可以在内存中快速的定位到value的值。

说到 CAS不得不说的ABA问题

CAS看起来不会有任何问题，完美解决了多线程下数据安全问题，但是可能有这样一个场景

线程1:获取内存中的值，为A然后被挂起线程2：获取内存中的值，为A修改A为B修改B为A执行完毕线程1:获取到的值A与内存中比对一致，可以操作

上述场景就出现了ABA问题，关于ABA问题会造成的问题，感兴趣的小伙伴可以查一查深入了解，要是基于我们正常使用的常用操作，能保证结果的正确，并不会对我们造成什么影响。如果非要规避ABA的场合，可以使用AtomicStampedReference，通过内部维护的一个时间戳来保证，比如上面线程2的操作，可理解为

修改A为B(2B)修改B为A(3A)

此时线程1执行，获取到的A与当前内存中的3A就有差异了。 虽然能规避ABA问题，但是额外的开销势必会影响性能，而使用这种规避ABA问题的CAS实现，性能有没有使用synchronized高呢？可以根据实际业务场景和配置，做一个性能对比来权衡。

解决ABA问题，目前的解决的方式有加版本号，使用AtomicMarkableReference加标记等的方式解决。