CAS 居然可以代替 synchorinzed

学习过多线程的同学一定看到过 CAS 这个概念,CASCompare-and-swap 的简称,那它有什么作用呢 ?为什么能够代替 synchorinzed?

CAS

CAS(Compare-and-swap):比较和替换,它是设计并发算法是的一种常用技术。使用 CAS 操作可用于保证变量更新的原子性。

CAS 操作涉及到 3 个值:

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

CAS 操作逻辑如下:CAS 比较 VA 的值,如果值相等则变量值更新为 B,否则不进行任何操作。如下图:

image

如果第一次接触到 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 关键字的功能缺陷。

先来看 volatile 关键字的作用,如下:

  • 有序性:防止重排序;
  • 可见性:变量更新时所有线程都可以访问到变量的最新值;
  • 原子性:只能保证单次读、写操作的原子性。

volatile 关键字的缺陷正是其无法保证变量操作的原子性,所以经常可以看到 volatilesynchorinzed 关键字共用的场景以保证变量操作的原子性,而 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 的操作来保证变量操作安全性的。

那下面对 CASsynchorinzed 的使用做下对比,主要从如下两方面:

功能限制:

  • CAS 更加轻量级,synchorinzed 升级为重量锁时会影响系统性能;
  • CAS 仅能保证单个变量操作的原子性,synchorinzed 可以保证代码块内所有变量操作的原子性。

多线程规模:

  • 少量线程:CAS 更具优势,synchorinzed 在少量情况下仍可能升级为重量锁影响系统性能。
  • 大量线程:synchorinzed 更具优势,由于 CAS 的很多实现都会使用了自旋操作,比如上面示例中的循环,当在大量线程的情况下 CAS 会频繁执行失败进而需要频繁重试,这样会浪费 CPU 资源。

在 Android 中的使用

Android 中我们也可以通过 Atomic*** 类来使用 volatile + CAS

  • AtomicFile()
  • AtomicInteger()
  • AtomicLong()
  • AtomicBoolean()
  • AtomicReferenceFieldUpdater()

前几个比较好理解,分别可以保证 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:目标变量名。

注意:field 目标变量必须是 volatile 变量。

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享