基于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的操作,可理解为
修改A为B(2B)
修改B为A(3A)
此时线程1执行,获取到的A与当前内存中的3A就有差异了。
虽然能规避ABA问题,但是额外的开销势必会影响性能,而使用这种规避ABA问题的CAS实现,性能有没有使用synchronized高呢?可以根据实际业务场景和配置,做一个性能对比来权衡。

    推荐阅读