使用LongAdder好還是volatile好

今天小編給大家分享一下使用LongAdder好還是volatile好的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

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

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

以上內容共有兩個重點：

1. 類似于 count++ 這種非一寫多讀的場景不能使用 volatile；

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

但口說無憑，即使是孤盡大佬說的，咱們也得證實一下，因為馬老爺子說過：實踐是檢驗真理的唯一標準。

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

（推薦教程：Java教程）

話不多，接下來我們直接進入本文正式內容...

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 來測試一下兩者的性能，測試代碼如下：

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好”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。