JDK的CAS机制

最新推荐文章于 2023-11-29 11:54:20 发布
最新推荐文章于 2023-11-29 11:54:20 发布
阅读量271 收藏
点赞数
分类专栏： CAS机制 文章标签： java jdk 并发编程 多线程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Pathosiser/article/details/109168530
版权

CAS机制总结

1、CAS的引出

在理解什么是CAS之前让我们来看一段代码：

public class Demo01 {

    /**
     * 记录访问次数
     */
    static int count;

    public static void request() throws InterruptedException {
        //调用一次耗时5毫秒
        TimeUnit.MILLISECONDS.sleep(5);
        count++;
    }

    public static void main(String[] args) {
        long startTime = System.currentTimeMillis();
        int threadSize = 100;

        /**
         * 为了保证100线程全部执行，所以使用CountDownLatch栅栏类
         */
        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 i = 0 ; i< 10 ; i++){
                            request();
                        }
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }finally {
                        countDownLatch.countDown();
                    }
                }
            });
            thread.start();
        }
        try {
            countDownLatch.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        long endTime = System.currentTimeMillis();
        System.out.println("当前线程："+Thread.currentThread().getName() + "耗时："+(endTime-startTime)+"ms,count:"+count);
    }
}

上面的代码的说明：在多线程情况下，访问一个方法，访问成功一次则count++，共有开启100条线程，每个线程访问10次，count的最终结果预期为1000.
最终程序运行结果为：
在这里插入图片描述
我们通过结果发现，访问数并你没有达到我们预期的1000，运行多次后count的结果依旧是<1000的。
那这是为什么呢？
我们不难发现，count++ 不是原子性操作，它实际上是由三步来完成的！

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

当有多个线程同时执行count++，他们同时执行到上面步骤的第一步，得到count是一样的，3步操作结束后。count只加1，导致count结果不正确

基于这个问题，我们可以对count++操作的时候，我们让多个线程排队处理，多个线程同时到达request()方法的时候，只能允许一个线程可以进去操作，其他线程在外面等待，等里面的线程处理完毕后，外面等待的线程再进去一个，这样操作的count++就是排队进行的，结果一定是正确的。
我们只需要在当前代码上稍微做点修改即可，其他代码不变，在request()方法上添加synchronized 关键字，锁对象为当前类的Class对象。

  public synchronized static void request() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(5);
        count++;
    }

我们再次执行代码，结果是：
在这里插入图片描述
通过结果我们不难发现，count确实达到了我们预期的结果，但耗时太长了，因为线程中的request方法使用synchronized关键字修饰，保证了并发情况下，request方法同一时刻只允许一个线程进入，request加锁相当于串行执行了，所以才会出现耗时长。

怎么解决这耗时长的问题呢？
在之前我们提到过，count++实际上是由三部分组成的，

  1. 获取count的值 ，记做A : A = count
  2. 将A的值+1 ，记做B : B = A + 1
  3. 将B的值赋值给count
    接下来，我们将升级第三步，将第三步分为四个步骤去完成，分别是
    - [1] 获取锁
    - [2] 获取当下count的最新值，记做expectCount
    - [3] 判断expectCount的值是否等于A，如果相等，则将B的值赋值给count，并返回true，否则返回false，然后再次执行count++操作，直到返回true为止。
    - [4] 释放锁

代码如下：

 /**
     * 记录访问次数
     * volatile : 表示多线程之间，count值可见
     */
    volatile static int count;

    public static int getCount() {
        return count;
    }

    public static void request() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(5);
//        count++;
        int expectCount;
        while(!CompareAndSwap(expectCount = getCount(), expectCount+1)){}
    }

    /**
     * 只给count++的第三步加锁
     * @param expectCount 期望值
     * @param newCount 需要给count赋值的新值
     * @return 成功返回true 失败返回false
     */
    public static synchronized boolean CompareAndSwap(int expectCount , int newCount){
        if(expectCount == getCount()){
            count = newCount;
            return true;
        }
        return false;
    }
     public static void main(String[] args) {
    	//main方法不做改变
    }

执行代码，结果是：
在这里插入图片描述
从结果中，我们可以很直接的发现，耗时变短了，count的值也是符合我们预期的值，这就是CAS。

2、介绍CAS机制

CAS(Compare-And-Swap):比较再替换。简单来说，比较和替换是使用一个期望值和一个变量的当前值进行比较，如果当前变量的值与我们期望的值相等，就使用一个新值替换当前变量的值。CAS包含三个操作数 (V（内存位置）、A（期望值）、B（新值）)，如果内存位置V的值与期望值A相同，那么处理器判断内存某个位置的值是是否为预期值，如果是则更改为B的值，如果不是，处理器不会做任何操作，并且这个过程是原子的。

