原子操作類AtomicInteger詳解

目錄

爲什麼需要AtomicInteger原子操作類?

要是換成volatile修飾count變量呢?

用了AtomicInteger類後會變成什麼樣子呢?

非阻塞同步


爲什麼需要AtomicInteger原子操作類?

       對於Java中的運算操作,例如自增或自減,若沒有進行額外的同步操作,在多線程環境下就是線程不安全的。num++解析爲num=num+1,明顯,這個操作不具備原子性,多線程併發共享這個變量時必然會出現問題。測試代碼如下:

這裏運行了20個線程,每個線程對count變量進行1000此自增操作,如果上面這段代碼能夠正常併發的話,最後的結果應該是20000纔對,但實際結果卻發現每次運行的結果都不相同,都是一個小於20000的數字。這是爲什麼呢?

要是換成volatile修飾count變量呢?

順帶說下volatile關鍵字很重要的兩個特性:

  1. 保證變量在線程間可見,對volatile變量所有的寫操作都能立即反應到其他線程中,換句話說,volatile變量在各個線程中是一致的(得益於java內存模型—"先行發生原則");
  2. 禁止指令的重排序優化;

那麼換成volatile修飾count變量後,會有什麼效果呢? 試一試:

結果似乎又失望了,測試結果和上面的一致,每次都是輸出小於20000的數字。這又是爲什麼麼? 上面的論據是正確的,也就是上面標紅的內容,但是這個論據並不能得出"基於volatile變量的運算在併發下是安全的"這個結論,因爲核心點在於java裏的運算(比如自增)並不是原子性的。

用了AtomicInteger類後會變成什麼樣子呢?

把上面的代碼改造成AtomicInteger原子類型,先看看效果

結果每次都輸出20000,程序輸出了正確的結果,這都歸功於AtomicInteger.incrementAndGet()方法的原子性。

非阻塞同步

同步:多線程併發訪問共享數據時,保證共享數據再同一時刻只被一個或一些線程使用。

       我們知道,阻塞同步和非阻塞同步都是實現線程安全的兩個保障手段

       非阻塞同步對於阻塞同步而言主要解決了阻塞同步中線程阻塞和喚醒帶來的性能問題,那什麼叫做非阻塞同步呢?在併發環境下,某個線程對共享變量先進行操作,如果沒有其他線程爭用共享數據那操作就成功;如果存在數據的爭用衝突,那就纔去補償措施,比如不斷的重試機制,直到成功爲止,因爲這種樂觀的併發策略不需要把線程掛起,也就把這種同步操作稱爲非阻塞同步(操作和衝突檢測具備原子性)。

       在硬件指令集的發展驅動下,使得 "操作和衝突檢測" 這種看起來需要多次操作的行爲只需要一條處理器指令便可以完成,這些指令中就包括非常著名的CAS指令(Compare-And-Swap比較並交換)。《深入理解Java虛擬機第二版.周志明》第十三章中這樣描述關於CAS機制:

所以再返回來看AtomicInteger.incrementAndGet()方法,它的時間也比較簡單

incrementAndGet()方法在一個無限循環體內,不斷嘗試將一個比當前值大1的新值賦給自己,如果失敗則說明在執行"獲取-設置"操作的時已經被其它線程修改過了,於是便再次進入循環下一次操作,直到成功爲止。這個便是AtomicInteger原子性的"訣竅"了,繼續進源碼看它的compareAndSet方法:

可以看到,compareAndSet()調用的就是Unsafe.compareAndSwapInt()方法,即Unsafe類的CAS操作。

發佈了75 篇原創文章 · 獲贊 79 · 訪問量 14萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章