【JavaEE】多线程CAS中的aba问题是什么？

你的名字 2024-03-23 12:36 61阅读 0赞

![05220197f96e43bd831fb30f8171aacf.gif][]

>  *  **博主简介：想进大厂的打工人**
>  *  **博主主页：**[@xyk:][xyk]
>  *  **所属专栏: [JavaEE初阶][JavaEE]**

什么是CAS问题？CAS: 全称Compare and swap，字面意思:”比较并交换“，CAS中的aba问题是什么？请看本文讲解~~

##  ##

--------------------

**目录**

文章目录

一、CAS是什么？

二、CAS是怎么实现的？

三、CAS有哪些应用

3.1 实现原子类

3.2实现自旋锁

四、CAS的aba问题

4.1什么是aba问题？

4.2 aba问题带来的bug

五、相关面试题

5.1 讲解下你自己理解的 CAS 机制

5.2 ABA问题怎么解决？

--------------------

**一、CAS是什么？**

CAS: 全称Compare and swap，字面意思:”比较并交换“，寄存器A的值和内存M的值进行对比，如果值相同，就把寄存器B的值和M的值进行交换~~一个 CAS 涉及到以下操作：

> 我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。  
> 1. 比较 A 与 V 是否相等。（比较）  
> 2. 如果比较相等，将 B 写入 V。（交换）  
> 3. 返回操作是否成功。

CAS伪代码

> 下面写的代码不是原子的, 真实的 CAS 是一个原子的硬件指令完成的. 这个伪代码只是辅助理解CAS 的工作流程

boolean CAS(address, expectValue, swapValue) {
    if (&address == expectedValue) {
    &address = swapValue;
    return true;
    }
    return false;
    }

![40868fd0e76d43ee8f1c92e09a23535e.png][]

关键的是，CAS操作，是一条CPU指令(原子的)！！并非是上述这一段代码，这一条指令就能完成上述这一段代码的功能~~

两种典型的不是 "原子性" 的代码  
1. check and set (if 判定然后设定值) \[上面的 CAS 伪代码就是这种形式\]  
2. read and update (i++) \[之前我们讲线程安全的代码例子是这种形式\]

当多个线程同时对某个资源进行CAS操作，只能有一个线程操作成功，但是并不会阻塞其他线程,其他线程只会收到操作失败的信号  
CAS 可以视为是一种乐观锁. (或者可以理解成 CAS 是乐观锁的一种实现方式)

## 二、CAS是怎么实现的？ ##

针对不同的操作系统，JVM 用到了不同的 CAS 实现原理，简单来讲：

> java 的 CAS 利用的的是 unsafe 这个类提供的 CAS 操作；  
> unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg；  
> Atomic::cmpxchg 的实现使用了汇编的 CAS 操作，并使用 cpu 硬件提供的 lock 机制保证其原子性。  
> 简而言之，是因为硬件予以了支持，软件层面才能做到。

## 三、CAS有哪些应用 ##

### 3.1 实现原子类 ###

标准库中提供了 java.util.concurrent.atomic 包, 里面的类都是基于这种方式来实现的。  
典型的就是 **AtomicInteger 类**. 其中的 getAndIncrement 相当于 i++ 操作

**AtomicInteger 类能够保证++ -- 的时候线程安全，并非是加锁**  
![386f8b92e70c4bbd9e361ae36476c4e0.png][]

AtomicInteger atomicInteger = new AtomicInteger(0);
    // 相当于 i++
    atomicInteger.getAndIncrement();

###  ###

伪代码实现:

class AtomicInteger {
        private int value;
        public int getAndIncrement() {
            int oldValue = value;
            while ( CAS(value, oldValue, oldValue+1) != true) {
                   oldValue = value;
            }
            return oldValue;
        }
    }

假设两个线程同时调用 getAndIncrement  
1) 两个线程都读取 value 的值到 oldValue 中. (oldValue 是一个局部变量, 在栈上. 每个线程有自己的栈)  
![88c868f1558f4cc6a44cd37840bd5b46.png][]

