CAS 竟然能够代替 synchorinzed

学习过多线程的同窗必定看到过 CAS 这个概念，CAS 是 Compare-and-swap 的简称，那它有什么做用呢？为何可以代替 synchorinzed?java

CAS

CAS（Compare-and-swap）：比较和替换，它是设计并发算法是的一种经常使用技术。使用 CAS 操做可用于保证变量更新的原子性。算法

CAS 操做涉及到 3 个值：安全

V 当前值：变量当前在内存中的值
A 指望值：指望变量当前在内存中的值
B 更新值：准备为变量赋予的新值

CAS 操做逻辑以下：CAS 比较 V 和 A 的值，若是值相等则变量值更新为 B，不然不进行任何操做。以下图：markdown

若是第一次接触到 CAS 的概念可能对它的操做逻辑产生疑惑，为何在相等的状况下执行赋值操做而不等的状况下反而什么都不作呢？下面看一个自增操做的示例：多线程

/**
 * Atomically increments by one the current value.
 *
 * @return the updated value
 */
public final int incrementAndGet() {
    for (;;) {
        //获取当前值, 此示例中当前值也是本次 `CAS` 的指望值
        int current = get();
        //获取更新值
        int next = current + 1;
        //执行CAS操做
        if (compareAndSet(current, next)) {
            //成功后才会返回指望值，不然无线循环
            return next;
        }
    }
}
复制代码

如今有线程 A、B，当线程 A 执行到 CAS 操做, 获取当前值、指望值和更新值分别为 0、0、1, 此时线程 A 被挂起，线程 B 进入执行 CAS 操做将变量值成功更新为 1, 线程 A 继续执行 CAS 操做, 因为此时变量当前值已经被修改，因此本次 CAS 执行失败，循环继续执行 CAS 自增操做，执行成功退出循环。并发

CAS VS synchorinzed

经过上面的示例知道 CAS 能够保证变量更新的原子性，进而能够联想到 volatile 关键字的功能缺陷。ide

先来看 volatile 关键字的做用，以下：高并发

有序性：防止重排序；
可见性：变量更新时全部线程均可以访问到变量的最新值；
原子性：只能保证单次读、写操做的原子性。

volatile 关键字的缺陷正是其没法保证变量操做的原子性，好比单目运算符 ++、-- 就涉及到读写两个操做。因此常常能够看到 volatile 和 synchorinzed 关键字共用的场景以保证变量操做的原子性，而 CAS 也能够保证变量操做的原子性。那 CAS 是否能够替代 synchorinzed 呢？在某些状况下是能够的。性能

好比在上面的示例中，AtomicInteger().getAndIncrement() 的内部源码以下：学习

/**
 * Atomically increments by one the current value.
 *
 * @return the previous value
 */
public final int getAndIncrement() {
    return U.getAndAddInt(this, VALUE, 1);
}

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;
}
复制代码

能够看到这里就是经过 volatile + CAS 的操做来保证变量操做安全性的。

那下面对 CAS 和 synchorinzed 的使用作下对比，主要从以下两方面：

功能限制：

CAS 更加轻量级，synchorinzed 升级为重量锁时会影响系统性能；
CAS 仅能保证单个变量操做的原子性，synchorinzed 能够保证代码块内全部变量操做的原子性。

并发规模：

低并发：CAS 更具优点，synchorinzed 在少许状况下仍可能升级为重量锁影响系统性能。
高并发：synchorinzed 更具优点，因为 CAS 的不少实现都会使用了自旋操做（以下文将介绍的 Atomic*** 系列），当在大量线程的状况下 CAS 会频繁执行失败进而须要频繁重试，这样会浪费 CPU 资源。

结论：在少许线程且仅需保证单个变量线程安全的状况下可以使用 volatile + CAS 替代 volatile + synchorinzed。

注意：volatile + CAS 和 volatile + synchorinzed 使用时要理解它们各自的角色和起到的做用：

volatile：保证有序性和可见性；

CAS、synchorinzed：保证操做原子性。

注意：多线程环境下正确使用 CAS 必须搭配 volatile 关键字。由于 CAS 虽然能够保证原子性，但其没法保证变量在不一样线程内存空间的安全性，因此须要 volatile 来保证变量更新对于不一样线程是可见的。

ABA 问题

除了上文提到过 CAS 的两个缺点：

