阿里為什么推薦使用LongAdder，而不是volatile？

阿里《Java開發(fā)手冊(cè)》最新嵩山版在不久前發(fā)布，其中有一段內(nèi)容引起了編者的注意，內(nèi)容如下：

【參考】volatile 解決多線程內(nèi)存不可見問題。對(duì)于一寫多讀，是可以解決變量同步問題，但是如果多寫，同樣無法解決線程安全問題。

說明：如果是 count++ 操作，使用如下類實(shí)現(xiàn)：AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 如果是 JDK8，推薦使用 LongAdder 對(duì)象，比 AtomicLong 性能更好（減少樂觀 鎖的重試次數(shù)）。

以上內(nèi)容共有兩個(gè)重點(diǎn)：

1. 類似于 count++ 這種非一寫多讀的場(chǎng)景不能使用 volatile；
2. 如果是 JDK8 推薦使用 LongAdder 而非 AtomicLong 來替代 volatile，因?yàn)?LongAdder 的性能更好。

但口說無憑，即使是孤盡大佬說的，咱們也得證實(shí)一下，因?yàn)轳R老爺子說過：實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)。

這樣做也有它的好處，第一，加深了我們對(duì)知識(shí)的認(rèn)知；第二，文檔上只寫了LongAdder 比 AtomicLong 的性能高，但是高多少呢？文中并沒有說，那只能我們自己動(dòng)手去測(cè)試嘍。

（推薦教程：Java教程）

話不多，接下來我們直接進(jìn)入本文正式內(nèi)容...

volatile 線程安全測(cè)試

首先我們來測(cè)試 volatile 在多寫環(huán)境下的線程安全情況，測(cè)試代碼如下：

public class VolatileExample {
    public static volatile int count = 0; // 計(jì)數(shù)器
    public static final int size = 100000; // 循環(huán)測(cè)試次數(shù)


    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--;
        }
        // 等所有線程執(zhí)行完成
        while (thread.isAlive()) {}
        System.out.println(count); // 打印結(jié)果
    }
}

我們把 volatile 修飾的 count 變量 ++ 10w 次，在啟動(dòng)另一個(gè)線程 -- 10w 次，正常來說結(jié)果應(yīng)該是 0，但是我們執(zhí)行的結(jié)果卻為：

1063

結(jié)論：由以上結(jié)果可以看出 volatile 在多寫環(huán)境下是非線程安全的，測(cè)試結(jié)果和《Java開發(fā)手冊(cè)》相吻合。

LongAdder VS AtomicLong

接下來，我們使用 Oracle 官方的 JMH 來測(cè)試一下兩者的性能，測(cè)試代碼如下：

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) // 測(cè)試完成時(shí)間
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 1, time = 1, timeUnit = TimeUnit.SECONDS) // 預(yù)熱 1 輪，每次 1s
@Measurement(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS) // 測(cè)試 5 輪，每次 3s
@Fork(1) // fork 1 個(gè)線程
@State(Scope.Benchmark)
@Threads(1000) // 開啟 1000 個(gè)并發(fā)線程
public class AlibabaAtomicTest {


    public static void main(String[] args) throws RunnerException {
        // 啟動(dòng)基準(zhǔn)測(cè)試
        Options opt = new OptionsBuilder()
                .include(AlibabaAtomicTest.class.getSimpleName()) // 要導(dǎo)入的測(cè)試類
                .build();
        new Runner(opt).run(); // 執(zhí)行測(cè)試
    }


    @Benchmark
    public int atomicTest(Blackhole blackhole) throws InterruptedException {
        AtomicInteger atomicInteger = new AtomicInteger();
        for (int i = 0; i < 1024; i++) {
            atomicInteger.addAndGet(1);
        }
        // 為了避免 JIT 忽略未被使用的結(jié)果
        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();
    }
}

程序執(zhí)行的結(jié)果為：

從上述的數(shù)據(jù)可以看出，在開啟了 1000 個(gè)線程之后，程序的 LongAdder 的性能比 AtomicInteger 快了約 1.53 倍，你沒看出是開了 1000 個(gè)線程，為什么要開這么多呢？這其實(shí)是為了模擬高并發(fā)高競(jìng)爭(zhēng)的環(huán)境下二者的性能查詢。

如果在低競(jìng)爭(zhēng)下，比如我們開啟 100 個(gè)線程，測(cè)試的結(jié)果如下：

結(jié)論：從上面結(jié)果可以看出，在低競(jìng)爭(zhēng)的并發(fā)環(huán)境下 AtomicInteger的性能是要比 LongAdder 的性能好，而高競(jìng)爭(zhēng)環(huán)境下 LongAdder的性能比 AtomicInteger 好，當(dāng)有 1000 個(gè)線程運(yùn)行時(shí)，LongAdder 的性能比 AtomicInteger 快了約 1.53 倍，所以各位要根據(jù)自己業(yè)務(wù)情況選擇合適的類型來使用。

性能分析

為什么會(huì)出現(xiàn)上面的情況？這是因?yàn)?AtomicInteger 在高并發(fā)環(huán)境下會(huì)有多個(gè)線程去競(jìng)爭(zhēng)一個(gè)原子變量，而始終只有一個(gè)線程能競(jìng)爭(zhēng)成功，而其他線程會(huì)一直通過 CAS 自旋嘗試獲取此原子變量，因此會(huì)有一定的性能消耗；而 LongAdder 會(huì)將這個(gè)原子變量分離成一個(gè) Cell 數(shù)組，每個(gè)線程通過 Hash 獲取到自己數(shù)組，這樣就減少了樂觀鎖的重試次數(shù)，從而在高競(jìng)爭(zhēng)下獲得優(yōu)勢(shì)；而在低競(jìng)爭(zhēng)下表現(xiàn)的又不是很好，可能是因?yàn)樽约罕旧頇C(jī)制的執(zhí)行時(shí)間大于了鎖競(jìng)爭(zhēng)的自旋時(shí)間，因此在低競(jìng)爭(zhēng)下表現(xiàn)性能不如 AtomicInteger。

（推薦微課：Java微課）

總結(jié)

本文我們測(cè)試了 volatile 在多寫情況下是非線程安全的，而在低競(jìng)爭(zhēng)的并發(fā)環(huán)境下 AtomicInteger 的性能是要比 LongAdder 的性能好，而高競(jìng)爭(zhēng)環(huán)境下 LongAdder 的性能比 AtomicInteger 好，因此我們?cè)谑褂脮r(shí)要結(jié)合自身的業(yè)務(wù)情況來選擇相應(yīng)的類型。

文章來源：公眾號(hào)-- Java中文社群 作者：磊哥

以上就是W3Cschool編程獅關(guān)于阿里為什么推薦使用LongAdder，而不是volatile？的相關(guān)介紹了，希望對(duì)大家有所幫助。