2) 线程1 先执行 CAS 操作. 由于 oldValue 和 value 的值相同, 直接进行对 value 赋值

> 注意:  
> CAS 是直接读写内存的, 而不是操作寄存器.  
> CAS 的读内存, 比较, 写内存操作是一条硬件指令, 是原子的.

![4a37cebee8be448ba202e1e93303f0ae.png][]

3) 线程2 再执行 CAS 操作, 第一次 CAS 的时候发现 oldValue 和 value 不相等, 不能进行赋值. 因此需要进入循环.  
在循环里重新读取 value 的值赋给 oldValue

![0cdb13ef65534f248ceb3144daf3c843.png][]

4) 线程2 接下来第二次执行 CAS, 此时 oldValue 和 value 相同, 于是直接执行赋值操作.

![6046a9665ab842f7be2ba776d9cc2bf1.png][]

5) 线程1 和 线程2 返回各自的 oldValue 的值即可.

通过形如上述代码就可以实现一个原子类. 不需要使用重量级锁, 就可以高效的完成多线程的自增操作.  
本来 check and set 这样的操作在代码角度不是原子的. 但是在硬件层面上可以让一条指令完成这  
个操作, 也就变成原子的了.

CAS本身对应一条CPU指令（不可拆分的最小单位了）

### 3.2实现自旋锁 ###

反复检查当前的锁状态，看是否解开了~~

基于 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;
        }
    }

![42a572c9b8ab4de29d1c88844e4823cb.png][]

如果当前owner是null，比较就成功，就把当前线程的引用设置到owner中，加锁完成！！循环结束

比较不成功~，意味着owner非空，锁已经有线程持有了~~此时CAS就啥也不干，直接返回false，循环继续进行~~

此时这个循环就会转的飞快，不停的尝试询问这里的锁是不是释放！！

**好处，一旦锁释放，就立即能获取到！！**

**坏处，cpu忙等~~**

一般乐观锁，这个情况下（锁冲突概率低）实现成自旋锁比较合适的~~

## 四、CAS的aba问题 ##

#### 4.1什么是aba问题？ ####

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, 还是经历了一个变化过程  
![fb74462b8f714384accae8985fa27ac0.png][]

这就好比, 我们买一个手机, 无法判定这个手机是刚出厂的新手机, 还是别人用旧了, 又翻新过的手  
机。

那么如何去解决这个问题呢？？aba的关键是值会反复横跳~~**如果约定数据只能单方向变化，问题就迎刃而解了（只能增加，或者只能减小）**

如果需求要求该数值，既能增加也能减小，应该怎么办？可以引入另外一个版本号变量，约定版本号只能增加~~

**每次CAS对比的时候，就不是对比数值本身，而是对比版本号！！**

#### 4.2 aba问题带来的bug ####

大部分的情况下, t2 线程这样的一个反复横跳改动, 对于 t1 是否修改 num 是没有影响的. 但是不排除一些特殊情况

> 假设 滑稽老哥 有 100 存款. 滑稽想从 ATM 取 50 块钱. 取款机创建了两个线程, 并发的来执行 -50操作.  
> 我们期望一个线程执行 -50 成功, 另一个线程 -50 失败.  
> 如果使用 CAS 的方式来完成这个扣款过程就可能出现问题.  
> 正常的过程  
> 1) 存款 100. 线程1 获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期望更新为 50.  
> 2) 线程1 执行扣款成功, 存款被改成 50. 线程2 阻塞等待中.  
> 3) 轮到线程2 执行了, 发现当前存款为 50, 和之前读到的 100 不相同, 执行失败.
> 
> 异常的过程  
> 1) 存款 100. 线程1 获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期望更新为 50.  
> 2) 线程1 执行扣款成功, 存款被改成 50. 线程2 阻塞等待中.  
> 3) 在线程2 执行之前, 滑稽的朋友正好给滑稽转账 50, 账户余额变成 100 ！！  
> 4) 轮到线程2 执行了, 发现当前存款为 100, 和之前读到的 100 相同, 再次执行扣款操作  
> 这个时候, 扣款操作被执行了两次!!! 都是 ABA 问题搞的鬼！！

