1 CAS是什么
CAS是Compare-And-Swap的缩写,即对比和替换,它在保证数据原子性的前提下尽可能的减少了锁的使用,很多编程语言或者系统实现上都大量的使用了CAS。
因为没有线程阻塞唤醒带来的性能消耗问题。这也是为什么CAS比synchronized性能高的原因!
1.1 JAVA中CAS的实现
JAVA中的CAS主要使用的是Unsafe类。Unsafe的CAS操作主要是基于硬件平台的汇编指令,目前的处理器基本都支持CAS,只不过不同的厂家的实现不一样罢了。
sun.misc.Unsafe类虽然提供了一系列直接操作内存对象的方法,但只是在jdk内部使用,JAVA官方不建议开发者直接调用Unsafe类;所以我们一般直接使用到的,都是java.util.concurrent.atomic包下的Atomic*类,比如AtomicBoolean、AtomicInteger等,其compareAndSet方法,也都是调用的Unsafe的CAS方法。
1 | public final class Unsafe { |
- value 表示 需要操作的对象
- valueOffset 表示 对象(value)的地址的偏移量(通过Unsafe.objectFieldOffset(Field valueField)获取)
- expect 表示更新时value的期待值
- update 表示将要更新的值
具体过程为每次在执行CAS操作时,线程会根据valueOffset去内存中获取当前值去跟expect的值做对比如果一致则修改并返回true,如果不一致说明有别的线程也在修改此对象的值,则返回false。
Unsafe类中compareAndSwapInt的具体实现所对应的cpp代码为:
1 | UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x)) |
1.2 CAS和自旋的配合
很多文章都信誓旦旦的说CAS底层使用自旋,从而达到高效的无锁并发。这是将Atomic的CAS实现和Unsafe的CAS实现混淆的结果,JAVA的CAS追本溯源都在Unsafe的CAS方法中,它顾名思义,只有比较和替换,没有自旋。
但不可否认,当CAS和自旋搭配使用的时候,确实效果更佳,尤其是在并发做加减的时候,所以Unsafe类提供了一个将CAS和自旋搭配使用的自增方法。
1 | public final int getAndSetInt(Object var1, long var2, int var4) { |
相同原理的还有getAndSetLong/getAndSetObject/getAndAddLong/getAndAddInt等方法。
1.3 Java 8对CAS机制的优化——LongAdder
当并发操作一个AtomicInteger而不是使用synchronize时,我们确实可以享受到CAS无锁并发带来的高性能,但CAS就完美无缺么?肯定不是的,比如说大量的线程同时并发修改一个AtomicInteger,可能有很多线程会不停的自旋,进入一个无限重复的循环中。
这些线程不停地获取值,然后发起CAS操作,但是发现这个值被别人改过了,于是再次进入下一个循环,获取值,发起CAS操作又失败了,再次进入下一个循环。
在大量线程高并发更新AtomicInteger的时候,这种问题可能会比较明显,导致大量线程空循环,自旋转,性能和效率都不是特别好。
于是,Java 8推出了一个新的类,LongAdder,他尝试使用分段CAS以及自动分段迁移的方式来大幅度提升多线程高并发执行CAS操作的性能!
在LongAdder的底层实现中,首先有一个base值,刚开始多线程来不停的累加数值,都是对base进行累加的,比如刚开始累加成了base = 5。
接着如果发现并发更新的线程数量过多,就会开始施行分段CAS的机制,也就是内部会搞一个Cell数组,每个数组是一个数值分段。这时,让大量的线程分别去对不同Cell内部的value值进行CAS累加操作,这样就把CAS计算压力分散到了不同的Cell分段数值中。
如此操作可以大幅度的降低多线程并发更新同一个数值时出现的无限循环的问题,大幅度提升了多线程并发更新数值的性能和效率!
更重要的是他内部实现了自动分段迁移的机制,也就是如果某个Cell的value执行CAS失败了,那么就会自动去找另外一个Cell分段内的value值进行CAS操作。这样也解决了线程空旋转、自旋不停等待执行CAS操作的问题,让一个线程过来执行CAS时可以尽快的完成这个操作。
最后,如果你要从LongAdder中获取当前累加的总值,就会把base值和所有Cell分段数值加起来返回给你。
LongAdder顾名思义,只是一个自增器,只能用来做增长操作
2 CAS的ABA问题
CAS还存在一个更加严重的问题——ABA问题:
线程1准备用CAS修改变量值A,在此之前,其它线程将变量的值由A替换为B,又由B替换为A,然后线程1执行CAS时发现变量的值仍然为A,所以CAS成功。但实际上这时的现场已经和最初不同了。
有没有解决方案呢?有的,JAVA中ABA中解决方案有两种,我们依次介绍
2.1 AtomicStampedReference类
解决ABA最简单的方案就是给值加一个修改版本号,每次值变化,都会修改它版本号,CAS操作时都对比此版本号。
AtomicStampedReference就是这种思路在JAVA中的产物,它主要维护包含一个对象引用以及一个可以自动更新的整数”stamp”的pair对象来解决ABA问题。
其关键代码如下(省略无用代码):
1 | //关键代码 |
不需要过分在意源码,我们只要知道怎么用就好,demo如下:
1 | public static void main(String[] args) { |
2.2 AtomicMarkableReference类
AtomicMarkableReference可以理解为AtomicStampedReference的简化版,就是不关心修改过几次,仅仅关心是否修改过。因此变量mark是boolean类型,仅记录值是否有过修改。
关键代码如下
1 | // Pair对象维护对象的引用和对象标记 |
不需要过分在意源码,我们只要知道怎么用就好,demo如下:
1 | public class AtomicMarkableReferenceDemo { |
输出结果
1 | 线程A : 初始值为:10 , 标记为: false |
由于线程B修改了对象,标记由false改为true,所以当上下文切换为线程A的时候,如果标记不一致,线程A执行CAS方法就会返回false。