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 的工作流程.
boolean CAS(address, expectValue, swapValue) {
if (&address == expectedValue) {
&address = swapValue;
return true;
}
return false;
}
CAS就类似于我们之前讲的Synchronized关键字,都是将操作变为原子性,但是呢,CAS只适用于一些特殊场景,并不通用
CAS的好处:
关于CAS是属于我们讲的那一种锁策略?
我们可以将CAS 视为是一种乐观锁. (或者可以理解成 CAS 是乐观锁的一种实现方式
针对不同的操作系统,JVM 用到了不同的 CAS 实现原理,简单来讲:
java 的 CAS 利用的的是 unsafe 这个类提供的 CAS 操作;
unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg;
Atomic::cmpxchg 的实现使用了汇编的 CAS 操作,并使用 cpu 硬件提供的 lock 机制保证其原子性。
简而言之,是因为硬件予以了支持,软件层面才能做到
标准库中提供了 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
注意:
- CAS 是直接读写内存的, 而不是操作寄存器.
- CAS 的读内存, 比较, 写内存操作是一条硬件指令, 是原子的.
代码示例如下:
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操作虽然好用,但是也存在一些问题
ABA 的问题:
假设存在两个线程 t1 和 t2. 有一个共享变量 num, 初始值为 A.
接下来, 线程 t1 想使用 CAS 把 num 值改成 Z, 那么就需要
先读取 num 的值, 记录到 oldNum 变量中.
使用 CAS 判定当前 num 的值是否为 A, 如果为 A, 就修改成 Z.
但是, 在 t1 执行这两个操作之间, t2 线程可能把 num 的值从 A 改成了 B, 又从 B 改成了 A
到这一步, t1 线程无法区分当前这个变量始终是 A, 还是经历了一个变化过程
这就好比, 我们买一个手机, 无法判定这个手机是刚出厂的新手机, 还是别人用旧了, 又翻新过的手机
大部分的情况下, t2 线程这样的一个反复横跳改动, 对于 t1 是否修改 num 是没有影响的. 但是不排除一些特殊情况
接下来我为大家举一个例子:
假设 春风老哥 有 100 存款. 春风想从 ATM 取 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文档了解使用方法即可
全称 Compare and swap, 即 “比较并交换”. 相当于通过一个原子的操作, 同时完成 “读取内存, 比 较是否相等,修改内存” 这三个步骤. 本质上需要 CPU 指令的支撑
给要修改的数据引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期. 如果发现当前版本号和之前读到的版本号一致, 就真正执行修改操作, 并让版本号自增; 如果发现当 前版本号比之前读到的版本号大, 就认为操作失败
关于《【JavaEE初阶】 CAS详解》就讲解到这儿,感谢大家的支持,欢迎各位留言交流以及批评指正,如果文章对您有帮助或者觉得作者写的还不错可以点一下关注,点赞,收藏支持一下!