**解决方案：**

给要修改的值,**引入版本号****.** 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期.  
CAS 操作在读取旧值的同时, 也要读取版本号.  
真正修改的时候,  
如果当前版本号和读到的版本号相同, 则修改数据, 并把版本号 + 1.  
如果当前版本号高于读到的版本号. 就操作失败(认为数据已经被修改过了)

> 这就好比, 判定这个手机是否是翻新机, 那么就需要收集每个手机的数据, 第一次挂在电商网站上的手机记为版本1, 以后每次这个手机出现在电商网站上, 就把版本号进行递增. 这样如果买家不在意这是翻新机, 就买. 如果买家在意, 就可以直接略过.

对比立即上面的转账例子：

> 假设 滑稽老哥 有 100 存款. 滑稽想从 ATM 取 50 块钱. 取款机创建了两个线程, 并发的来执行 -50操作.  
> 我们期望一个线程执行 -50 成功, 另一个线程 -50 失败.  
> 为了解决 ABA 问题, 给余额搭配一个版本号, 初始设为 1.  
> 1) 存款 100. 线程1 获取到 存款值为 100, 版本号为 1, 期望更新为 50; 线程2 获取到存款值为 100,版本号为 1, 期望更新为 50.  
> 2) 线程1 执行扣款成功, 存款被改成 50, 版本号改为2. 线程2 阻塞等待中.  
> 3) 在线程2 执行之前, 滑稽的朋友正好给滑稽转账 50, 账户余额变成 100, 版本号变成3.  
> 4) 轮到线程2 执行了, 发现当前存款为 100, 和之前读到的 100 相同, 但是当前版本号为 3, 之前读到的版本号为 1, 版本小于当前版本, 认为操作失败

## 五、相关面试题 ##

### 5.1 讲解下你自己理解的 CAS 机制 ###

全称 Compare and swap, 即 "比较并交换". 相当于通过一个原子的操作, 同时完成 "读取内存, 比  
较是否相等, 修改内存" 这三个步骤. 本质上需要 CPU 指令的支撑

### 5.2 ABA问题怎么解决？ ###

给要修改的数据引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期.  
如果发现当前版本号和之前读到的版本号一致, 就真正执行修改操作, 并让版本号自增; 如果发现当  
前版本号比之前读到的版本号大, 就认为操作失败

[05220197f96e43bd831fb30f8171aacf.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/551ffce7d639477eada4b66b0301e22b.png
[xyk]: https://blog.csdn.net/asad21654864?spm=1000.2115.3001.5343
[JavaEE]: https://blog.csdn.net/asad21654864/category_12243955.html?spm=1001.2014.3001.5482
[40868fd0e76d43ee8f1c92e09a23535e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/1c5bebebbbdf4d60b23e8d3a824cc141.png
[386f8b92e70c4bbd9e361ae36476c4e0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/ff6388fd26c348c8a756c46b5650a47b.png
[88c868f1558f4cc6a44cd37840bd5b46.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/42660577a261478bb19760665d319187.png
[4a37cebee8be448ba202e1e93303f0ae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/6430191d519f4c45b81c972732f8ae39.png
[0cdb13ef65534f248ceb3144daf3c843.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/efc5bd1dc1084cdfb5b6eceedf4446fc.png
[6046a9665ab842f7be2ba776d9cc2bf1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/4e9307e71c6c46e3a548ee9479bd6fef.png
[42a572c9b8ab4de29d1c88844e4823cb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/0eedcb112ede44a5960fd2518af57e52.png
[fb74462b8f714384accae8985fa27ac0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/d0a213965ce34a6da60597108f5cf5b6.png