3、JDK中是如何实现CAS呢？

以比较简单的AtomicInteger为例(一些AtomicInteger的方法)：
在这里插入图片描述
在这里插入图片描述
我们发现，AtimicInteger的方法都是通过unsafe对象来调用的。
Unsafe是CAS的核心类，由于Java是无法直接访问底层系统的，需要通过本地（native）方法来防访问，Unsafe相当于一个后门，基于该类可以直接操作特定内存的数据，Unsafe类存在于sun.misc包中，其内部方法操作可以像C的指针一样直接操作内存。在Java中CAS操作的执行依赖于Unsafe类的方法。
在这里插入图片描述Unsafe的方法都是由native修饰的，功力还比较浅薄，等高深一点再进去看原理吧！

总结：JDK实现CAS机制是因为底层调用了Unsafe的CAS方法

4、CAS机制的优缺点

优点：CAS是一种乐观锁，而且是一种非阻塞的轻量级的乐观锁，什么是非阻塞式的呢？其实就是一个线程想要获得锁，对方会给一个回应表示这个锁能不能获得。在资源竞争不激烈的情况下性能高，相比synchronized重量锁，synchronized会进行比较复杂的加锁，解锁和唤醒操作。

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

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

3.ABA问题：CAS最大的问题。CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，在CAS方法执行之前，被其它线程修改为了B、然后又修改回了A，那么CAS方法执行检查的时候会发现它的值没有发生变化，但是实际却变化了。这就是CAS的ABA问题。

5、代码模拟ABA问题

public class CASABATest {

    /**
     * AtomicInteger: 可以用原子方式更新的 int 值
     *
     * 准备数据 , 初始值为1
     *
     */
    public static AtomicInteger a = new AtomicInteger(1);

    public static void main(String[] args) {
        /**
         * 创建两个线程，模拟CAS的ABA问题
         * 主线程执行+1操作
         * 其他线程在主线程替换旧值时执行+1，-1操作
         */
        Thread main = new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println("操作线程："+Thread.currentThread().getName()+",初始值:"+a.get());
                int expectNum = a.get();
                int newNum = expectNum + 1;

                try {
                    Thread.sleep(1000L); // main线程休息一秒，让出cpu的资源
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                boolean isCASSuccess = a.compareAndSet(expectNum, newNum);
                System.out.println("操作线程："+Thread.currentThread().getName()+",[incread],CAS:"+isCASSuccess);

            }
        },"主线程");

        Thread other = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(10L);//休息10毫秒，保证主线程运行到了sleep
                    int incNum = a.incrementAndGet(); // +1 操作
                    System.out.println("操作线程："+Thread.currentThread().getName()+",【increment】值为:"+a.get());
                    int decNum = a.decrementAndGet(); // -1 操作
                    System.out.println("操作线程："+Thread.currentThread().getName()+",【decrement】值为:"+a.get());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        },"其他线程");

        main.start();
        other.start();
    }

}

代码分析：创建两个线程，主线程执行+1操作，干扰线程执行+1，-1操作，然后通过AtomicInteger的compareAndSet() ->替换成功则返回true，否则返回false。
运行代码，结果如下：
在这里插入图片描述
我们看到CAS的结果为true，但我们已经在干扰线程中对当前值进行了操作，这就意味着CAS并没有察觉到ABA问题，这就是CAS的ABA问题。

6、JDK自带的ABA问题解决方法

AtomicStampedReference主要包含一个对象引用及一个可以自动更新的整数“stamp”的Pair对象来解决ABA问题。
在这里插入图片描述
修改数据需要提供原来数据的引用以及版本号，只有版本号一致了，你就能去修改数据。我们去看一下他的compareAndSet()方法。
在这里插入图片描述
当你的期望引用以及你的期望版本号与Pair对象中的引用数据以及版本号一致，才可进行替换操作。
在这里插入图片描述
casPair()的底层源码：
在这里插入图片描述
ABA问题的解决，代码如下：

public class CASABATest02 {

    /**
     * AtomicInteger: 可以用原子方式更新的 int 值
     *
     * 准备数据 , 初始值为1
     *
     */
    public static AtomicStampedReference<Integer> a = new AtomicStampedReference<>(1,1);

