🌲什么是 CAS
CAS: 全称Compare and swap，字面意思:”比较并交换“
这样解释还是很茫然，我们来看一下一个CAS 涉及到的操作就明白CAS是啥了
我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。
- 比较 A 与 V 是否相等。（比较）
- 如果比较相等，将 B 写入 V。（交换）
- 返回操作是否成功
意思就是我们现再假设有一个寄存器，里面存储的是A和B的值，我们这里为了后面方便叙述，我们另A= 1，B= 2；还有一个内存里面存储的是V的值，此处先假设V = 1
比较A与V的值，相等就将B与V的值进行交换
如果操作成功就会返回成功的操作
假设我们这里的V最开始：v = 2；
此时A与V值不相等，就会返回失败操作
🚩CAS伪代码
需要注意的是下面这段伪代码只是为了理解上面CAS的思想的，并不具有原子性。 真实的 CAS 是一个原子的硬件指令完成的. 这个伪代码只是辅助理解CAS 的工作流程.
boolean CAS(address, expectValue, swapValue) { if (&address == expectedValue) { &address = swapValue; return true; } return false; }
CAS就类似于我们之前讲的Synchronized关键字，都是将操作变为原子性，但是呢，CAS只适用于一些特殊场景，并不通用
CAS的好处：
- 当多个线程同时对某个资源进行CAS操作，只能有一个线程操作成功，但是并不会阻塞其他线程,其他线程只会收到操作失败的信号。
关于CAS是属于我们讲的那一种锁策略？
我们可以将CAS 视为是一种乐观锁. (或者可以理解成 CAS 是乐观锁的一种实现方式
🎋CAS 是怎么实现的
针对不同的操作系统，JVM 用到了不同的 CAS 实现原理，简单来讲：
- java 的 CAS 利用的的是 unsafe 这个类提供的 CAS 操作；
- unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg；
- Atomic::cmpxchg 的实现使用了汇编的 CAS 操作，并使用 cpu 硬件提供的 lock 机制保证其原子性。
简而言之，是因为硬件予以了支持，软件层面才能做到
🌳CAS的应用
🚩实现原子类
标准库中提供了 java.util.concurrent.atomic 包, 里面的类都是基于这种方式来实现的.
典型的就是 AtomicInteger 类.
里面提供了很多方法可以供操作
其中的 getAndIncrement 相当于 i++ 操作.
AtomicInteger atomicInteger = new AtomicInteger(0); // 相当于 i++ atomicInteger.getAndIncrement();
那这个方法是怎么实现CAS的呢？我们一起来看一下该类的伪代码
class AtomicInteger { private int value; public int getAndIncrement() { int oldValue = value; while ( CAS(value, oldValue, oldValue+1) != true) { oldValue = value; } return oldValue; } }
假设两个线程同时调用 getAndIncrement
- 两个线程都读取 value 的值到 oldValue 中. (oldValue 是一个局部变量, 在栈上每个线程有自己的栈)
- 线程1 先执行 CAS 操作. 由于 oldValue 和 value 的值相同, 直接进行对 value 赋值
注意:
- CAS 是直接读写内存的, 而不是操作寄存器.
- CAS 的读内存, 比较, 写内存操作是一条硬件指令, 是原子的.
- 线程2 再执行 CAS 操作, 第一次 CAS 的时候发现 oldValue 和 value 不相等, 不能进行赋值. 因此需要进入循环
在循环里重新读取 value 的值赋给 oldValue
- 线程2 接下来第二次执行 CAS, 此时 oldValue 和 value 相同, 于是直接执行赋值操作
- 线程1 和 线程2 返回各自的 oldValue 的值即可
代码示例如下：
import java.util.concurrent.atomic.AtomicInteger; public class ThreadDemo1 { public static void main(String[] args) throws InterruptedException { AtomicInteger atomicInteger = new AtomicInteger(0); Thread thread1 = new Thread(() -> { for(int i = 0; i < 100; i ++) { atomicInteger.getAndIncrement(); } }); Thread thread2 = new Thread(() -> { for(int i = 0; i < 100; i ++) { atomicInteger.getAndIncrement(); } }); thread2.start(); thread1.start(); thread1.join(); thread2.join(); System.out.println(atomicInteger); } }
结果展示：
通过形如上述代码就可以实现一个原子类. 不需要使用重量级锁, 就可以高效的完成多线程的自增操作.
🚩实现自旋锁
自旋锁是基于 CAS 实现更灵活的锁, 获取到更多的控制权.
自旋锁的伪代码如下：
public class SpinLock { private Thread owner = null; public void lock(){ // 通过 CAS 看当前锁是否被某个线程持有. // 如果这个锁已经被别的线程持有, 那么就自旋等待. // 如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程. while(!CAS(this.owner, null, Thread.currentThread())){ //一系列操作 } } public void unlock (){ this.owner = null; } }
利用上述伪代码的思想就可以实现一个自旋锁了
CAS操作虽然好用，但是也存在一些问题
🎄CAS 的 ABA 问题
🚩什么是 ABA 问题
ABA 的问题:
假设存在两个线程 t1 和 t2. 有一个共享变量 num, 初始值为 A.
接下来, 线程 t1 想使用 CAS 把 num 值改成 Z, 那么就需要
- 先读取 num 的值, 记录到 oldNum 变量中.
- 使用 CAS 判定当前 num 的值是否为 A, 如果为 A, 就修改成 Z.
但是, 在 t1 执行这两个操作之间, t2 线程可能把 num 的值从 A 改成了 B, 又从 B 改成了 A
- 线程 t1 的 CAS 是期望 num 不变就修改. 但是 num 的值已经被 t2 给改了. 只不过又改成 A 了. 这个时候 t1 究竟是否要更新 num 的值为 Z 呢?
到这一步, t1 线程无法区分当前这个变量始终是 A, 还是经历了一个变化过程
这就好比, 我们买一个手机, 无法判定这个手机是刚出厂的新手机, 还是别人用旧了, 又翻新过的手机
🚩ABA 问题引来的 BUG
大部分的情况下, t2 线程这样的一个反复横跳改动, 对于 t1 是否修改 num 是没有影响的. 但是不排除一些特殊情况
接下来我为大家举一个例子：
假设 春风老哥 有 100 存款. 春风想从 ATM 取 50 块钱. 取款机创建了两个线程, 并发的来执行 - 50操作.
- 我们期望一个线程执行 -50 成功,
- 另一个线程 -50 失败.
如果使用 CAS 的方式来完成这个扣款过程就可能出现问题
正常的过程
- 存款 100. 线程1 获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期望更新为 50.
- 线程1 执行扣款成功, 存款被改成 50. 线程2 阻塞等待中.
- 轮到线程2 执行了, 发现当前存款为 50, 和之前读到的 100 不相同, 执行失败
异常的过程
- 存款 100. 线程1 获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期望更新为 50.
- 线程1 执行扣款成功, 存款被改成 50. 线程2 阻塞等待中.
- 在线程2 执行之前, 春风的朋友正好给滑稽转账 50, 账户余额变成 100 !!
- 轮到线程2 执行了, 发现当前存款为 100, 和之前读到的 100 相同, 再次执行扣款操作
这个时候, 扣款操作被执行了两次!!! 都是 ABA 问题搞的鬼！！！
🚩解决方案
给要修改的值, 引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期.
CAS 操作在读取旧值的同时, 也要读取版本号.
真正修改的时候,
- 如果当前版本号和读到的版本号相同, 则修改数据, 并把版本号 + 1.
- 如果当前版本号高于读到的版本号. 就操作失败(认为数据已经被修改过了)
这就好比, 判定这个手机是否是翻新机, 那么就需要收集每个手机的数据, 第一次挂在电商网站上的手机记为版本1,以后每次这个手机出现在电商网站上, 就把版本号进行递增. 这样如果买家不在意这是翻新机, 就买. 如果买家在意, 就可以直接略过
我们再来利用版本号来解决一下春风老哥的问题
假设 春风老哥 有 100 存款. 春风想从 ATM 取 50 块钱. 取款机创建了两个线程, 并发的来执行 -50操作.
我们期望一个线程执行 -50 成功, 另一个线程 -50 失败.为了解决 ABA 问题, 给余额搭配一个版本号, 初始设为 1.
- 存款 100. 线程1 获取到 存款值为 100, 版本号为 1, 期望更新为 50; 线程2 获取到存款值为 100,版本号为 1, 期望更新为 50.
- 线程1 执行扣款成功, 存款被改成 50, 版本号改为2. 线程2 阻塞等待中.
- 在线程2 执行之前, 春风的朋友正好给春风转账 50, 账户余额变成 100, 版本号变成3.
- 轮到线程2 执行了, 发现当前存款为 100, 和之前读到的 100 相同, 但是当前版本号为 3, 之前读到的版本号为 1, 版本小于当前版本, 认为操作失败.
在 Java 标准库中提供了 AtomicStampedReference 类. 这个类可以对某个类进行包装, 在内部就提供了上面描述的版本管理功能.
关于 AtomicStampedReference 的具体用法此处不再展开. 有需要的同学自行查找Java文档了解使用方法即可
🍀CAS相关面试题
- 讲解下你自己理解的 CAS 机制
全称 Compare and swap, 即 “比较并交换”. 相当于通过一个原子的操作, 同时完成 “读取内存, 比 较是否相等,修改内存” 这三个步骤. 本质上需要 CPU 指令的支撑
- ABA问题怎么解决？
给要修改的数据引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期. 如果发现当前版本号和之前读到的版本号一致, 就真正执行修改操作, 并让版本号自增; 如果发现当 前版本号比之前读到的版本号大, 就认为操作失败
⭕总结
关于《【JavaEE初阶】 CAS详解》就讲解到这儿，感谢大家的支持，欢迎各位留言交流以及批评指正，如果文章对您有帮助或者觉得作者写的还不错可以点一下关注，点赞，收藏支持一下！
