java中的CAS操作以及ABA问题

引出

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

因为java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。

 所以，使用无锁（乐观锁思想）会很大程度上避免上述问题，比如使用volatile定义变量，但是volattile只能保证贡享变量的可见性，不能解决读>改>写等的原子问题，这时可以使用CAS（Compare and Swap）。

CAS（Compare and Swap）

  CAS,比较和交换，是JDK提供的非阻塞性的原子操作，JDK里面的Unsaf类提供了一系列的compareAndSwap*方法，这些方法都是native方法，使用JNI的方式访问本地的C++实现库，也可以说，JDK通过硬件保证了读>改>写的原子操作。

运行原理

   CAS（V, A, B）主要有三个参数，V为内存的值、A为预期值，B为新值。当内内存中的值与预期的值相等时，那么就将内存的值更新为新的值B，如果内存值与预期值不相等，说明有其他线程对这个已被其他线程更新，此时处理器不做任何操作。

如上，
   多线程情况下，一个线程判断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。