JAVA并发基石——CAS

引言

我们知道，锁分为乐观锁，悲观锁

• 独占锁是一种悲观锁，而 synchronized 就是一种独占锁，synchronized会导致其它所有未持有锁的线程阻塞，而等待持有锁的线程释放锁。
• 所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。而乐观锁用到的机制就是CAS。

下面我们来写一段代码

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;

public class Demo {
    static int count=0;
    public  static void request() throws InterruptedException {
        TimeUnit.MICROSECONDS.sleep(5);
        count++;

    }


    public  static void main(String[] args) throws InterruptedException {
        long startIime=System.currentTimeMillis();
        int threadSize=100;
        CountDownLatch countDownLatch=new CountDownLatch(threadSize);
        for (int i=0;i<threadSize;i++){
            Thread thread=new Thread(new Runnable() {
                @Override
                public void run() {
                 try {
                     for (int j=0;j<10;j++){
                         request();
                     }
                 }catch (InterruptedException e){
                     e.printStackTrace();
                 }finally {
                     countDownLatch.countDown();
                 }
                }
            });
            thread.start();
        }
        countDownLatch.await();
        long endTime=System.currentTimeMillis();
        System.out.println(Thread.currentThread().getName()+"耗时："+(endTime-startIime+"  count:"+count));

    }
}

我们可以看到，代码中总共有一千次的循环，按理来说，最后的count应该是1000，但是，最后的答案却不是1000，这是为什么呢？

其实count++ 这一行代码一共有三步操作：

• 1.获取count的值，记做A : A=count
• 2.将A值+1，得到B ：B=A+1
• 3.将B值赋值给count

那么，如果有A.B两个线程同时执行count++,他们通知执行到上面步骤的第一步，得到的count是一样的，3步操作结束后，count只加了1，导致count结果不正确，那么，我们是否可以在A=count这里一步把它锁住呢？

我们来写下一段代码

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;

public class Demo2 {
    static int count=0;
    public synchronized static void request() throws InterruptedException {
        TimeUnit.MICROSECONDS.sleep(5);
        count++;

    }


    public  static void main(String[] args) throws InterruptedException {
        long startIime=System.currentTimeMillis();
        int threadSize=100;
        CountDownLatch countDownLatch=new CountDownLatch(threadSize);
        for (int i=0;i<threadSize;i++){
            Thread thread=new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        for (int j=0;j<10;j++){
                            request();
                        }
                    }catch (InterruptedException e){
                        e.printStackTrace();
                    }finally {
                        countDownLatch.countDown();
                    }
                }
            });
            thread.start();
        }
        countDownLatch.await();
        long endTime=System.currentTimeMillis();
        System.out.println(Thread.currentThread().getName()+"耗时："+(endTime-startIime+"  count:"+count));

    }
}

在这里我们用**synchronized 修饰了方法，但是，我们发现修饰后需要的时间大大上升，这是因为被synchronized **修饰后，synchronized关键字会让没有得到锁资源的线程进入BLOCKED状态，而后在争夺到锁资源后恢复为RUNNABLE状态，这个过程中涉及到操作系统用户模式和内核模式的转换，代价比较高。

尽管JAVA 1.6为synchronized做了优化，增加了从偏向锁到轻量级锁再到重量级锁的过过度，但是在最终转变为重量级锁之后，性能仍然比较低。所以面对这种情况，我们就可以使用java中的“原子操作类”。

我们来再写一段代码

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;

public class Demo3 {
    static int count=0;
    public  static void request() throws InterruptedException {
        TimeUnit.MICROSECONDS.sleep(5);
        int expectCount;
        while(!compareAndSwap(expectCount=getCount(),expectCount+1)){

        }

    }

    public static synchronized boolean compareAndSwap(int expectCount,int newCount){
        if(getCount()==expectCount){
            count=newCount;
            return true;
        }
        return false;
    }
    public  static int getCount(){return count;}

