CAS乐观锁

目录

• CAS原理
  • 重试机制（循环 CAS）
  • 底层实现
• CAS 的问题
  • CAS的ABA问题
  • 循环时间长开销大
  • 只能保证单个变量的原子性

---

大佬文章：

CAS原理

深入理解 CAS 原理 | Java

Java CAS操作的实现原理深度解析与应用案例

面试必问的CAS原理你会了吗.md

---

CAS 全称为 Compare And Swap 翻译过来就是比较并且交换。它是指一种操作机制，而不是某个具体的类或方法。

在看到 Compare 和 Swap 后，我们就应该知道，CAS 里面至少包含了两个动作，分别是比较和交换，在现在的 CPU 中，为这两个动作专门提供了一个指令，就是CAH 指令，由 CPU 来保证这两个操作一定是原子的，也就是说比较和交换这两个操作只能是要么全部完成，要么全部没有完成。

在 Java 平台上对这种操作进行了包装。在 Unsafe 类中，调用代码如下：

unsafe.compareAndSwapInt(this, valueOffset, expect, update);

Unsafe类是Java实现CAS的基石，但它的作用不仅仅是实现CAS，还有操作直接内存等作用，实际上Unsafe类也是juc包的实现的基石。

它需要三个参数，分别是内存位置 V，旧的预期值 A 和新的值 B。

操作时，先从内存位置读取到值，然后和预期值A比较。
如果相等，则将此内存位置的值改为新值 B，返回 true。
如果不相等，说明和其他线程冲突了，则不做任何改变，返回 false。

这种机制在不阻塞其他线程的情况下避免了并发冲突，比独占锁的性能高很多。 CAS 在 Java 的原子类和并发包中有大量使用。

CAS原理

假设内存中的原数据V，旧的预期值A，需要修改的新值B。

1、比较 A 与 V 是否相等。（比较）
2、如果比较相等，将 B 写入 V。（交换）
3、返回操作是否成功

【注意】：是否当刚好判断 V 中值等于 A 的值的时候，另一个线程来修改了V 的值这种情况呢？

答案是不会的，CAS 操作的最终实现是依赖 CPU 原子性指令实现的，怎么说呢？CAS 是一种操作系统原语范畴的指令，是连续的，不允许被打断，不会造成数据不一致问题。

重试机制（循环 CAS）

有很多文章说，CAS 操作失败后会一直重试直到成功，这种说法很不严谨。

第一，CAS 本身并未实现失败后的处理机制，它只负责返回成功或失败的布尔值，后续由调用者自行处理。只不过我们最常用的处理方式是重试而已。

第二，这句话很容易理解错，被理解成重新比较并交换。实际上失败的时候，原值已经被修改，如果不更改期望值，再怎么比较都会失败。而新值同样需要修改。

所以正确的方法是，使用一个死循环进行 CAS 操作，成功了就结束循环返回，失败了就重新从内存读取值和计算新值，再调用 CAS。看下 AtomicInteger 的源码就什么都懂了：

public class AtomicInteger extends Number implements java.io.Serializable {
    private static final long serialVersionUID = 6214790243416807050L;
    
    // setup to use Unsafe.compareAndSwapInt for updates
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;
    
    static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }
    
    private volatile int value;
    ...
}

在AtomicInteger数据定义的部分，我们可以看到，其实实际存储的值是放在value中的，除此之外我们还获取了unsafe实例，并且定义了valueOffset。

再看到static块，懂类加载过程的都知道，static块的加载发生于类加载的时候，是最先初始化的，这时候我们调用unsafe的objectFieldOffset从Atomic类文件中获取value的偏移量，那么valueOffset其实就是记录value的偏移量的。

/**
 * Java实现：Atomically increments by one the current value.
 *
 * @return the updated value
 */
public final int incrementAndGet() {
	return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
 
// Unsafe 底层实现
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;
}

再回到上面一个函数getAndAddInt，我们看var5获取的是什么，通过调用unsafe的getIntVolatile(var1, var2)，这是个native方法，具体实现到JDK源码里去看了，其实就是获取var1中，var2偏移量处的值。var1就是AtomicInteger，var2就是我们前面提到的valueOffset，这样我们就从内存里获取到现在valueOffset处的值了。

现在重点来了，compareAndSwapInt（var1, var2, var5, var5 + var4）其实换成compareAndSwapInt（obj, offset, expect, update）比较清楚：

如果obj内的value和expect相等，就证明没有其他线程改变过这个变量，那么就更新它为update；
如果这一步的CAS没有成功，那就采用自旋的方式继续进行CAS操作；
其实这两个步骤，在JNI里是借助于一个CPU指令完成的。所以还是原子操作。

底层实现

CAS 底层是靠调用 CPU 指令集的 cmpxchg 完成的，它是 x86 和 Intel 架构中的 compare and exchange 指令。在多核的情况下，这个指令也不能保证原子性，需要在前面加上 lock 指令。

lock 指令可以保证一个 CPU 核心在操作期间独占一片内存区域。那么 这又是如何实现的呢？

在处理器中，一般有两种方式来实现上述效果：总线锁和缓存锁。在多核处理器的结构中，CPU 核心并不能直接访问内存，而是统一通过一条总线访问。

总线锁就是锁住这条总线，使其他核心无法访问内存。这种方式代价太大了，会导致其他核心停止工作。

缓存锁并不锁定总线，只是锁定某部分内存区域。当一个 CPU 核心将内存区域的数据读取到自己的缓存区后，它会锁定缓存对应的内存区域。锁住期间，其他核心无法操作这块内存区域。

CAS 就是通过这种方式实现比较和交换操作的原子性的。值得注意的是，CAS 只是保证了操作的原子性，并不保证变量的可见性，因此变量需要加上 volatile 关键字。

CAS 的问题

CAS的ABA问题

CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新。但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。这就是CAS的ABA问题。

常见的解决思路是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A-B-A 就会变成1A-2B-3A。

目前在JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

循环时间长开销大

如果CAS不成功，则会原地自旋，如果长时间自旋会给CPU带来非常大的执行开销。

解决方案：可以考虑限制自旋的次数，避免过度消耗 CPU；另外还可以考虑延迟执行。

只能保证单个变量的原子性

当对一个共享变量执行操作时，可以使用 CAS 来保证原子性，但是如果要对多个共享变量进行操作时，CAS 是无法保证原子性的，比如需要将 i 和 j 同时加 1：

i++;j++;

这个时候可以使用 synchronized 进行加锁，有没有其他办法呢？有，将多个变量操作合成一个变量操作。从 JDK1.5 开始提供了AtomicReference 类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。