突击并发编程JUC系列-​JDK1.8 扩展类型 LongAdder

> 突击并发编程JUC系列演示代码地址：
> https://github.com/mtcarpenter/JavaTutorial

小伙伴们，大家好，我们又见面了，突击并发编程JUC系列实战JDK1.8 扩展类型马上就要发车了。

JDK 1.8 扩展类型如下

初步了解

前面在讲解AtomicLong,跟大家提到过longAdder , AtomicLong通过CAS提供了非阻塞的原子性操作，相比使用阻塞算法的同步器来说它的性能已经很好了，但是JDK开发组并不满足于此。使用AtomicLong时，在高并发下大量线程会同时去竞争更新同一个原子变量，但是由于同时只有一个线程的CAS操作会成功，这就造成了大量线程竞争失败后，会通过无限循环不断进行自旋尝试CAS的操作，而这会白白浪费CPU资源。

从JDK 8开始，针对Long型的原子操作，Java又提供了LongAdder、LongAccumulator；针对Double类型，Java提供了DoubleAdder、DoubleAccumulator。Striped64相关的类的继承层次如下所示。

LongAdder克服了高并发下使用AtomicLong的缺点。既然AtomicLong的性能瓶颈是由于过多线程同时去竞争一个变量的更新而产生的，LongAdder则是把一个变量分解为多个变量，让同样多的线程去竞争多个资源，解决了性能问题。

使用AtomicLong时，是多个线程同时竞争同一个原子变量。图示如下

使用 longAdder 多个线程同时竞争一个原子变量，图示如下

LongAdder 是把一个变量拆成多份，变为多个变量，有点像 ConcurrentHashMap 中 的分段锁**把一个Long型拆成一个base变量外加多个Cell，每个Cell包装了一个Long型变量。**这样，在同等并发量的情况下，争夺单个变量更新操作的线程量会减少，这变相地减少了争夺共享资源的并发量。
另外，多个线程在争夺同一个Cell原子变量时如果失败了，它并不是在当前Cell变量上一直自旋CAS重试，而是尝试在其他Cell的变量上进行CAS尝试，这个改变增加了当前线程重试CAS成功的可能性。最后，在获取LongAdder当前值时，是把所有Cell变量的value值累加后再加上base返回的。LongAdder维护了一个延迟初始化的原子性更新数组（默认情况下Cell数组是null）和一个基值变量base。由于Cells占用的内存是相对比较大的，所以一开始并不创建它，而是在需要时创建，也就是惰性加载。

案例测试

下面通过 AtomicLong 和 LongAdder 分别对百万雄师求和，为了更好的对分别通过 10 、100 、500个线程并发求和百万雄师数量。

AtomicLong 性能测试

public class AtomicExample10 {

    // 并发线程数
    public static int requestTotal = 500;
    // 求和总数
    public static int sumTotal = 1000000;

    public static AtomicLong count = new AtomicLong(0);


    public static void main(String[] args) throws InterruptedException {
        ExecutorService executorService = Executors.newFixedThreadPool(requestTotal);
        final CountDownLatch countDownLatch = new CountDownLatch(requestTotal);
        long start = System.currentTimeMillis();
        for (int i = 0; i < requestTotal; i++) {
            executorService.execute(() -> {
                add();
                countDownLatch.countDown();
            });


        }
        countDownLatch.await();
        executorService.shutdown();
        System.out.println("count=" + count.get());
        System.out.println("耗时：" + (System.currentTimeMillis() - start));
    }

    private static void add() {
        // 针对 sumTotal 求和
        for (int j = 0; j < sumTotal; j++) {
           count.getAndIncrement();
        }

    }
}

通过 10 、100 、500 个并发线程测试

 // 并发线程数 10
count=10000000
耗时：305
// 并发线程数 100
count=100000000
耗时：2301
// 并发线程数 500
count=500000000
耗时：10865

LongAdder 性能测试

public class AtomicExample11 {

    // 请求总数
    public static int requestTotal = 100;

    public static LongAdder count = new LongAdder();


    public static void main(String[] args) throws InterruptedException {
        final CountDownLatch countDownLatch = new CountDownLatch(requestTotal);
        long start = System.currentTimeMillis();
        for (int i = 0; i < requestTotal; i++) {
            new Thread(() -> {
                try {
                    TimeUnit.MILLISECONDS.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                add();
                countDownLatch.countDown();
            }).start();

        }
        countDownLatch.await();
        System.out.println("count=" + count);
        System.out.println("耗时：" + (System.currentTimeMillis() - start));
    }

    private static void add() {
        count.add(1);
    }

}

通过 10 、100 、500 个并发线程测试

// 并发线程数 10
count=10000000
耗时：110
// 并发线程数 100
count=100000000
耗时：375
// 并发线程数 500
count=500000000
耗时：1451

总结

在以上的测试并发数越多 LongAdder性能越突出，LongAdder 是把一个变量拆成多份，分散到多个变量， 通过内部 cells 数组分担了高并发下多线程同时对一个原子变量进行更新时的竞争量，让多个线程可以同时对 cells 数组里面的元素进行并行的更新操作，其核心实现通过空间来换时间 。

** 我是小春哥，从事 Java 后端开发，会一点前端、通过持续输出系列技术文章以文会友，如果本文能为您提供帮助，欢迎大家关注、 点赞、分享支持，我们下期再见！