Java多线程中画图带你理解CAS和ABA问题

一、CAS问题

1、什么是CAS

• CAS是英文单词Compare And Swap的缩写，翻译过来就是比较并替换。

CAS 算法它包含3 个参数:CAS(V,A,B)
①V表示要更新的变量(内存值)
②A表示预期值(旧的)
③B表示要修改的新值

• 当且仅当V等于于A值时，才会将V的值设为B
• 如果V 值和A值不同，则说明已经有其他线程做了更新，则当前线程什么都不做。最后，CAS 返回当前V 的真实值。
• CAS 操作是抱着乐观的态度进行的(乐观锁)，并且是一个原子的操作它总是认为自己可以成功完成操作。当多个线程同时使用CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败。失败的线程不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。基于这样的原理，CAS 操作即使没有锁，也可以发现其他线程对当前线程的干扰，并进行恰当的处理。

2、为什么会有CAS机制的出现

• 在JDK 5之前Java语言是靠synchronized关键字保证同步的，这会导致有锁
  锁机制存在以下问题：
  （1）在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。
  （2）一个线程持有锁会导致其它所有需要此锁的线程挂起。而synchronized是一种悲观锁，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。如果全部使用悲观锁，在高并发的环境下必定是非常浪费时间和CPU、内存资源

volatile是不错的机制，但是volatile不能保证原子性。因此对于同步最终还是要回到锁机制上来。

此时解决的方案就是乐观锁策略。所谓乐观锁就是，每次不加锁而是假设没有冲突去完成某项操作，如果因为冲突失败就重试，直到成功为止。

3、CAS执行后的结果

• 如果内存值V和我们的预期值A相等，则将内存值修改为B，操作成功！
• 如果内存值V和我们的预期值A不相等，⼀般也有两种情况：

①重试(⾃旋)
举个例子并且画图，来展示如何进行重试的。

• 此刻有100个线程，对count值进⾏加1。 如果在线程安全的情况下，这个count值最终的结果⼀定是为100的。那就意味着：每个线程都会对这个count值实质地进⾏加1。
  ②什么都不做
• 例子：两个线程，都想将count的值设置为5

二、ABA问题

1、什么是ABA

它是由CAS操作导致的第一个问题，因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。

• 现在我有⼀个变量count=10 ，现在有三个线程，分别为A、B、C
• 线程A和线程C同时读到count变量，所以线程A和线程C的内存值和预期值都为10
• 此时线程A使⽤CAS将count值修改成100
• 修改完后，就在这时，线程B进来了，读取得到count的值为100(内存值和预期值都是100)，将count值修改成10
• 线程C拿到执⾏权，发现内存值是10，预期值也是10，将count值修改成11

上⾯的操作都可以正常执⾏完的，这样会发⽣什么问题呢？？?线程C⽆法得知线程A和线程B修改过的count值，这样是有⻛险的。

• 以链表的删除为例子说明风险

2、如何解决ABA问题

• 在变量前面追加版本号：每次变量更新就把版本号加1，则A-B-A就变成1A-2B-3A。就像白雪公主吃苹果前，先看下苹果上有没有指纹，也就相当于是查看苹果版本号，来确定有没有被换过
• atomic包下的AtomicStampedReference类：其compareAndSet方法首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用的该标志的值设置为给定的更新值。

三、CAS导致的其他问题

1、只能保证一个共享变量的原子操作

• 当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，可以把多个变量放在一个对象里来进行CAS操作。

2、循环时间长开销大

• 自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。