AtomicXXX 用得好好的，阿里为什么推荐使用 LongAdder？面试必问

悠悠 2023-09-28 11:21 58阅读 0赞

## 面试连环炮 ##

先来一连炮简单的面试，看你能顶住几轮？

--------------------

**栈长：**

> **1、多线程情况下，进行数字累加（count++）要注意什么？**

张三：

> 要注意给累加方法加同步锁，不然会出现变量可见性问题，变量值被其他线程覆盖出现不一致的情况

**栈长：**

> **2、保证变量的可见性，用 volatile 修饰不就行了吗？**

张三：

> volatile 是可以保证可见性，但不能保证原子性和线程安全

**栈长：**

> **3、除了加同步锁这种方案，还有别的方法吗？**

张三：

> 还可以用 JDK 中的原子类，比如：AtomicInteger、AtomicLong，它们是通过 CAS 算法实现的一种乐观主义

**栈长：**

> **4、不错，还知道别的么？**

张三：

> 呃……

--------------------

认真的，你能顶住几轮？

这些问题是 Java 程序员面试过程中必问的，出场率贼高，Java 程序员必懂，这些题在Java面试库小程序中也都有详细答案，这里就不展开了。

**你还知道别的么？最后一轮的答案就是今天的主题！**

## 更好的选择：LongAdder ##

你还在用 AtomicInteger、AtomicLong 原子类进行并发累加操作吗？那你就 OUT 了！

除了 AtomicInteger、AtomicLong，其实在 JDK 8 中更建议使用 **LongAdder** 进行原子性操作，性能更好，如果你使用的还是 JDK 7-，那当我没说，即使如此，也不能找借口不知道，毕竟 JDK 8 是现在的主流应用版本了。

**阿里巴巴最新的 Java开发手册 是这么定义的：**

![9dc8d2d95cf9ae2bd4c74f94f415540b.png][]

这份阿里巴巴完整的 Java 开发手册，可以关注公众号：爱穿格子衫的程序猿，即可下载高清完整版。

如果你还没有用过 **LongAdder**，不妨看看本文，刷新你的认知，栈长带你涨知识！

## 为什么搞出了 LongAdder？ ##

我们都知道在 JDK 5 中搞出了 AtomicInteger、AtomicLong 等原子类，这也是在 JDK 8 之前普遍用的原子性操作类，来看下 AtomicLong 的累加源码：

![bf5081e86cd964aa18ebdcb86f42e5ed.png][]

大家都知道这些原子类都是通过 CAS 算法实现的乐观锁，通过旧值和现有的值不断循环比对，直到比对成功才修改成功结束循环。

这样就会有一个问题，如果并发数很高的话，就会造成过多的没有必要的 "***循环***"，这势必会影响 CPU 的性能。

所以，JDK 8 又搞出来了一个 **LongAdder**，也在 atomic 包下：

![80573ccfc711e7d3f05d6d5aaeb25cf3.png][]

大家可以看到，在同级宝箱中还有一个 LongAccumulator 类，这个这篇不展开，栈长下次再另开一篇具体分析，写完我会第一时间进行推送。

## LongAdder 为什么性能更好？ ##

来分析下 LongAdder 类的源码：

![242f1f1770e3470be74010d467033e85.png][]

累加

在 LongAdder 中维护了一个 Cell 数组，当 Cell 它不为空时，size 是 2 的次幂大小，每个 Cell 数组里面都有一个初始值为 0 的 long 变量，用来存储每个 Cell 的值：

![df8cc461045fb22631ffe9a0d2088787.png][]

Cell 类源码

然后其中的 sum 方法用来对 Cell 数组进行求和再加上 base 基础值进行返回：

![15f96dcaed9e2e3cb5d44f49f0c2d0d1.png][]

求和

**关于 base 基础值：**

LongAdder 并不会一开始就创建 Cell 数组，其本身也会维护一个 base 基础值，当 CAS 更新失败时才进行创建或者扩容。

**来看下 AtomicXXX 和 LongAdder 更新对比图：**

![950c252694ef84c2d021052659cadf16.png][]

来源：https://acet.pe.kr/809

Cell 数组相当于一个分段的概念，把 AtomicXXX 中的一个值分成了多个值进行管理，当 CAS 更新失败时不再当前循环重试，而是尝试获取其他的资源锁，这样就降低了对于 AtomicXXX 中间是单个资源的竞争，所以 LongAdder 的性能更高。

**虽然 LongAdder 性能更好，那有没有缺点呢？**

LongAdder 带来了良好的性能，代价肯定也是有的，既然维护了 Cell 数组，也就意味着要占用更多的内存空间，以空间换时间，也是值得的。

## 实战测试 ##

既然官方都说在高并发的情况下性能更好，事实是否如此呢？

栈长必须实战测试一翻，打消大家的疑虑！

**AtomicLong 测试代码：**

/**
     * @author: 栈长
     * @from: 公众号Java技术栈
     */
    private static void atomicLongTest() throws InterruptedException {
        long start = System.currentTimeMillis();
        ExecutorService es = Executors.newFixedThreadPool(MAX_POOL_SIZE);
        for (int i = 0; i < MAX_POOL_SIZE; i++) {
            es.execute(() -> {
                for (int j = 0; j < MAX_LOOP_SIZE; j++) {
                    atomicLong.incrementAndGet();
                }
            });
        }
        es.shutdown();
        es.awaitTermination(5, TimeUnit.MINUTES);
        System.out.printf("AtomicLong %s*%s 结果：%s，耗时：%sms.\n",
                MAX_POOL_SIZE,
                MAX_LOOP_SIZE,
                atomicLong.get(),
                (System.currentTimeMillis() - start));
    }

