关于CAS问题解读（自我认识表达）

红太狼 2021-10-09 08:52 322阅读 0赞

起初，笔者本人第一次看到这个简写，cas，也是不了解的；但是对于笔者的性格，究其所以然。那么整起：

我们先看下这个词的表述：

# CAS：Compare and Swap，比较再交换 #

注意：此处我们咬文嚼字，比较再交换，比较再交换，比较再交换

重要的事情读三遍，中国文化博大精深，相信各位很好理解：也就是，需要先比较之后，再进行交换。

那么具体出现在什么地方呢？上源码：

public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);
    
    public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
    
    public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);

这段代码在我们的jdk中的

### **sun.misc.Unsafe**下 ###

细细分析，第一眼，看到此方法，会发现native这个关键字，那么这个是什么意思呢？

native是一个计算机函数，一个Native Method就是一个Java调用非[Java][]代码的接口。方法的实现由非Java语言实现，比如C或C++。

所以，可以知道，该方法是直接由汇编底层实现的方法，直接发送指令到机器，所以，我们可以看到，这里没有实现内容。

所以我们大可认为，这个方法，是不会存在多线程问题的。

那么上述，我们描述“比较再交换”，就是此处，那么是怎么个“比较再交换”呢？

可以看到 ![20200710220003755.png][]

此处有四个入参：都分别是什么意思呢？（该类没有注释）

这么解释

我们需要把 Integer age = 14; 改为 age = 15 ；那么age的对应的位置是 2134213；

那么就是 compareAndSwapInt(age, 2134213, 14, 15)；

这样是不是更好理解一些？

用稍微正确的语言描述就是 var1为 所被修改的对象， var2 为对应的属性偏移量， var4就是对应的修改前的值，  var5就是需要被交换后的值。

也就是：执行该方法，会去对应var2上对应的地址指向的值比较 是不是 和var4的值一致，如果一致，那么将会将var5的值进行赋值，执行交换动作。

这个时候衍生出一个新的东西，就是大家有没有发现，这个方法是有返回值的，就是boolean类型，返回的true和false是什么情况才会返回的呢？

当比较对应属性偏移量var2对应的值和var4所传入的值一致，那么就认为达到预期，那么将执行与var5进行交换。那么就是，如果预期比较一致，那么将返回true，并且交换成功了。如果与预期比较不一致，那么将返回false，那么就交换不成功。这也是返回值的一个条件。

那么这个返回值有何作用呢？上源码！

可以看到

java.util.concurrent.atomic.AtomicInteger

/**
         * Atomically sets the value to the given updated value
         * if the current value {@code ==} the expected value.
         *
         * @param expect the expected value
         * @param update the new value
         * @return {@code true} if successful. False return indicates that
         * the actual value was not equal to the expected value.
         */
        public final boolean compareAndSet(int expect, int update) {
            return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
        }

这个方法就引用了Unsafe中的compareAndSwapInt();方法。

再看下引用的地方（同一个类AtomicInteger ）

/**
         * Atomically updates the current value with the results of
         * applying the given function, returning the previous value. The
         * function should be side-effect-free, since it may be re-applied
         * when attempted updates fail due to contention among threads.
         *
         * @param updateFunction a side-effect-free function
         * @return the previous value
         * @since 1.8
         */
        public final int getAndUpdate(IntUnaryOperator updateFunction) {
            int prev, next;
            do {
                prev = get();
                next = updateFunction.applyAsInt(prev);
            } while (!compareAndSet(prev, next));
            return prev;
        }

\*使用的结果以原子方式更新当前值  
      \*应用给定的函数，返回上一个值。 的  
      \*该功能应无副作用，因为它可能会重新应用  
      \*当尝试更新由于线程间争用而失败时。

这个描述比较偏国外哈，那么用我的语言描述就是：会使用原子性的形式对一个对象进行更新值，该方法没有坏处，在多线程的环境下对同一个对象进行读写操作，如果执行“比较再交换”失败，那么将继续执行相同的操作。

那么，我们分析一下代码结构，执行流程哈。

可以看到，定义了两个整型值 prev, next；

执行do while语句进行循环。

首先执行一次结果代码块：获取到prev最新的值，再计算出需要替换后的值next，

然后调用compareAndSet()方法，判断这个刚刚获取到的值prev是不是和现在属性偏移量中的值一致，能不能更新?

如果不一致，不能更新，那好，代码再次去获取到prev最新的值，再计算出需要替换后的值next；

然后调用compareAndSet()方法，判断这个刚刚获取到的值prev是不是和现在属性偏移量中的值一致，能不能更新?

如果不一致，不能更新，那好，代码再次去获取到prev最新的值，再计算出需要替换后的值next；

然后调用compareAndSet()方法，判断这个刚刚获取到的值prev是不是和现在属性偏移量中的值一致，能不能更新?

........

直到刚刚获取的值prev和指针指向的值一致，更新成功，返回true，

然后  !true  不满足条件，退出循环。

返回 当前系统中最新的值。

### **这个动作就可以称之为“自旋锁”** ###

那么cas就是可以表达清晰了，通过比较再替换来表达其核心。通过“自旋锁”的实现方式来表达其内部的实现逻辑。

