阿裡為什麼推薦使用LongAdder，而不是AtomicLong？

阿裡《Java開發手冊》最新嵩山版在 8.3 日釋出，其中有一段内容引起了老王的注意，内容如下：

【參考】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​

​。

總結