**LongAdder 测试代码：**

/**
     * @author: 栈长
     * @from: 公众号Java技术栈
     */
    private static void longAdderTest() throws InterruptedException {
        long start = System.currentTimeMillis();
        ExecutorService es = Executors.newFixedThreadPool(MAX_POOL_SIZE);
        for (int i = 0; i < MAX_POOL_SIZE; i++) {
            es.execute(() -> {
                for (int j = 0; j < MAX_LOOP_SIZE; j++) {
                    longAdder.increment();
                }
            });
        }
        es.shutdown();
        es.awaitTermination(5, TimeUnit.MINUTES);
        System.out.printf("LongAdder %s*%s 结果：%s，耗时：%sms.\n",
                MAX_POOL_SIZE,
                MAX_LOOP_SIZE,
                longAdder.sum(),
                (System.currentTimeMillis() - start));
    }

这里只贴核心测试代码了，完整代码已上传到了 Github：

> https://github.com/javastacks/javastack

**测试结果：**

![555fe3655d2a39493365ada5171980dd.png][]

这里测试的只有是 **1 个线程**，每个线程循环**累加 1 次**，这个没有锁竞争、没有高并发操作的场景就能看出性能上的差异了。。

栈长再不断提升 **线程数、循环累加次数** ，得到了以下测试结果：

线程数 \* 循环次数AtomicLongLongAdder1 \* 145ms1ms10 \* 1055ms2ms10 \* 10056ms2ms100 \* 1058ms10ms100 \* 10074ms10ms1000 \* 10190ms71ms1000 \* 100217ms73ms1000 \* 1000194ms81ms1000 \* 10000301ms114ms1000 \* 1000001813ms277ms1000 \* 100000017596ms1629ms

图表对比：

![56a958d89a160557c7b82d766cbd8b5c.png][]

从测试结果可以看出，LongAdder 的性能都是碾压 AtomicLong 的，最高可达 28 多倍的差距（56/2），可以说在高性能要求的高并发场景，肯定是有必要用 LongAdder 的，这也是阿里巴巴为什么建议使用 LongAdder 的原因。

当然，这只是我个人的测试，这个也和硬件配置有关系的，但毋庸置疑是，AtomicLong 的性能是更好的。

## 总结 ##

本文以一场面试连环炮揭开了 LongAdder 的面纱，怎么解决 count++ 的线程安全性问题？

栈长再总结下：

*  累加方法加 synchronized/ Lock 同步锁；
 *  使用 AtomicInteger/ AtomicLong 原子类；
 *  **使用 LongAdder 原子类（推荐使用）；**

LongAdder 这个东西是 Java 8 搞出来的，用来代替 AtomicXXX，不管是否高并发场景，都完胜 AtomicXXX，它不仅可以改善性能，现在面试也问的越来越多了，大家还是有必要掌握。

虽然 LongAdder 性能更好，但也是以更多的内存空间消耗为代价的，当然，现代计算机，内存早已不是瓶颈，所以这点消耗是可以忽略不计的，性能还是最重要的，但是大家也要知道这个点。

本文实战源代码完整版已经上传：

> https://github.com/javastacks/javastack

好了，今天的分享就到这里了!

![4a4f4f3fa92b4c06853f0299fa2eacbb.jpeg][]

[9dc8d2d95cf9ae2bd4c74f94f415540b.png]: https://img-blog.csdnimg.cn/img_convert/9dc8d2d95cf9ae2bd4c74f94f415540b.png
[bf5081e86cd964aa18ebdcb86f42e5ed.png]: https://img-blog.csdnimg.cn/img_convert/bf5081e86cd964aa18ebdcb86f42e5ed.png
[80573ccfc711e7d3f05d6d5aaeb25cf3.png]: https://img-blog.csdnimg.cn/img_convert/80573ccfc711e7d3f05d6d5aaeb25cf3.png
[242f1f1770e3470be74010d467033e85.png]: https://img-blog.csdnimg.cn/img_convert/242f1f1770e3470be74010d467033e85.png
[df8cc461045fb22631ffe9a0d2088787.png]: https://img-blog.csdnimg.cn/img_convert/df8cc461045fb22631ffe9a0d2088787.png
[15f96dcaed9e2e3cb5d44f49f0c2d0d1.png]: https://img-blog.csdnimg.cn/img_convert/15f96dcaed9e2e3cb5d44f49f0c2d0d1.png
[950c252694ef84c2d021052659cadf16.png]: https://img-blog.csdnimg.cn/img_convert/950c252694ef84c2d021052659cadf16.png
[555fe3655d2a39493365ada5171980dd.png]: https://img-blog.csdnimg.cn/img_convert/555fe3655d2a39493365ada5171980dd.png
[56a958d89a160557c7b82d766cbd8b5c.png]: https://img-blog.csdnimg.cn/img_convert/56a958d89a160557c7b82d766cbd8b5c.png
[4a4f4f3fa92b4c06853f0299fa2eacbb.jpeg]: https://img-blog.csdnimg.cn/4a4f4f3fa92b4c06853f0299fa2eacbb.jpeg