JAVA并发基石——CAS

Posted Code_BinBin

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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机制。

以上是关于JAVA并发基石——CAS的主要内容,如果未能解决你的问题,请参考以下文章

JAVA并发基石——CAS

Java并发基石-CAS原理实战

Java并发基石-CAS原理实战

并发编程的灵魂:CAS机制详解

并发-CAS 原理浅解01

并发-CAS 原理浅解01