为什么使用LongAdder而不是volatile

今天小编给大家分享一下为什么使用LongAdder而不是volatile的相关知识点，内容详细，逻辑清晰，相信大部分人都还太了解这方面的知识，所以分享这篇文章给大家参考一下，希望大家阅读完这篇文章后有所收获，下面我们一起来了解一下吧。

说明：如果是 count++ 操作，使用如下类实现：AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 如果是 JDK8，推荐使用 LongAdder 对象，比 AtomicLong 性能更好（减少乐观 锁的重试次数）。

以上内容共有两个重点：

1. 类似于 count++ 这种非一写多读的场景不能使用 volatile；

2. 如果是 JDK8 推荐使用 LongAdder 而非 AtomicLong 来替代 volatile，因为 LongAdder 的性能更好。

但口说无凭，即使是孤尽大佬说的，咱们也得证实一下，因为马老爷子说过：实践是检验真理的唯一标准。

这样做也有它的好处，第一，加深了我们对知识的认知；第二，文档上只写了LongAdder 比 AtomicLong 的性能高，但是高多少呢？文中并没有说，那只能我们自己动手去测试喽。

话不多，接下来我们直接进入本文正式内容...

volatile 线程安全测试

首先我们来测试 volatile 在多写环境下的线程安全情况，测试代码如下：

public class VolatileExample {
    public static volatile int count = 0; // 计数器    public static final int size = 100000; // 循环测试次数    public static void main(String[] args) {
        // ++ 方式 10w 次        Thread thread = new Thread(() -> {
            for (int i = 1; i <= size; i++) {
                count++;
            }
        });
        thread.start();
        // -- 10w 次        for (int i = 1; i <= size; i++) {
            count--;
        }
        // 等所有线程执行完成        while (thread.isAlive()) {}
        System.out.println(count); // 打印结果    }
}

我们把 volatile 修饰的 count 变量 ++ 10w 次，在启动另一个线程 -- 10w 次，正常来说结果应该是 0，但是我们执行的结果却为：

1063

结论：由以上结果可以看出 volatile 在多写环境下是非线程安全的，测试结果和《Java开发手册》相吻合。

LongAdder VS AtomicLong

接下来，我们使用 Oracle 官方的 JMH（Java Microbenchmark Harness， JAVA 微基准测试套件）来测试一下两者的性能，测试代码如下：

import org.openjdk.jmh.annotations.*;import org.openjdk.jmh.infra.Blackhole;import org.openjdk.jmh.runner.Runner;import org.openjdk.jmh.runner.RunnerException;import org.openjdk.jmh.runner.options.Options;import org.openjdk.jmh.runner.options.OptionsBuilder;import java.util.concurrent.TimeUnit;import java.util.concurrent.atomic.AtomicInteger;import java.util.concurrent.atomic.LongAdder;@BenchmarkMode(Mode.AverageTime) // 测试完成时间@OutputTimeUnit(TimeUnit.NANOSECONDS)@Warmup(iterations = 1, time = 1, timeUnit = TimeUnit.SECONDS) // 预热 1 轮，每次 1s@Measurement(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS) // 测试 5 轮，每次 3s@Fork(1) // fork 1 个线程@State(Scope.Benchmark)@Threads(1000) // 开启 1000 个并发线程public class AlibabaAtomicTest {

    public static void main(String[] args) throws RunnerException {
        // 启动基准测试        Options opt = new OptionsBuilder()
                .include(AlibabaAtomicTest.class.getSimpleName()) // 要导入的测试类                .build();
        new Runner(opt).run(); // 执行测试    }

    @Benchmark    public int atomicTest(Blackhole blackhole) throws InterruptedException {
        AtomicInteger atomicInteger = new AtomicInteger();
        for (int i = 0; i < 1024; i++) {
            atomicInteger.addAndGet(1);
        }
        // 为了避免 JIT 忽略未被使用的结果        return atomicInteger.intValue();
    }

    @Benchmark    public int longAdderTest(Blackhole blackhole) throws InterruptedException {
        LongAdder longAdder = new LongAdder();
        for (int i = 0; i < 1024; i++) {
            longAdder.add(1);
        }
        return longAdder.intValue();
    }
}

从上述的数据可以看出，在开启了 1000 个线程之后，程序的 LongAdder 的性能比 AtomicInteger 快了约 1.53 倍，你没看出是开了 1000 个线程，为什么要开这么多呢？这其实是为了模拟高并发高竞争的环境下二者的性能查询。

如果在低竞争下，比如我们开启 100 个线程

结论：从上面结果可以看出，在低竞争的并发环境下 AtomicInteger 的性能是要比 LongAdder 的性能好，而高竞争环境下 LongAdder 的性能比 AtomicInteger 好，当有 1000 个线程运行时，LongAdder 的性能比 AtomicInteger 快了约 1.53 倍，所以各位要根据自己业务情况选择合适的类型来使用。

性能分析

为什么会出现上面的情况？这是因为 AtomicInteger 在高并发环境下会有多个线程去竞争一个原子变量，而始终只有一个线程能竞争成功，而其他线程会一直通过 CAS 自旋尝试获取此原子变量，因此会有一定的性能消耗；而 LongAdder 会将这个原子变量分离成一个 Cell 数组，每个线程通过 Hash 获取到自己数组，这样就减少了乐观锁的重试次数，从而在高竞争下获得优势；而在低竞争下表现的又不是很好，可能是因为自己本身机制的执行时间大于了锁竞争的自旋时间，因此在低竞争下表现性能不如 AtomicInteger。

以上就是“为什么使用LongAdder而不是volatile”这篇文章的所有内容，感谢各位的阅读！相信大家阅读完这篇文章都有很大的收获，小编每天都会为大家更新不同的知识，如果还想学习更多的知识，请关注亿速云行业资讯频道。