# **那么很多地方会对cas比较[synchronized][]两者的区别：** #

此处我简单分析一下：

1.通过比较两者的保持代码的原子性的实现方式，我们可以知道，sync是通过控制整个代码块来实现原子性的。而cas则是通过判断比较而交换来实现原子性的。通过两者的特性，可以知道，sync是一种类似某个时间点只能有一个线程访问该代码块，其他线程均同步阻塞。那么cas则是多线程间竞争访问该变量。如果在更新前，该变量被其他线程抢占，并更新，那么当前线程将进入锁，执行自旋锁，直至成功访问。这也是两者最大的区别，本质的区别，

通过此处，我们也可以究其效率性能问题探究一下：

cas并不会产生阻塞，而是不断线程间竞争。sync是严格杜绝其他线程访问同一数据。

两者可以猜出，cas在对于少量线程的时候，效率是大于sync;

sync在大量线程的时候，效率是大于cas的，并且在大量线程的时候，cas是需要消耗大量cpu的。

有兴趣的同学可以尝试比较一下两者具体性能差。

那么两者优缺点也油然而生。

但是cas还有一个很大的问题，笔者在初次学习的时候，也发问了。就是了解了cas的实现逻辑，想，这样不就有问题了吗？但是又被自己给否认了。觉得多虑了。

简单描述一下问题：假设线程A和线程B同时修改同一个对象。线程A执行效率为5s，线程B执行效率2s，该对象初始值为a，线程B将其改为c，然后又改为a，这个时候线程A计算完成了，判断比较的时候，发现获取主存中该对象的初始值和当前获取的值为一致，都是a，那么就将a改为d了。

那么这个时候，虽然线程A获取的值无变化，但是实际意义上，B都对其进行两次操作了。也就破坏了其原子性的概念。那么这就是 “ABA”问题了。

那么怎么解决该问题呢？

如何杜绝线程B在线程A不知情的情况下修改了两次数据，并且线程A还认为没修改呢？

那么解决方案，就是提供每次修改的日志记录，如果我们发现这次修改的记录的版本和获取的记录的版本不一致，那么就是已经被修改了。

那么JUC（java.util.concurrent）中也提供了一个解决方案：AtomicStampedReference

/**
         * Creates a new {@code AtomicStampedReference} with the given
         * initial values.
         *
         * @param initialRef the initial reference
         * @param initialStamp the initial stamp
         */
        public AtomicStampedReference(V initialRef, int initialStamp) {
            pair = Pair.of(initialRef, initialStamp);
        }

如果我们不能通过结果判断出这个对象，值是否被修改过，这个“Object”还是不是之前的“Object”了，那么我们就可以引用上述类：原子标记

通俗来来讲：就是我们记录每次原子性替换的动作。怎么记录呢？是的，我们可以通过版本号，每一次修改都是原子性的，版本号并不会被覆盖修改。那么就是说。我们每次都可以记录这个对象，值被修改后的版本号。那么我们就可以知道：这个版本1的“Object”已经变成了版本4的“Object”了。这样，我们就知道了当前数据已经被修改，那么我们就需要重新获取最新的值了。

有想法的可以看看，该类，该类没有无参构造，也就是说我们必须入参初始化。

initialRef：初始化值

initialStamp：初始化版本号

AtomicStampedReference ref = new AtomicStampedReference<Integer>(100, 1);

那么我们使用的时候就需要对其赋予值和版本号。

此处我声明一个对象，初始值为100     版本号为1。

/**
         * Atomically sets the value of both the reference and stamp
         * to the given update values if the
         * current reference is {@code ==} to the expected reference
         * and the current stamp is equal to the expected stamp.
         *
         * @param expectedReference the expected value of the reference
         * @param newReference the new value for the reference
         * @param expectedStamp the expected value of the stamp
         * @param newStamp the new value for the stamp
         * @return {@code true} if successful
         */
        public boolean compareAndSet(V   expectedReference,
                                     V   newReference,
                                     int expectedStamp,
                                     int newStamp) {
            Pair<V> current = pair;
            return
                expectedReference == current.reference &&
                expectedStamp == current.stamp &&
                ((newReference == current.reference &&
                  newStamp == current.stamp) ||
                 casPair(current, Pair.of(newReference, newStamp)));
        }

可以看到此处的匹配再替换，只有一个方法，并且有四个参数，按照顺序来：

expectedReference：预期值

newReference：新值

expectedStamp：预期版本

newStamp：新版本

那么这个时候，我们就可以考虑，如果当前版本乐观认为没有被修改，那么将，预期值和预期版本都是我们所知道的，也就是100和1

这个时候，我们就需要把版本升级和把新值赋予就可以了。

那么返回值也是boolean。来判断我们的结果是否替换成功。

![20200713220143502.png][]

具体问题我们就讲到这里。

**下次我们来聊聊ArrayList为什么不安全？**

[Java]: https://baike.baidu.com/item/Java/85979
[20200710220003755.png]: /images/20211009/3d3ae19698704595bc151d905a950be7.png
[synchronized]: https://www.cnblogs.com/willowWind/p/8551926.html
[20200713220143502.png]: /images/20211009/c2a4a134e2054b5eb3a2327fe23d366b.png