您好,登錄后才能下訂單哦!
今天小編給大家分享一下為什么使用LongAdder而不是volatile的相關(guān)知識點(diǎn),內(nèi)容詳細(xì),邏輯清晰,相信大部分人都還太了解這方面的知識,所以分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后有所收獲,下面我們一起來了解一下吧。
說明:如果是 count++ 操作,使用如下類實(shí)現(xiàn):AtomicInteger count = new AtomicInteger(); count.addAndGet(1); 如果是 JDK8,推薦使用 LongAdder 對象,比 AtomicLong 性能更好(減少樂觀 鎖的重試次數(shù))。
以上內(nèi)容共有兩個重點(diǎn):
類似于 count++ 這種非一寫多讀的場景不能使用 volatile
;
如果是 JDK8 推薦使用 LongAdder
而非 AtomicLong
來替代 volatile
,因?yàn)?LongAdder
的性能更好。
但口說無憑,即使是孤盡大佬說的,咱們也得證實(shí)一下,因?yàn)轳R老爺子說過:實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)。
這樣做也有它的好處,第一,加深了我們對知識的認(rèn)知;第二,文檔上只寫了LongAdder
比 AtomicLong
的性能高,但是高多少呢?文中并沒有說,那只能我們自己動手去測試嘍。
話不多,接下來我們直接進(jìn)入本文正式內(nèi)容...
首先我們來測試 volatile
在多寫環(huán)境下的線程安全情況,測試代碼如下:
public class VolatileExample { public static volatile int count = 0; // 計(jì)數(shù)器 public static final int size = 100000; // 循環(huán)測試次數(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 次,在啟動另一個線程 -- 10w 次,正常來說結(jié)果應(yīng)該是 0,但是我們執(zhí)行的結(jié)果卻為:
1063
結(jié)論:由以上結(jié)果可以看出 volatile
在多寫環(huán)境下是非線程安全的,測試結(jié)果和《Java開發(fā)手冊》相吻合。
接下來,我們使用 Oracle 官方的 JMH(Java Microbenchmark Harness, JAVA 微基準(zhǔn)測試套件)來測試一下兩者的性能,測試代碼如下:
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) // 測試完成時(shí)間@OutputTimeUnit(TimeUnit.NANOSECONDS)@Warmup(iterations = 1, time = 1, timeUnit = TimeUnit.SECONDS) // 預(yù)熱 1 輪,每次 1s@Measurement(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS) // 測試 5 輪,每次 3s@Fork(1) // fork 1 個線程@State(Scope.Benchmark)@Threads(1000) // 開啟 1000 個并發(fā)線程public class AlibabaAtomicTest { public static void main(String[] args) throws RunnerException { // 啟動基準(zhǔn)測試 Options opt = new OptionsBuilder() .include(AlibabaAtomicTest.class.getSimpleName()) // 要導(dǎo)入的測試類 .build(); new Runner(opt).run(); // 執(zhí)行測試 } @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(); } }
從上述的數(shù)據(jù)可以看出,在開啟了 1000 個線程之后,程序的 LongAdder
的性能比 AtomicInteger
快了約 1.53 倍,你沒看出是開了 1000 個線程,為什么要開這么多呢?這其實(shí)是為了模擬高并發(fā)高競爭的環(huán)境下二者的性能查詢。
如果在低競爭下,比如我們開啟 100 個線程
結(jié)論:從上面結(jié)果可以看出,在低競爭的并發(fā)環(huán)境下 AtomicInteger
的性能是要比 LongAdder
的性能好,而高競爭環(huán)境下 LongAdder
的性能比 AtomicInteger
好,當(dāng)有 1000 個線程運(yùn)行時(shí),LongAdder
的性能比 AtomicInteger
快了約 1.53 倍,所以各位要根據(jù)自己業(yè)務(wù)情況選擇合適的類型來使用。
為什么會出現(xiàn)上面的情況?這是因?yàn)?AtomicInteger
在高并發(fā)環(huán)境下會有多個線程去競爭一個原子變量,而始終只有一個線程能競爭成功,而其他線程會一直通過 CAS 自旋嘗試獲取此原子變量,因此會有一定的性能消耗;而 LongAdder
會將這個原子變量分離成一個 Cell 數(shù)組,每個線程通過 Hash 獲取到自己數(shù)組,這樣就減少了樂觀鎖的重試次數(shù),從而在高競爭下獲得優(yōu)勢;而在低競爭下表現(xiàn)的又不是很好,可能是因?yàn)樽约罕旧頇C(jī)制的執(zhí)行時(shí)間大于了鎖競爭的自旋時(shí)間,因此在低競爭下表現(xiàn)性能不如 AtomicInteger
。
以上就是“為什么使用LongAdder而不是volatile”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家閱讀完這篇文章都有很大的收獲,小編每天都會為大家更新不同的知識,如果還想學(xué)習(xí)更多的知識,請關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。