仅能保证单个变量操做的原子性；
在高并发状况下 CAS 一直失败会一直重试，浪费 CPU 资源针。对这个问题的一个思路是引入退出机制，如重试次数超过必定阈值后失败退出。固然，更重要的是避免在高并发环境下使用 CAS。

还有一个问题就是 ABA 问题，现有线程 A、B：

线程 1 读取内存中的数据为 A；
线程 2 修改内存数据为 B；
线程 2 修改内存数据为 A；
线程 1 对数据执行 CAS 操做。

因为执行到第四步时内存数据仍然为 A，但其实数据已经被修改过了。这就是 ABA 问题。针对 ABA 问题能够经过引入版本号的方式解决，每次修改内存中的值版本号都 +1，在执行 CAS 操做是不只比较内存中的值也比较版本号，只有二者都相同时才执行成功。Java 中提供的 java.util.concurrent.atomic.AtomicStampedReference 也是经过版本号来解决 ABA 问题的。

在 Android 中的使用

在 Android 中咱们也能够经过 Atomic*** 类来使用 volatile + CAS。

AtomicFile
AtomicInteger
AtomicLong
AtomicBoolean
AtomicReferenceFieldUpdater
AtomicStampedReference

前几个比较好理解，分别能够保证 file、int、long、boolean 类型数据的原子操做，那么若是操做数据为 String 或类型不可知怎么办呢？这时候就可使用 AtomicReferenceFieldUpdater() 了。在 Kotlin.lazy 的实现中就使用到了 AtomicReferenceFieldUpdater：

private class SafePublicationLazyImpl<out T>(initializer: () -> T) : Lazy<T>, Serializable {
    @Volatile private var initializer: (() -> T)? = initializer
    @Volatile private var _value: Any? = UNINITIALIZED_VALUE
    // this final field is required to enable safe initialization of the constructed instance
    private val final: Any = UNINITIALIZED_VALUE

    override val value: T
        get() {
            val value = _value
            if (value !== UNINITIALIZED_VALUE) {
                @Suppress("UNCHECKED_CAST")
                return value as T
            }

            val initializerValue = initializer
            // if we see null in initializer here, it means that the value is already set by another thread
            if (initializerValue != null) {
                val newValue = initializerValue()
                if (valueUpdater.compareAndSet(this, UNINITIALIZED_VALUE, newValue)) {
                    initializer = null
                    return newValue
                }
            }
            @Suppress("UNCHECKED_CAST")
            return _value as T
        }

    ......
    
    companion object {
        private val valueUpdater = java.util.concurrent.atomic.AtomicReferenceFieldUpdater.newUpdater(
            SafePublicationLazyImpl::class.java,
            Any::class.java,
            "_value"
        )
    }
}
复制代码

AtomicReferenceFieldUpdater 经过静态方法 newUpdater() 获取实例对象。newUpdater() 方法有三个参数，分别是：

tclass：目标变量所在类的 class 对象；
vclass：目标变量的类型 class 对象；
fieldName：目标变量名。

在上述 kotlin.lazy 源码中经过比较初始值，保证在多线程环境中仅第一次赋值有效：

valueUpdater.compareAndSet(this, UNINITIALIZED_VALUE, newValue)
复制代码

再来看 AtomicStampedReference，它的初始化方法以下：

public AtomicStampedReference(V initialRef, int initialStamp) {
}
复制代码

能够看到初始化方法须要两个参数：

初始值
暂且看作初始版本号

用法以下：

private val atomicObj: AtomicStampedReference<String> = AtomicStampedReference("A", 0)

val t1 = Thread {
    try {
        TimeUnit.SECONDS.sleep(1)
    } catch (e: InterruptedException) {
    }
    println("run thread1")
    atomicObj.compareAndSet("A", "B", atomicObj.stamp, atomicObj.stamp + 1)
    atomicObj.compareAndSet("B", "A", atomicObj.stamp, atomicObj.stamp + 1)
}

val t2 = Thread {
    val stamp: Int = atomicObj.stamp
    try {
        TimeUnit.SECONDS.sleep(2)
    } catch (e: InterruptedException) {
    }
    println("run thread2")
    val result: Boolean = atomicObj.compareAndSet("A", "B", stamp, stamp + 1)
    println(result) // false
}

t1.start()
t2.start()
复制代码

能够看到因为 Thread2 提早获取了版本号，及时 Thread1 执行以后值依然是 A, 但因为版本号已然发生了变化因此 Thread2 的执行结果仍然是 false。