◆
CAS的概念
◆
对于并发控制来说,使用锁是一种悲观的策略。它总是假设每次请求都会产生冲突,如果多个线程请求同一个资源,则使用锁宁可牺牲性能也要保证线程安全。而无锁则是比较乐观的看待这个问题,它会假设每次访问都没有冲突,这样就提高了效率。但是事实难料、这个冲突是避免不了的,无锁也考虑到了肯定会遇到冲突,对于冲突的解决无锁就使用一种比较交换(CAS)的技术来检测冲突。一旦检测到冲突就重试当前操作直到成功为止。
◆
CAS算法
◆
CAS机制中使用了3个基本操作数CAS(V,E,N):V表示要更新的变量,E表示预期值,N表示新值。
CAS更新一个变量的时候,只有当变量的预期值E和要更新的变量V的实际值相同时,才会将V的值修改为N。
一个简单的例子:
◆
Java中CAS的底层实现
◆
我们看一下AtomicInteger当中常用的自增方法incrementAndGet:
public final int incrementAndGet() { return unsafe.getAndAddInt(this, valueOffset, 1) + 1; }
这里涉及到两个重要的对象,一个是unsafe,一个是valueOffset。
unsafe是什么东西呢?它JVM为我们提供了一个访问操作系统的后门,unsafe为我们提供了硬件级别的原子操作。而valueOffset对象,是通过unsafe.objectFiledOffset方法得到,所代表的是AtomicInteger对象value成员变量在内存中的偏移量。我们可以简单的把valueOffset理解为value变量的内存地址。
而unsafe的getAndAddInt方法顾名思义就是使用操作系统的原子操作来为我们实现当前的的++操作并把旧值返回回来。因为是返回的旧值所以
incrementAndGet方法返回的数据应该是这个旧值加上1
◆
CAS的缺点
◆
CPU开销过大
在并发量比较高的情况下,如果许多线程反复尝试更新某一个变量,却又一直更新不成功,循环往复,会给CPU带来很到的压力。
不能保证代码块的原子性
CAS机制所保证的知识一个变量的原子性操作,而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新,就不得不使用synchronized了。
ABA问题
这是CAS机制最大的问题所在。
我们现在来说什么是ABA问题。
假设小王账户有1000块钱,即v=1000。
这时有三个线程想使用CAS的方式更新这个小王的账户。线程1和线程2已经获取当前账户余额为1000,线程3还未获取当前值。
线程1为花呗扣款、线程2为花呗扣款的备用操作(避免第一次扣款失败),线程3为工资入账
接下来,线程1先一步执行成功,把当前账户成功从1000减少到500;同时线程2因为某种原因被阻塞住,没有及时扣款;线程3在线程1扣款之后,获取了当前值500。
在之后,线程2仍然处于阻塞状态,线程3继续执行,成功入账工资500,把当前值又变回了1000。
此时,线程2恢复运行状态,进行更新之前查询E和V相同,所以毫不犹豫的进行又一次账户扣款。
这种扣款的方式对于小王来说肯定是不可接受的(估计都要疯了),解决方案就是在操作的时候加个版本号或者是时间戳来标示状态信息。
同样以刚才的例子来说:
假设小王账户有1000块钱,即v=1000。
这时有三个线程想使用CAS的方式更新这个小王的账户。线程1和线程2已经获取当前账户余额为1000,线程3还未获取当前值。但是呢,这里线程1和2还需要记录一个获取当前账户余额的最后更新时间,比如9.30.
同样的线程1为花呗扣款、线程2为花呗扣款的备用操作(避免第一次扣款失败),线程3为工资入账。
接下来,线程1先一步执行成功,把当前账户成功从1000减少到500;此时账户余额的时间戳就已经变了,比如9.31。同时线程2因为某种原因被阻塞住,没有及时扣款;线程3在线程1扣款之后,获取了当前值500和时间戳9.31。
在之后,线程2仍然处于阻塞状态,线程3继续执行,成功入账工资500,把账户又变回了1000,同时时间戳更新为9.32。
此时,线程2恢复运行状态,进行更新之前查询E和V虽然相同,但是时间戳确是不一样的。
◆
Java提供的12种原子操作类
◆
原子更新基本类型
原子更新数组
原子更新引用类型
原子更新字段