java中的CAS操作以及ABA问题

引出

  java锁在并发中占据着重要的地位,但是有一个缺点就是,当一个线程没有获取到锁的时候就会被阻塞挂起,等到锁被释放时再重新被唤醒去竞争锁这个是比较耗费系统资源的。

因为java的线程是java中的CAS操作以及ABA问题
如上,
   多线程情况下,一个线程判断V=A成立,将V修改成新值,其他线程预期值也是修改前的内存值,此时判断V=A不成立,于是重新读取内存中的值为预期值,并尝试再次修改V的值,即继续CAS。当然也不是可以一直循环CAS的,毕竟这样时间长了也会非常消耗CPU资源的。

应用

CAS操作采用了乐观锁的思想,总是认为自己可以成功完成操作。在有多个线程同时使用CAS操作一个变量时,只有一个会胜出并成功更新,其余均失败。失败的线程不会被挂起,仅被告知失败,并且允许再次尝试,当然,也允许失败的线程放弃操作。基于这样的原理,CAS操作即使没有锁,也可以发现其他线程对当前线程的干扰,并进行恰当的处理。

在JDK的JUC包中(java.util.concurrent.atomic)里面提供了一组原子类:常见的有

  • AtomicInteger:整形原子类
  • AtomicLong:长整型原子类
  • AtomicBoolean:布尔型原子类
  • AtomicReference:引用类型原子类

这些原子类的基本特性就是在多线程环境下,有多个线程同时执行这些类的实例包含的方法时,会有排他性。其内部是基于CAS算法实现的,即在某个线程进入方法中执行其中的指令时,不会被其他线程打断;而别的线程就像自旋锁一样,一直等到该方法执行完成才由JVM从等待的队列中选择另一个线程进入

CAS的ABA问题

   假如线程1使用CAS修改初始值为1的变量,那么首先获取当前这个变量的值(假设是A),使用CAS操作尝试把变量修改为B,但执行前,线程1失去CPU使用权了,线程2进来,将变量改为B,随后又使用CAS修改为A,当线程A再来时,发现变量和预期值还相等,于是CAS操作成功。
  举个例子:比如一个程序的逻辑是当余额还剩100时就给账号充值200,A线程首先获取到余额是100,准备执行+200操作,此时线程B来了将余额加上200,此时余额是300,随后,很快,用户消费了200,此时余额还剩100,现在,A终于获取到CPU时间段,执行CAS发现余额还是100,和预期一样,于是CAS操作成功,账户又加200,这就导致账户充值了两次。

如何解决ABA问题

  通过版本号解决,每次执行数据的修改操作时都会带上一个版本号,在预期上午版本还号和内存中版本号相同时,执行修改操作,并对版本号+1,否则不操作。以为版本号是递增的,所以不会出现ABA问题。例:java原子类中的AtomicStampedReference和AtomicMarkableReference。

版权声明:玥玥 发表于 2021-03-14 6:44:57。
转载请注明:java中的CAS操作以及ABA问题 | 女黑客导航