赞
踩
CAS:全称Compare and swap,字面意思:“比较并交换”。一个 CAS 涉及到以下操作:
我们假设内存中的数据V,旧的预期值 (CPU寄存器A中的值)A,需要修改的新值 (CPU寄存器B中的值)B。
- 比较 A 与 V 是否相等(比较)
- 如果比较相等,将 B 写入 V(交换)
- 返回操作是否成功
CAS 伪代码:
下面写的代码不是原子的,真实的 CAS 是一个原子的硬件指令完成的,这个伪代码只是辅助理解 CAS 的工作流程~~
boolean CAS(address, expectValue, swapValue) {
if (&address == expectedValue) {
&address = swapValue;
return true;
}
return false;
}
这里的赋值其实是"交换",但是不关心寄存器B里是啥了,更关心内存中是啥!所以把交换近似看成赋值也没毛病~~
两种典型的不是 “原子性” 的代码:
- check and set (if 判定然后设定值) [上面的 CAS 伪代码就是这种形式]
- read and update (i++) [之前我们讲线程安全的代码例子是这种形式]
当多个线程同时对某个资源进行CAS操作,只能有一个线程操作成功,但是并不会阻塞其他线程,其他线程只会收到操作失败的信号~~
CAS 可以视为是一种乐观锁 (或者可以理解成 CAS 是乐观锁的一种实现方式)
因为CAS是一个原子的硬件指令完成的,所以是线程安全的,同时还高效 (不涉及到锁冲突,线程等待)!!!
咱们基于CAS就可以有很多新的玩法,即实现一些逻辑的时候,不加锁也能保证线程安全~~
CAS确实看起来比加锁更好,但是CAS只是在特定场景能用,而加锁适用面更广,并且加锁代码往往比CAS可读性更好!
针对不同的操作系统,JVM 用到了不同的 CAS 实现原理,简单来讲:
简而言之,是因为硬件予以了支持,软件层面才能做到。
标准库中提供了 java.util.concurrent.atomic 包,里面的类都是基于这种方式来实现的。
典型的就是 AtomicInteger 类,其中的 getAndIncrement 相当于 i++ 操作~
ABA的问题:
假设存在两个线程 t1 和 t2,有一个共享变量 num,初始值为 A。
接下来,线程 t1 想使用 CAS 把 num 值改成 Z,那么就需要:
但是,在 t1 执行这两个操作之间,t2 线程可能把 num 的值从 A 改成了 B,又从 B 改成了 A!
线程 t1 的 CAS 是期望 num 不变就修改,但是 num 的值已经被 t2 给改了,只不过又改成 A 了,这个时候 t1 究竟是否要更新 num 的值为 Z 呢?
到这一步,t1 线程无法区分当前这个变量始终是 A,还是经历了一个变化过程:
这就好比,我们买一个手机,无法判定这个手机是刚出厂的新手机,还是别人用旧了,又翻新过的手机。
大部分情况下,t2 线程这样的一个反复横跳改动,对于 t1 是否修改 num 是没有影响的,但是不排除一些特殊情况!:
给要修改的值引入版本号 (或上次修改时间),在CAS比较数据当前值和旧值的同时,也要比较版本号是否符合预期。
这就好比,判定这个手机是否是翻新机,那么就需要收集每个手机的数据,第一次挂在电商网站上的手机记为版本1,以后每次这个手机出现在电商网站上,就把版本号进行递增。这样如果买家不在意这是翻新机,就买;如果买家在意,就可以直接略过~~
在Java标准库中提供了 AtomicStampedReference 类,这个类可以对某个类进行包装,在内部就提供了上面描述的版本管理功能!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。