JUC——CAS与ABA问题

什么是CAS?

这是 compareAndSet() 方法的首字母缩写。CAS是CPU的并发原语。

而这个方法的作用也能从名字看出来。

  • 比较并赋值

举个例子:

public static void main(String[] args) {
        // 参数:默认值
        AtomicInteger atomicInteger = new AtomicInteger(2020);
        //如果期望的值为 2020, 则把他修改成 2021,,否则不更新
        System.out.println(atomicInteger.compareAndSet(2020, 2021));
        System.out.println(atomicInteger.get());
        atomicInteger.getAndIncrement();//相当于 num++;
        System.out.println(atomicInteger.compareAndSet(2020, 2021));
        System.out.println(atomicInteger.get());
    }

这里的 AtomicInteger 是原子性的 Integer。
atomic
也是 java.util.concurrent 包下的。

执行结果:

true
2021
false
2022

有两个参数:

  • compareAndSet(“期望的值”,“要变更为的值”);

接下来说一下ABA问题,这个问题就是伴随着CAS而生的。


什么是ABA问题?


就拿刚刚那个例子来说,如果有两个线程来,就有可能出现问题。

上图理解:
CAS_ABA问题

这里有同学可能会说,结果”没变”,感觉问题不大。

  • 这难道就是我们想要的结果吗?

说明这个问题之前,我们先从文字含义角度理解一波,来仔细体会一下 “期望” 和 “修改”,这两个词。

先说 “修改”:

  • 修改所带来的影响是深远的,改了就是改了,没有说改了一段时间自己又变回去了。这是一个持久的过程。
  • 相对的另一个词:“期望”,也必须是持久的期望,不能只是在判断的那一时刻。

这意思就是说:很多时候我们不能只是判断变量的值,还要保证变量的状态。这是两个维度的事儿,忽略哪一个都会出现问题。


如何解决ABA问题


在各种乐观锁的实现中,都采用了 version 版本号来加以区分。

  • 在 Java 中 AtomicStampedReference 实现了这种思想。

上代码感受一下:

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicStampedReference;

//经典的ABA问题解决方案
//其思想 和 乐观锁很像(可以说是一样)
public class ABA {
    public static void main(String[] args) {

        int stamp = 1;
        AtomicStampedReference<Integer> reference = new AtomicStampedReference<>(1,stamp);

        new Thread(()->{
            //期待值为1 修改为2 ;期待版本号为 stamp 修改版本号为 stamp+1
            System.out.println("线程A:"+reference.compareAndSet(1, 2
                    , stamp, stamp + 1));
            System.out.println("线程A:"+reference.getReference());//获得引用值
            //再把值该回去
            System.out.println("线程A:"+reference.compareAndSet(2, 1
                    , reference.getStamp(), reference.getStamp() + 1));
            System.out.println("线程A:"+reference.getReference());//获得引用值
        },"线程A").start();

        new Thread(()->{
            //让 线程A 先搞完。
            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            //期待值为1 修改为2 ;期待版本号为 stamp 修改版本号为 stamp+1
            System.out.println("线程B:"+reference.compareAndSet(1, 6
                    , stamp, stamp + 1));
            System.out.println("线程B:"+reference.getReference());//获得引用值
        },"线程B").start();
    }
}

执行结果:

线程A:true
线程A:2
线程A:true
线程A:1
线程B:false
线程B:1

虽然 线程B 期待的值是对的,但期待的版本号不对,所以给出了CAS执行失败的结果。

  • 这样就避免了ABA问题的发生。

不解决ABA问题会有什么后果。


首先,我们先要认清一点:

ABA问题是非常具有隐晦性的,他造成的影响通常不可预知。

进一步解释就是:

  • 它让逻辑确定的程序有了不确定性。

举个例子(很经典):

一个栈:A→B→C

线程 T1 要将A pop()出去,这样栈顶就是 B 了 (他已经知道了下一个元素是B)

  • 这个用CAS实现就是:head.compareAndSet(A,B)
    • 期待A,改成B

理想修改后的状态:B→C

可是这时候来了一个线程 T2 ,他不讲武德,上去一套闪电五连鞭…

  • 在 线程 T1 之前 完成 pop 出 B 和 C,然后又将 B push进去。

这样 C 就无缘无故地被丢了,异常修改后的状态:B

这样的问题是不确定性的,带来的错误也是影响深远的,不能被及时发现的。

  • 不确定会不会来其他线程捣乱
  • 在错误发生之后,head.compareAndSet(A,B) 执行成功了,继续对后面操作造成影响。
  • 问题会在下次调用 C 时,从逻辑上发现(C不存在了)

不报错的问题才是最可怕的,这种隐晦性的问题是我们不希望遇到的。


版本号的真正作用:

首先,在版本号的判断下,如果出现问题,后面操作是不会执行的。

能让我们及时发现问题。这样就把隐晦性的问题变得明朗起来了。

That’s all, thank you.

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

少歌

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值