基于atomic包分析CAS原理基于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 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-->5000Process 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
【基于atomic包分析CAS原理】回过头来，看下刚刚还没解释的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的操作，可理解为