    public static void main(String[] args) {
        /**
         * 创建两个线程，模拟CAS的ABA问题
         * 主线程执行+1操作
         * 其他线程在主线程替换旧值时执行+1，-1操作
         */
        Thread main = new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println("操作线程："+Thread.currentThread().getName()+",初始值:"+a.getReference());
                Integer expectReference = a.getReference(); //期望引用
                Integer newReference = expectReference + 1; //新的引用
                Integer expectStamp = a.getStamp();//期望版本
                Integer newStamp = expectStamp + 1;
                try {
                    Thread.sleep(1000L); // main线程休息一秒，让出cpu的资源
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                boolean isCASSuccess = a.compareAndSet(expectReference, newReference,expectStamp,newStamp);
                System.out.println("操作线程："+Thread.currentThread().getName()+",[incread],CAS:"+isCASSuccess);

            }
        },"主线程");

        Thread other = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(10L);//休息10毫秒，保证主线程运行到了sleep
                    a.compareAndSet(a.getReference(),a.getReference()+1,a.getStamp(),a.getStamp()+1);//加1
                    System.out.println("操作线程："+Thread.currentThread().getName()+",【increment】值为:"+a.getReference()+"版本："+a.getStamp());
                    a.compareAndSet(a.getReference(),a.getReference()-1,a.getStamp(),a.getStamp()+1);//-1
                    System.out.println("操作线程："+Thread.currentThread().getName()+",【decrement】值为:"+a.getReference()+"版本："+a.getStamp());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        },"其他线程");

        main.start();
        other.start();
    }

}

代码分析：我们将AtomicInteger 对象替换成了AtomicStampedReference对象，给期望引用添加了期望版本号，在执行CAS操作时，如果期望引用和新引用或者期望版本和新版本不一致，compareAndSet()方法就会返回false，很显然，我们在干扰线程中对版本进行了两次+1操作，而期望版本是一次+1操作，所以一定返回的是false。
结果如下：
在这里插入图片描述

