JAVA并发编程JUC包之CAS原理

原创

拉丁解牛说技术

发布于 2024-09-06 18:03:33

1210

发布于 2024-09-06 18:03:33

文章被收录于专栏：JAVA并发编程

在JDK 1.5之后，java api中提供了java.util.concurrent包，简称JUC包。这个包定义了很多我们非常熟悉的工具类，比如原子类AtomicXX，线程池executors、信号量semaphore、阻塞队列、同步器等。日常并发编程要用的熟面孔基本都在这里。

首先，Atomic包，原子操作类，提供了用法简单、性能高效、最重要是线程安全的更新一个变量。支持整型、长整型、布尔、double、数组、以及对象的属性原子修改，支持种类非常丰富。

之前的文章《JAVA并发编程volatile核心原理》说过，volatile只是解决了多线程的可见性和有序性问题，原子性问题并没有解决。在这里volatile+Atomic原子类可以完美实现多线程共享变量的安全修改。

1、Atomic原子类并发修改共享变量demo

package lading.java.mutithread;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;

/**
 * 多线程并发下，使用原子类+volatile进行操作，实现共享变量修改并发安全
 * 10个线程并发对共享变量count进行求和,每个线程求和100次，最后结果是1000
 */
public class Demo005AtomicCount {
    public static volatile AtomicInteger count = new AtomicInteger(0);

    public static void main(String[] args) {
        int threadNum = 10;
        ExecutorService threadPool = Executors.newFixedThreadPool(threadNum);
        for (int i = 0; i < threadNum; i++) {
            //10个线程并发对共享变量count进行求和,每个线程求和100次
            threadPool.submit(() -> {
                System.out.println(Thread.currentThread().getName() + "开始对count求和100次");
                for (int j = 0; j < 100; j++) {
                    count.getAndIncrement();
                }
            });
        }
        threadPool.shutdown();
        System.out.println("最后count的值：" + count.get());
    }
}

结果，刚好就是1000.

2、说一下CAS原理

CAS 英文原名compare AND swap（比较再置换）。在JUC包中，大量应用了CAS的原理实现，比如AQS ，concurrentHashMap都有应用CAS技术。可以说，synchronized、volatile、CAS就是JAVA并发编程里的基石。

CAS本质是一条CPU指令，fun(address,oldValue,newValue)，其中Address就是本次操作要读取旧值以及修改为新值的内存地址，oldValue就是该内存地址之前的旧值，newValue就是本次操心希望写入的新值。

核心原理：判断内存地址address当前的值是否与oldValue相同，如果相同就更新该内存地址的值为newValue。

先看一下源码，这个AtomicInteger +1源码：

public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
    }

然后compareAndSwapInt的源码如下：
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

这里this.compareAndSwapInt(var1, var2, var5, var5 + var4));可以看到其实是4个变量，实际就是我们常说的三个变量，因为Object var1表示这个对象内存地址，var2只是偏移量。

这个偏移量有什么用呢?继续看unsafe c++的源码，发现，其实和我们之前讲的JVM内存模型是一样的，一个对象有自己的地址，对象在内存中会占据一段内存区域，这一片区域会有对象的各种信息，比如锁状态，对象头信息，最重要的是还有我们这个对象的值。那如何找到这个值的内存地址呢？

这时候就是需要这个long var2 偏移量。通过这个var2才可以读到当前变量的旧值old。然后拿这个old和预期的oldValue去比对，相等了就把newValue更新到值的内存地址。

3、CAS有什么缺陷吗

在2的核心原理源码看到，很明显，如果发现从内存地址里值不是预期的oldValue，那就陷入了死循环。CAS就是一个while循环判断内存地址值是否等于预期值，不等于就继续循环。

3.1 CAS一直不成功，就会导致CPU自旋时间过长，CPU开销过大。

3.2 A->B->A问题，俗称ABA问题。

举个例子，有个变量name="A",有个线程想把name从A修改为C。但是很不幸在次过程中被别的线程修改为B后，又再修改为A，它才能执行。再具体一点就是：有个人存款有100块，想去取出来，但是取款机显示余额是0，无法取现；过了一会，发现余额是100，这才能取现。这个诡异的过程就是ABA的问题，CAS对变量预期旧值的循环变化是无感的。

4、如何解决CAS的ABA问题

我们先看一下ABA的demo。

package lading.java.mutithread;

import java.util.concurrent.atomic.AtomicInteger;

/**
 * CAS ABA问题复现
 * count 原值100
 */
public class Demo006CasBug {
    public static volatile AtomicInteger count = new AtomicInteger(100);

    public static void main(String[] args) throws InterruptedException {
        //线程1先修改为200，然后马上修改为100
        Thread thread1 = new Thread(() -> {
            count.compareAndSet(100, 200);
            count.compareAndSet(200, 100);
            System.out.println(Thread.currentThread().getName() + "完成对count的从100修改为200，然后再修改为100");
        });
        Thread thread2 = new Thread(() -> {
            count.compareAndSet(100, 300);
            System.out.println(Thread.currentThread().getName() + "对count的从100修改为" + count.get());
        });
        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();
    }
}

结果是线程1无感的修改为300，实际上期间线程0已经修改了2次。

JDK提供了AtomicStampedReference来解决。解决demo：

package lading.java.mutithread;
import java.util.concurrent.atomic.AtomicStampedReference;

/**
 * 解决CAS ABA问题
 * 用AtomicStampedReference，给原子类增加一个时间戳6666，这样每次修改需要增加判断预期的时间戳
 * 类似数据库mysql更新一个记录，update set col1='' where col2=oldVal and timestamp=oldVal
 * 在cas基础上增加一个数据时间戳，确保数据未更新修改过。
 */
public class Demo007CasBugFix {
    public static AtomicStampedReference<Integer> count = new AtomicStampedReference<>(100, 6666);

    public static void main(String[] args) throws InterruptedException {
        //线程1先修改为200，然后马上修改为100
        Thread thread1 = new Thread(() -> {
            System.out.println(Thread.currentThread().getName() + "第一次修改前时间戳版本号：" + count.getStamp());
            count.compareAndSet(100, 200, count.getStamp(), count.getStamp() + 1);
            System.out.println(Thread.currentThread().getName() + "第二次修改前时间戳版本号：" + count.getStamp());
            count.compareAndSet(200, 100, count.getStamp(), count.getStamp() + 1);
            System.out.println(Thread.currentThread().getName() + "完成对count的从100修改为200，然后再修改为100");
        });
        Thread thread2 = new Thread(() -> {
            try {
                Thread.sleep(5);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            System.out.println(Thread.currentThread().getName() + "第三次修改前时间戳版本号：" + count.getStamp());
            boolean isSuccess = count.compareAndSet(100, 300, count.getStamp(), count.getStamp() + 1);
            if (isSuccess) {
                System.out.println(Thread.currentThread().getName() + "修改成功，对count的从100修改为300");
            } else {
                System.out.println(Thread.currentThread().getName() + "修改失败，count值为：" + count.getReference());
            }

        });
        thread1.start();
        thread2.start();
    }
}

结果，因为时间戳已经被修改了，线程1就没法修改cout，避免了ABA问题：