目录
什么是 CAS
CAS 伪代码
CAS 是怎么实现的
CAS 有哪些应用
实现原子类
伪代码实现:
实现自旋锁
自旋锁伪代码
CAS 的 ABA 问题
什么是 ABA 问题
ABA 问题引来的 BUG
CAS相关面试题
什么是 CAS
CAS:
全称
Compare and swap
，字面意思
:”
比较并交换
“
，一个
CAS
涉及到以下操作:
我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。
1. 比较 A 与 V 是否相等。（比较） 2. 如果比较相等，将 B 写入 V。（交换） 3. 返回操作是否成功。
CAS 比较交换的是 内存 和 寄存器。比如有一个内存M，现在有俩个寄存器A，B.
CAS(M,A,B）如果M和A的值相同的话，就把M和B的值交换，同时整个操作返回true.
如果M和A的值不同的话，无事发生，同时整个操作返回false.
CAS 伪代码
伪代码 ，代码是不能真正编译执行（不符合语法要求) 认识到逻辑是啥样的。
下面写的代码不是原子的, 真实的 CAS 是一个原子的硬件指令完成的. 这个伪代码只是辅助理解
CAS 的工作流程.
boolean CAS(address, expectValue, swapValue) {
if (&address == expectedValue) {
&address = swapValue;
return true;
}
return false;
}
两种典型的不是 "原子性" 的代码
1. check and set (if 判定然后设定值) [上面的 CAS 伪代码就是这种形式] 2. read and update (i++) [之前我们讲线程安全的代码例子是这种形式]
当多个线程同时对某个资源进行
CAS
操作，只能有一个线程操作成功，但是并不会阻塞其他线程
,
其他线程只会收到操作失败的信号。
CAS 可以视为是一种乐观锁. (或者可以理解成 CAS 是乐观锁的一种实现方式)
CAS其实是一个cpu指令（一个cpu指令，就能完成上述比较交换的逻辑）单个cpu指令，是原子的！就可以使用CAS完成一些操作，进一步的替代"加锁"。——这样就给编写线程安全的代码，引入了新的思路。
基于CAS实现线程安全的方式，也称为"无锁编程",
优点：保证线程安全，同时避免阻塞(效率）缺点：代码会更复杂，不好理解，只能够适合一些特定的场景，不如加锁方式更普实。
CAS 是怎么实现的
CAS本质上是cpu提供的指令——》又被操作系统封装，提供成api，然后又被JVM，也提供成api——》程序员就可以使用了。
针对不同的操作系统，
JVM
用到了不同的
CAS
实现原理，简单来讲：
java 的 CAS 利用的的是 unsafe 这个类提供的 CAS 操作； unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg； Atomic::cmpxchg 的实现使用了汇编的 CAS 操作，并使用 cpu 硬件提供的 lock 机制保证其原子性。
简而言之，是因为
硬件予以了支持，软件层面才能做到。
等到后面会更加能理解。
CAS 有哪些应用
实现原子类
int 进行++，不是原子的（load，add，save)三步骤。
AtomicInteger,基于CAS的方式对int进行封装，此时进行++，就是原子的了。（++操作是基于CAS指令实现的）
标准库中提供了 java.util.concurrent.atomic 包, 里面的类都是基于这种方式来实现的.
典型的就是 AtomicInteger 类. 其中的 getAndIncrement 相当于 i++ 操作.
在java中，有些操作是偏底层的操作，偏底层的操作在使用的时候有更多的注意事项，稍有不慎就容易写出问题。这些操作，就会放到unsafe中进行归类。
unsafe代表有更多的注意事项，稍有不慎就写错。（就比如在导航的时候，遇到事故多发地方就会提醒警告信息）
我们看到原子类内部没有使用synchronized加锁使用。
native是本地方法，compareAndSwapInt比较和交换，JVM源码中，使用c++实现逻辑，底层的操作。
从上面流程我们可以看到，CAS中cpu指令 ，先是通过系统进行封装，提供了api(getAndSetInt),然后JVM进行封装提供api（compareAndSwapInt）。而原子类是基于CAS实现的。
原子类里面基于CAS实现的。 通过利用指令原子性逻辑获取锁实现原子性操作。
伪代码实现:
class AtomicInteger {
private int value;
public int getAndIncrement() {
int oldValue = value;
while ( CAS(value, oldValue, oldValue+1) != true) {
oldValue = value;
}
return oldValue;
}
}
初始情况下，value的值是0，俩次自增结果是2.
如果俩者相等，就返回true,并且让oldValue+1赋值给value，让value+1，如果不相等就得让value赋值给oldvalue，然后进行++操作。
所以我们之前所说的”线程不安全“本质上是进行自增的过程中，穿插执行了。
CAS也是让这里的自增，不要穿插执行，核心思路和加锁是类似的，加锁是通过阻塞的方式，避免穿插，CAS则是会通过重试的方式，避免穿插。
实现自旋锁
基于
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;
}
}
记录当前这个锁被哪个线程获取到了，如果是null，表示未加锁状态。
CAS 的 ABA 问题
什么是 ABA 问题
ABA
的关键问题
: 是通过值"没有发生改变"来作为”没有其他线程穿插执行“判定依据。
但是这种判定方式不够严谨，更极端的情况下，可能有另一个线程穿插进来，把值从A->B->A,针对第一个线程来说，看起来好像是这个值，没变，实际上已经被穿插执行了。
比如，买个手机，买到的是一个”二手的，翻新的设备“。翻新机，也不是不能用，里面可能会有一些暗伤。
ABA问题如果真的出现了，其实大部分情况下是不会产生bug的，就相当于买到二手设备，也是能用的，虽然另一个线程穿插执行了，由于值又改回来了，此时逻辑上也不一定会产生bug。
ABA 问题引来的 BUG
假设这个场景，我去ATM取钱，我本身的账户1000，我想要取500，我再取钱的过程中，出现bug了，我按下取钱按钮的时候，没反应，又按了一下，此时就产生了俩个线程进行扣款操作。
由于t3线程正好又在这个节骨眼上转来了500，与时我的余额又是1000了，就会导致t1线程也能扣款。此时我预期取500，实际上扣了1000.
大部分情况下ABA问题其实没啥大事，但是有一些极端情况，会使ABA出现bug，只要让判定的数值，按照一个方向增长即可。有增有减，就可能出现ABA，只是增加，或者只是减少，针对像账户余额这样概念，本身就应该要能增有减，可以引入一个额外的变量，版本号，约定每次修改余额就让版本号自增，此时在使用CAS判定的时候，就不是直接判定余额了，而是判定版本号，看版本号是否是变化了，如果版本号不变，注定没有线程穿插了执行。
相关面试题
1) 讲解下你自己理解的 CAS 机制
compareAndSwap 比较并且交换，相当于一个原子操作，同时完成
， "读取内存, 比
较是否相等, 修改内存" 这三个步骤. 本质上需要 CPU 指令的支撑。通过利用指令的原子性从而避免获取锁实现了原子性操作。
2) ABA问题怎么解决？
给要修改的变量添加一个版本号，在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期.如果发现当前版本号和之前读到的版本号一致, 就真正执行修改操作, 并让版本号自增; 如果发现当前版本号比之前读到的版本号大, 就认为操作失败
难道父母眼里只有学习学习嘛？？
推荐文章
您阅读本篇文章共花了：
发表评论