Pathosiser
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
CAS下ABA问题及优化方案
07-03
• select&set业务场景，在并发时会出现一致性问题 • 基于“值”的CAS乐观锁，可能导致ABA问题 • CAS乐观锁，必须保证修改时的“此数据”就是“彼数据”，应该由“值”比对，优化为“版本号”比对
jdk1.8_64.7z
11-03
解压缩版，不是安装版 jdk1.8 中对集合的底层结构做了调整。 如HashMap从1.7的数据+链表的形式...ConcurrentHashMap从分段机制+数组+链表+红黑树到CAS+数组+链表+红黑树。 这里先简要记录，后续会详解Map的原理与区别。
JDK 中CAS(原子)操作工具类 AtomicInteger AtomicIntegerArray AtomicReference等等
红鹰
10-22 383
CAS操作(原子操作，底层使用处理器的CAS指令)，内部通过乐观锁(旧值和新值比较或版本号比较)实现， 缺点：ABA问题：值改成其他值后又改回来了，从而不知道是否改过(只控制结果，不能够控制过程)。解决方案添加版本号（默认旧值和新值进行比较）,JDK 提供AtomicMarkableReference，AtomicStampedReference。 AtomicMarkableReference...
CAS的ABA问题详解
Frankltf的博客
03-18 244
CAS的ABA问题详解 CAS的ABA问题详解 ABA问题 在多线程场景下CAS会出现ABA问题，关于ABA问题这里简单科普下，例如有2个线程同时对同一个值(初始值为A)进行CAS操作，这三个线程如下 1.线程1，期望值为A，欲更新的值为B 2.线程2，期望值为A，欲更新的值为B 线程1抢先获得CPU时间片，而线程2因为其他原因阻塞了，线程1...
CAS的ABA问题及解决方法
yang_154116的博客
07-21 8647
一、什么是ABA问题？ 考虑如下操作： 并发1（上）：获取出数据的初始值是A，后续计划实施CAS乐观锁，期望数据仍是A的时候，修改才能成功 并发2：将数据修改成B 并发3：将数据修改回A 并发1（下）：CAS乐观锁，检测发现初始值还是A，进行数据修改   上述并发环境下，并发1在修改数据时，虽然还是A，但已经不是初始条件的A了，中间发生了A变B，B又变A...
java多线程基础知识之CAS（jdk8）解析
chenglian9396418的博客
09-05 452
1 CAS讲解 在工作中，我们往往需要面对多线程计数的问题，我们第一反应，使用“synchronized”，控制并发。 @Slf4j public class CASDemo extends Thread{ private static int t = 0; ...
jdk1.8.0_60_linux.zip
05-13
在jdk1.8中对hashMap等map集合的数据结构优化。hashMap数据结构的优化 ...ConcurrentHashMap (锁分段机制)，concurrentLevel,jdk1.8采用CAS算法(无锁算法，不再使用锁分段)，数组+链表中也引入了红黑树的使用
jdk-8u112-windows-x64.zip
03-22
在jdk1.8中对hashMap等map集合的数据结构优化。hashMap数据结构的优化 ...ConcurrentHashMap (锁分段机制)，concurrentLevel,jdk1.8采用CAS算法(无锁算法，不再使用锁分段)，数组+链表中也引入了红黑树的使用
jdk-8u202-linux-x64.tar
03-25
在jdk1.8中对hashMap等map集合的数据结构优化。...除了添加之后，效率都比链表高，1.8之后链表新进元素加到末尾，ConcurrentHashMap (锁分段机制)，concurrentLevel,1.8采用CAS算法，数组+链表中也引入了红黑树的使用
JAVA CAS实现原理与使用.docx
06-21
在JDK 5之前Java语言是靠synchronized关键字保证同步的，这会导致有锁（后面的章节还会谈到锁）。 锁机制存在以下问题： （1）在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。 （2...
Java并发编程-CAS原理
最新发布
m0_46561911的博客
11-29 906
CAS 自旋锁 ABA
说说你对Jdk并发包中的CAS实现的了解？
weixin_34183910的博客
12-06 92
为什么80%的码农都做不了架构师？>>> ...
Java中CAS详解
qq_37436172的博客
12-06 1847
CAS机制是一种数据更新的方式。在具体讲什么是CAS机制之前，我们先来聊下在多线程环境下，对共享变量进行数据更新的两种模式：悲观锁模式和乐观锁模式。 悲观锁更新的方式认为：在更新数据的时候大概率会有其他线程去争夺共享资源，所以悲观锁的做法是：第一个获取资源的线程会将资源锁定起来，其他没争夺到资源的线程只能进入阻塞队列，等第一个获取资源的线程释放锁之后，这些线程才能有机会重新争夺资源。synchronized就是java中悲观锁的典型实现，synchronized使用起来非常简单方便，但是会使没争抢到资源的线
单点登录CAS-01：如何找到适合自己JDK版本的CAS？
小码哥的专栏
05-12 1964
单点登录CAS-01环境准备1、背景2、步骤 1、背景 最近的项目需要用到单点登录，网上此类文章有很多，我尝试只通过看官方文档上手，特写此系列文章记录一下上手流程。 我的项目环境用的是JDK1.8，而cas最新版本需要jdk11，因此遇到的第一个问题是：如何找到适合我项目使用的CAS版本？ 笨方法：找到历史版本页面，一个个点进去查看其依赖环境，直到找到合适的版本。 2、步骤 1、打开CAS官网：http://www.jasig.org/cas,在页面上找到"download"字样的链接： 2、点击后进入
jdk1.8对cas操作优化
lh87270202的博客
02-26 1123
一、前言 假设现在有多个线程对一个变量不停累加，如果直接对这个变量做 ++ 操作，是有问题的。 多线程对一个data变量时空行修改，是线程不安全的，会导致data值的变化不 遵循预期的值来改变。 二、初初步解决：synchronized 对方法上加synchronized关键字，这样初步的解决“太重了”。 更高效解决方案：Atomic原子类及其底层原理 java并发包下提供了一系列Atomic原子...
CAS的ABA问题
legend050709的专栏
03-05 111
cas
Java并发基础：了解无锁CAS就从源码分析
weixin_34377065的博客
08-05 110
了解无锁CAS就从源码分析 CAS的全称为Compare And Swap，直译就是比较交换。是一条CPU的原子指令，其作用是让CPU先进行比较两个值是否相等，然后原子地更新某个位置的值，其实现方式是基于硬件平台的汇编指令，在intel的CPU中，使用的是cmpxchg指令，就是说CAS是靠硬件...
CAS中的ABA问题
冯同学的博客
10-11 1494
CAS中的ABA问题
在jdk1.8中cas+synchronized与segment相比的好处是什么？
04-23
在 JDK1.8 中，使用 CAS（Compare And Swap）和 synchronized（锁）机制实现并发同步。相比于 JDK1.7 中使用的 Segment 机制，CAS 和 synchronized 在性能和并发度上都有所提高。 具体来说，CAS 操作相当于一个乐观锁，当进行操作时，先比较当前内存值是否和预期值相等，如果相等则进行操作，否则不进行操作。这避免了竞争和阻塞，提高了并发度。而 synchronized 在加锁时会阻塞其他的线程，降低了并发度。此外，CAS 操作在执行时也更加轻量级，性能更优。 另外，JDK1.8 中的 ConcurrentHashMap 通过分段锁，从而减少了对全局锁的依赖，也提高了并发度和性能。而在 JDK1.7 中的 ConcurrentHashMap 使用的是 Segment 机制，需要对每个 Segment 加锁，带来了一定的性能损失。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值