共计 3455 个字符，预计需要花费 9 分钟才能阅读完成。
前言
-
CAS 的全称是 Compare-And-Swap，它是CPU 并发原语
原语属于操作系统用于领域，是由若干条指令组成，用于实现某个性能的一个过程，并且原语的执行必须是间断的，在执行过程中 不容许被中断（保障原子性）
- 它的性能是判断内存某个地位的值 是否为预期值，如果是则更改为新的值，这个过程是原子的，也就是说 CAS 是线程平安的。
代码应用
public class Test {public static void main(String[] args) {
// 创立一个原子类，初始化为 5
AtomicInteger atomicInteger = new AtomicInteger(5);
// 调用 CAS 办法，试图更新为 2020，这里有两个参数，5 示意期望值，第二个是咱们要更新的值
atomicInteger.compareAndSet(5, 2020);
System.out.println("第一次调用 CAS 办法，数值为：" + atomicInteger);
// 而后再次应用一个办法，将值改成 1024
atomicInteger.compareAndSet(5, 1024);
System.out.println("第二次调用 CAS 办法，数值为：" + atomicInteger);
}
}下面代码的执行后果为
这是因为咱们执行第一个的时候，期望值和本来值是满足的，因而批改胜利，然而第二次后，主内存的值曾经批改成了 2020，不满足期望值，因而写入失败。
CAS 底层原理（对 Unsafe 的了解）
CAS 咱们围绕着 AtomicInteger 类来理解，首先先看看 atomicInteger.getAndIncrement() 办法的源码（实现 n ++ 的办法）
从这里可能看到，底层又调用了一个 unsafe 类的 getAndAddInt 办法
1、unsafe 类
- Unsafe 是 CAS 的外围类，因为 Java 办法无奈间接拜访底层零碎，须要通过本地（native）办法来拜访，Unsafe 相当于一个后门，基于该类能够间接操作特定内存的数据。Unsafe 类存在于
sun.misc包中，其外部办法操作能够像 C 的指针一样间接操作内存。 - Unsafe 类中的所有办法都是 native 润饰的，也就是说 Unsafe 类中的办法都间接调用操作系统底层资源执行相应工作。
- 为什么 Atomic 润饰的包装类，可能保障原子性，依附的就是底层的 unsafe 类
2、变量 valueOffset
getAndAddInt办法中，valueOffset示意该变量在内存中的偏移地址，因为 Unsafe 就是依据内存偏移地址获取数据的。
内存偏移量就像是 c 的指针，我不晓得你，然而我晓得你的坐标地址，我就能操作你
public final int getAndIncrement() {return unsafe.getAndAddInt(this, valueOffset, 1);
}
/*
this（以后对象），valueOffset（内存偏移量，也就是内存地址）从这里咱们可能看到，通过 valueOffset，间接通过内存地址，获取到值，而后进行加 1 的操作
*/3、变量 value 用 volatile 润饰
保障了多线程之间的内存可见性。能使得 CAS 自旋中，能够及时晓得内存的值有没有扭转。
getAndAddInt 办法的源码如下图：
var5 就是线程从主内存中拷贝到工作内存的值。那么 CAS 操作的时候，须要比拟工作内存中的值，和主内存中的值进行比拟。假如执行 compareAndSwapInt 返回 false，那么就始终执行 while 办法，直到冀望的值和实在值一样。
- var1：AtomicInteger 对象自身
- var2：该对象值的援用地址
- var4：须要变动的数量
-
var5：用 var1 和 var2 找到的内存中的实在值
- 用该对象以后的值与 var5 比拟
- 如果雷同，更新 var5 + var4 并返回 true
- 如果不同，持续取值而后再比拟，直到更新实现
这就是 CAS 的实现机制了！！！
- 为什么 AtomicInteger 用 CAS 而不是用 synchronized？
synchronized 上锁缩小了并发性，而 CAS 思维没有上锁，而是用 do while 循环反复用 CAS 比拟，直到比拟胜利为止，这样即保障了一致性，又进步了并发性。
总结
CAS（CompareAndSwap）
比拟当前工作内存中的值和主内存中的值，如果雷同则执行规定操作，否则持续比拟直到主内存和工作内存中的值统一为止。
CAS 利用
CAS 有 3 个操作数，内存值 V，旧的预期值 A，要批改的更新值 B。
当且仅当预期值 A 和内存值 V 雷同时，将内存值 V 批改为 B，否则什么都不做。
CAS 毛病
CAS 不加锁，保障一次性，然而须要 屡次比拟。
- 循环工夫长，开销大（因为执行的是 do while，如果比拟不胜利始终在循环，最差的状况，就是某个线程始终取到的值和预期值都不一样，这样就会有限循环）
-
只能保障一个共享变量的原子操作
- 当对一个共享变量执行操作时，咱们能够通过循环 CAS 的形式来保障原子操作
- 然而对于多个共享变量操作时，循环 CAS 就无奈保障操作的原子性，这个时候只能用锁来保障原子性
- ABA 问题？
前言：
从 AtomicInteger 引出上面的问题
CAS -> Unsafe -> CAS 底层思维 -> ABA -> 原子援用更新 -> 如何躲避 ABA 问题
ABA 问题
一句话概括就是：狸猫换太子。
CAS 只管结尾和结尾，也就是头和尾是一样，那就批改胜利，两头的这个过程，可能会被人批改过。只管 CAS 操作胜利，然而不代表这个过程是没问题的。
原子援用
原子援用其实和原子包装类是差不多的概念，就是将一个 java 类用原子援用类进行包装起来，那么这个类就具备了 原子性。
public class User {
String name;
int age;
public User(String name, int age) {
this.age = age;
this.name = name;
}
//getter，setter 办法 + toString 办法
public static void main(String[] args) {User u1 = new User("yuanqi", 18);
User u2 = new User("xiaoen", 19);
// 创立原子援用包装类
AtomicReference<User> atomicReference = new AtomicReference<>();
// 设置当初主物理内存的共享变量为 u1
atomicReference.set(u1);
// CAS，如果当初主物理内存的值为 u1，那么替换为 u2
atomicReference.compareAndSet(u1, u2);
// CAS，当初主物理内存的值曾经被批改成 u2 了，因而替换失败
atomicReference.compareAndSet(u1, u2);
}
}基于原子援用的 ABA 问题
public static void main(String[] args) {
// 创立原子援用包装类。类型为 Integer，初始值 100
AtomicReference<Integer> atomicReference = new AtomicReference<>(100);
new Thread(() -> {
// 把 100 改为 101，再改为 100，也就是 ABA 问题
atomicReference.compareAndSet(100, 101);
atomicReference.compareAndSet(101, 100);
}, "线程 A").start();
new Thread(() -> {
// 睡眠 1s，保障 A 线程实现 ABA 操作。try {TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {e.printStackTrace();
}
// 测试曾经狸猫换天子的 100，是否被扭转
atomicReference.compareAndSet(100, 666);
System.out.println("atomicReference 的值为：" + atomicReference);
}, "线程 B").start();}咱们发现，它可能胜利的批改，这就是 ABA 问题。
解决 ABA 问题
AtomicStampedReference 类
新增一种机制，也就是批改 版本号，相似于工夫戳的概念
AtomicMarkableReference 类
它不是保护一个版本号，而是保护一个boolean 类型的标记，用法没有 AtomicStampedReference 灵便。因而也只是在特定的场景下应用。