震惊!!!原来CAS这样理解更简单!!

一:什么是CAS

compare and swap :比较和交换
CAS是一条CPU指令(原子性),但可以完成比较和交换操作.
CAS的流程,可以想象成一个方法.

CAS的伪代码:

上图所说的"交换",实际上更多的是用来"赋值";一般更关心内存中,交换后的数据,而不关心reg2寄存器 里交换后的数据.近似的可以认为上述伪代码就是如果address内存地址的值和reg1 寄存器里的值相等,就把reg2寄存器的值赋值给address内存地址.
由于CPU提供了上述指令,因此操作系统内核,也就能够完成上述操作,就会提供这样的CAS的API,而JVM又对CAS API进一步的封装了,因此,在Java代码中也就可以使用CAS操作了.
但实际上,CAS被封装到了一个"unsafe"包中,不鼓励使用.

二:原子类

Java中,也有一些类,对CAS进行了进一步的封装,典型的就是"原子类".

public class Demo1{
    private  static AtomicInteger count=new AtomicInteger(0);
    public static void main(String[] args) {
        Thread t1=new Thread(()->{
            for (int i = 0; i <50000 ; i++) {
                //count.getAndDecrement();//count++
                //可以保证这里的count++就是原子的
                count.incrementAndGet();//++count
            }
        });
        Thread t2=new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                count.getAndIncrement();
            }
        });
            t1.start();
            t2.start();
            try{
                t1.join();
                t2.join();
            }catch (InterruptedException e){
                e.printStackTrace();
            }

        System.out.println("count= " +count);

    }
}

基于CAS,不加锁来实现线程安全代码的方式,也称为"无锁编程".
但CAS只能是针对一些特殊的场景,使用它是高效的(少数场景),比如上述的"++“,”–"

2.1:自旋锁基于CAS实现的原理

public class SpinLock {
    private Thread owner = null;
    //owner 会记录持有锁的线程是谁,未加锁的状态,owner就是null
    public void lock(){
        //通过CAS看当前锁是否被某个线程持有,
        //如果这个锁被别的线程持有,那么就自旋等待
        //如果这个锁没有被别的线程持有,那么就把owner设为当前尝试加锁的线程
        while(!CAS(this.owner,null,Thread.currentThread()));
        //如果当前owner为空,就把当前调用lock方法的线程引用赋值给owner
        //此时,CAS返回true,取反,循环结束
        //如果当前owner的是不为null,此时,CAS不会进行任何交换/赋值,直接返回false.
        //再取反,就是true,就继续循环
    }
    public void unlock(){
        this.owner=null;
    }



}

但如果是重量级锁,系统内核的锁的API就不是这样的了,系统内核的锁的API会让线程被挂起(进入阻塞状态),修改线程的PCB,移动到表示阻塞状态的队列中,(链表节点的删除和插入操作),使线程不参与调度.

三:CAS的ABA问题

CAS的核心就是"比较-发现相等-交换"
如果内存中的值,不相等,就有稍后重试;
发现相等指的是数据中间没有发生任何的改变.
但相等!=没有改变过
CAS期望的是:中间没有其他线程修改过这个数据,实际上,不一定,可能会出现,其他线程,把这个数据从 A->B->A,看起来没改变,但其实变了
CAS无法区分,当前数据是确实没有改变过,还是变了,又变回来了.但是,在大多数的情况下,区分不区分,不太影响,也不会有什么问题.
但这有些极端的情况下,可能会产生bug!

3.1:情景再现:

假设:滑稽老铁,账户余额是1000,准备从ATM里取款500(假设取款操作是按照CAS的方式来执行的).

滑稽老铁,进行取款,在取款的过程中,发生bug了,按了一下取款,卡了一下,他紧接着又按了一下.此时,产生了两个线程,来执行上述扣款操作.
如果只有两个线程,是没有问题的.比如:

但如果,刚好有人给滑稽老铁转账500,就可能存在bug了.
比如:

上就是ABA 问题的典型bug场景,是非常极端的场景,
用户多次点击&&恰好在这个时候有另外的人转账&&转账刚好是500&&转账刚好在第一次扣款之后,第二次扣款之前.诸多的巧合,才能构成上述的bug,任何一个环节正好没对上,都不会出现bug.

3.2:如何避免ABA问题

使用账户余额判定,本身就不太科学,因为账户余额本身就属于"能加也能减",就容易出现ABA问题.
引入"版本号",约定版本号,只能加,不能减,每次操作后,版本号都要+1,通过CAS判定版本号,就可以进一步的完成上述的操作.