    public  static void main(String[] args) throws InterruptedException {
        long startIime=System.currentTimeMillis();
        int threadSize=100;
        CountDownLatch countDownLatch=new CountDownLatch(threadSize);
        for (int i=0;i<threadSize;i++){
            Thread thread=new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        for (int j=0;j<10;j++){
                            request();
                        }
                    }catch (InterruptedException e){
                        e.printStackTrace();
                    }finally {
                        countDownLatch.countDown();
                    }
                }
            });
            thread.start();
        }
        countDownLatch.await();
        long endTime=System.currentTimeMillis();
        System.out.println(Thread.currentThread().getName()+"耗时："+(endTime-startIime+"  count:"+count));

    }
}

可以看到，这里消耗的时间很少，而且结果也是我们想要的1000

CAS机制

CAS机制全称compare and swap，翻译为比较并交换，是一种有名的无锁（lock-free）算法。也是一种现代 CPU 广泛支持的CPU指令级的操作，只有一步原子操作，所以非常快。而且CAS避免了请求操作系统来裁定锁的问题，直接在CPU内部就完成了，CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。更新一个变量的时候，只有当变量的预期值A和内存地址V当中的实际值相同时，才会将内存地址V对应的值修改为B，这样说或许有些抽象，我们来看一个例子：

在内存地址V当中，存储着值为10的变量。

此时线程1想要把变量的值增加1。对线程1来说，旧的预期值A=10，要修改的新值B=11。

在线程1要提交更新之前，另一个线程2抢先一步，把内存地址V中的变量值率先更新成了11。

线程1开始提交更新，首先进行A和地址V的实际值比较（Compare），发现A不等于V的实际值，提交失败。

线程1重新获取内存地址V的当前值，并重新计算想要修改的新值。此时对线程1来说，A=11，B=12。这个重新尝试的过程被称为自旋。

这一次比较幸运，没有其他线程改变地址V的值。线程1进行Compare，发现A和地址V的实际值是相等的。

线程1进行SWAP，把地址V的值替换为B，也就是12。

CAS的缺点

1.CPU开销较大

在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。

2.不能保证代码块的原子性

CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。

 因为它本身就只是一个锁住总线的原子交换操作啊。两个CAS操作之间并不能保证没有重入现象。

3.ABA问题

这是CAS机制最大的问题所在，什么是ABA呢？就是A变成了B又变成了A，我们来举个例子

假设内存中有一个值为A的变量，存储在地址V当中。

此时有三个线程想使用CAS的方式更新这个变量值，每个线程的执行时间有略微的偏差。线程1和线程2已经获得当前值，线程3还未获得当前值。

接下来，线程1先一步执行成功，把当前值成功从A更新为B；同时线程2因为某种原因被阻塞住，没有做更新操作；线程3在线程1更新之后，获得了当前值B。

再之后，线程2仍然处于阻塞状态，线程3继续执行，成功把当前值从B更新成了A。

最后，线程2终于恢复了运行状态，由于阻塞之前已经获得了“当前值”A，并且经过compare检测，内存地址V中的实际值也是A，所以成功把变量值A更新成了B。

这样子看着好像也没有什么问题，那我们用一个实际的业务来举一个例子

• 小明的卡上有5000元，他去银行取2000块钱
• 这个时候因为某种故障，取钱的请求发出了两次
• 这个时候，小明的妈妈给他寄过去2000块钱

我们来分析一下结果

按照我们的想法，应该是第一个请求发出去，卡上就只有3000元了，这个时候另一个请求发过来，卡上变成5000元，然后被阻塞的请求失败，卡上还有5000元，但是事实不是这样的，结果是第三次请求又会扣除卡里2000元，这样，就出现了一个很大的问题。

如何应对ABA问题

其实也不是什么很难的问题，我们加一个版本号就行了，我们仍然以最初的例子来说明一下，假设地址V中存储着变量值A，当前版本号是01。线程1获得了当前值A和版本号01，想要更新为B，但是被阻塞了。

这时候，内存地址V中的变量发生了多次改变，版本号提升为03，但是变量值仍然是A。

随后线程1恢复运行，进行Compare操作。经过比较，线程1所获得的值和地址V的实际值都是A，但是版本号不相等，所以这一次更新失败。

在Java当中，AtomicStampedReference类就实现了用版本号做比较的CAS机制。