您好,登錄后才能下訂單哦!
小編給大家分享一下Atomic有什么用,希望大家閱讀完這篇文章之后都有所收獲,下面讓我們一起去探討吧!
如果是count++操作,使用如下類實(shí)現(xiàn): AtomicInteger count = new AtomicInteger(); count.addAndGet(1);如果是 JDK8,推薦使用 LongAdder 對(duì)象,比 AtomicLong 性能更好(減少樂觀鎖的重試次數(shù))。
首先我們來個(gè)例子:
public class AtomicMain { public static void main(String[] args) throws InterruptedException { ExecutorService service = Executors.newCachedThreadPool(); Count count = new Count(); // 100個(gè)線程對(duì)共享變量進(jìn)行加1 for (int i = 0; i < 100; i++) { service.execute(() -> count.increase()); } // 等待上述的線程執(zhí)行完 service.shutdown(); service.awaitTermination(1, TimeUnit.DAYS); System.out.println("公眾號(hào):Java3y---------"); System.out.println(count.getCount()); } } class Count{ // 共享變量 private Integer count = 0; public Integer getCount() { return count; } public void increase() { count++; } }
你們猜猜得出的結(jié)果是多少?是100嗎?
多運(yùn)行幾次可以發(fā)現(xiàn):結(jié)果是不確定的,可能是95,也可能是98,也可能是100
根據(jù)結(jié)果我們得知:上面的代碼是線程不安全的!如果線程安全的代碼,多次執(zhí)行的結(jié)果是一致的!
我們可以發(fā)現(xiàn)問題所在:count++
并不是原子操作。因?yàn)?code>count++需要經(jīng)過讀取-修改-寫入
三個(gè)步驟。舉個(gè)例子:
如果某一個(gè)時(shí)刻:線程A讀到count的值是10,線程B讀到count的值也是10
線程A對(duì)count++
,此時(shí)count的值為11
線程B對(duì)count++
,此時(shí)count的值也是11(因?yàn)榫€程B讀到的count是10)
所以到這里應(yīng)該知道為啥我們的結(jié)果是不確定了吧。
要將上面的代碼變成線程安全的(每次得出的結(jié)果是100),那也很簡(jiǎn)單,畢竟我們是學(xué)過synchronized鎖的人:
在increase()
加synchronized鎖就好了
public synchronized void increase() { count++; }
無論執(zhí)行多少次,得出的都是100:
從上面的代碼我們也可以發(fā)現(xiàn),只做一個(gè)++
這么簡(jiǎn)單的操作,都用到了synchronized鎖,未免有點(diǎn)小題大做了。
Synchronized鎖是獨(dú)占的,意味著如果有別的線程在執(zhí)行,當(dāng)前線程只能是等待!
于是我們?cè)幼兞康念惥偷菆?chǎng)了!
1.2CAS再來看看
在寫文章之前,本以為對(duì)CAS有一定的了解了(因?yàn)橹耙呀?jīng)看過相關(guān)概念,以為自己理解了)..但真正敲起鍵盤寫的時(shí)候,還是發(fā)現(xiàn)沒完全弄懂...所以再來看看CAS吧。
來源維基百科:
比較并交換(compare and swap, CAS),是原子操作的一種,可用于在多線程編程中實(shí)現(xiàn)不被打斷的數(shù)據(jù)交換操作,從而避免多線程同時(shí)改寫某一數(shù)據(jù)時(shí)由于執(zhí)行順序不確定性以及中斷的不可預(yù)知性產(chǎn)生的數(shù)據(jù)不一致問題。 該操作通過將內(nèi)存中的值與指定數(shù)據(jù)進(jìn)行比較,當(dāng)數(shù)值一樣時(shí)將內(nèi)存中的數(shù)據(jù)替換為新的值。
CAS有3個(gè)操作數(shù):
內(nèi)存值V
舊的預(yù)期值A(chǔ)
要修改的新值B
當(dāng)多個(gè)線程嘗試使用CAS同時(shí)更新同一個(gè)變量時(shí),只有其中一個(gè)線程能更新變量的值(A和內(nèi)存值V相同時(shí),將內(nèi)存值V修改為B),而其它線程都失敗,失敗的線程并不會(huì)被掛起,而是被告知這次競(jìng)爭(zhēng)中失敗,并可以再次嘗試(或者什么都不做)。
我們畫張圖來理解一下:
我們可以發(fā)現(xiàn)CAS有兩種情況:
如果內(nèi)存值V和我們的預(yù)期值A(chǔ)相等,則將內(nèi)存值修改為B,操作成功!
如果內(nèi)存值V和我們的預(yù)期值A(chǔ)不相等,一般也有兩種情況:
重試(自旋)
什么都不做
我們?cè)倮^續(xù)往下看,如果內(nèi)存值V和我們的預(yù)期值A(chǔ)不相等時(shí),應(yīng)該什么時(shí)候重試,什么時(shí)候什么都不做。
1.2.1CAS失敗重試(自旋)
比如說,我上面用了100個(gè)線程,對(duì)count值進(jìn)行加1。我們都知道:如果在線程安全的情況下,這個(gè)count值最終的結(jié)果一定是為100的。那就意味著:每個(gè)線程都會(huì)對(duì)這個(gè)count值實(shí)質(zhì)地進(jìn)行加1。
我繼續(xù)畫張圖來說明一下CAS是如何重試(循環(huán)再試)的:
上面圖只模擬出兩個(gè)線程的情況,但足夠說明問題了。
1.2.2CAS失敗什么都不做
上面是每個(gè)線程都要為count值加1,但我們也可以有這種情況:將count值設(shè)置為5
我也來畫個(gè)圖說明一下:
理解CAS的核心就是:CAS是原子性的,雖然你可能看到比較后再修改(compare and swap)覺得會(huì)有兩個(gè)操作,但終究是原子性的!
原子變量類在java.util.concurrent.atomic
包下,總體來看有這么多個(gè):
我們可以對(duì)其進(jìn)行分類:
基本類型:
AtomicBoolean:布爾型
AtomicInteger:整型
AtomicLong:長(zhǎng)整型
數(shù)組:
AtomicIntegerArray:數(shù)組里的整型
AtomicLongArray:數(shù)組里的長(zhǎng)整型
AtomicReferenceArray:數(shù)組里的引用類型
引用類型:
AtomicReference:引用類型
AtomicStampedReference:帶有版本號(hào)的引用類型
AtomicMarkableReference:帶有標(biāo)記位的引用類型
對(duì)象的屬性:
AtomicIntegerFieldUpdater:對(duì)象的屬性是整型
AtomicLongFieldUpdater:對(duì)象的屬性是長(zhǎng)整型
AtomicReferenceFieldUpdater:對(duì)象的屬性是引用類型
JDK8新增DoubleAccumulator、LongAccumulator、DoubleAdder、LongAdder
是對(duì)AtomicLong等類的改進(jìn)。比如LongAccumulator與LongAdder在高并發(fā)環(huán)境下比AtomicLong更高效。
Atomic包里的類基本都是使用Unsafe實(shí)現(xiàn)的包裝類。
Unsafe里邊有幾個(gè)我們喜歡的方法(CAS):
// 第一和第二個(gè)參數(shù)代表對(duì)象的實(shí)例以及地址,第三個(gè)參數(shù)代表期望值,第四個(gè)參數(shù)代表更新值 public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5); public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5); public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);
從原理上概述就是:Atomic包的類的實(shí)現(xiàn)絕大調(diào)用Unsafe的方法,而Unsafe底層實(shí)際上是調(diào)用C代碼,C代碼調(diào)用匯編,最后生成出一條CPU指令cmpxchg,完成操作。這也就為啥CAS是原子性的,因?yàn)樗且粭lCPU指令,不會(huì)被打斷。
2.1原子變量類使用
既然我們上面也說到了,使用Synchronized鎖有點(diǎn)小題大作了,我們用原子變量類來改一下:
class Count{ // 共享變量(使用AtomicInteger來替代Synchronized鎖) private AtomicInteger count = new AtomicInteger(0); public Integer getCount() { return count.get(); } public void increase() { count.incrementAndGet(); } } // Main方法還是如上
修改完,無論執(zhí)行多少次,我們的結(jié)果永遠(yuǎn)是100!
其實(shí)Atomic包下原子類的使用方式都不會(huì)差太多,了解原子類各種類型,看看API,基本就會(huì)用了(網(wǎng)上也寫得比較詳細(xì),所以我這里果斷偷懶了)...
2.2ABA問題
使用CAS有個(gè)缺點(diǎn)就是ABA的問題,什么是ABA問題呢?首先我用文字描述一下:
現(xiàn)在我有一個(gè)變量count=10
,現(xiàn)在有三個(gè)線程,分別為A、B、C
線程A和線程C同時(shí)讀到count變量,所以線程A和線程C的內(nèi)存值和預(yù)期值都為10
此時(shí)線程A使用CAS將count值修改成100
修改完后,就在這時(shí),線程B進(jìn)來了,讀取得到count的值為100(內(nèi)存值和預(yù)期值都是100),將count值修改成10
線程C拿到執(zhí)行權(quán),發(fā)現(xiàn)內(nèi)存值是10,預(yù)期值也是10,將count值修改成11
上面的操作都可以正常執(zhí)行完的,這樣會(huì)發(fā)生什么問題呢??線程C無法得知線程A和線程B修改過的count值,這樣是有風(fēng)險(xiǎn)的。
下面我再畫個(gè)圖來說明一下ABA的問題(以鏈表為例):
2.3解決ABA問題
要解決ABA的問題,我們可以使用JDK給我們提供的AtomicStampedReference和AtomicMarkableReference類。
AtomicStampedReference:
An {@code AtomicStampedReference} maintains an object referencealong with an integer "stamp", that can be updated atomically.
簡(jiǎn)單來說就是在給為這個(gè)對(duì)象提供了一個(gè)版本,并且這個(gè)版本如果被修改了,是自動(dòng)更新的。
原理大概就是:維護(hù)了一個(gè)Pair對(duì)象,Pair對(duì)象存儲(chǔ)我們的對(duì)象引用和一個(gè)stamp值。每次CAS比較的是兩個(gè)Pair對(duì)象
// Pair對(duì)象 private static class Pair<T> { final T reference; final int stamp; private Pair(T reference, int stamp) { this.reference = reference; this.stamp = stamp; } static <T> Pair<T> of(T reference, int stamp) { return new Pair<T>(reference, stamp); } } private volatile Pair<V> pair; // 比較的是Pari對(duì)象 public boolean compareAndSet(V expectedReference, V newReference, int expectedStamp, int newStamp) { Pair<V> current = pair; return expectedReference == current.reference && expectedStamp == current.stamp && ((newReference == current.reference && newStamp == current.stamp) || casPair(current, Pair.of(newReference, newStamp))); }
因?yàn)槎嗔艘粋€(gè)版本號(hào)比較,所以就不會(huì)存在ABA的問題了。
2.4LongAdder性能比AtomicLong要好
如果是 JDK8,推薦使用 LongAdder 對(duì)象,比 AtomicLong 性能更好(減少樂觀鎖的重試次數(shù))。
去查閱了一些博客和資料,大概的意思就是:
使用AtomicLong時(shí),在高并發(fā)下大量線程會(huì)同時(shí)去競(jìng)爭(zhēng)更新同一個(gè)原子變量,但是由于同時(shí)只有一個(gè)線程的CAS會(huì)成功,所以其他線程會(huì)不斷嘗試自旋嘗試CAS操作,這會(huì)浪費(fèi)不少的CPU資源。
而LongAdder可以概括成這樣:內(nèi)部核心數(shù)據(jù)value分離成一個(gè)數(shù)組(Cell),每個(gè)線程訪問時(shí),通過哈希等算法映射到其中一個(gè)數(shù)字進(jìn)行計(jì)數(shù),而最終的計(jì)數(shù)結(jié)果,則為這個(gè)數(shù)組的求和累加。
簡(jiǎn)單來說就是將一個(gè)值分散成多個(gè)值,在并發(fā)的時(shí)候就可以分散壓力,性能有所提高。
看完了這篇文章,相信你對(duì)“Atomic有什么用”有了一定的了解,如果想了解更多相關(guān)知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道,感謝各位的閱讀!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。