建站
咨詢
售后
建站咨詢
新聞中心
我們之前了解過了 AtomicInteger、AtomicLong、AtomicBoolean 等原子性工具類，下面我們繼續(xù)了解一下位于 java.util.concurrent.atomic 包下的工具類。
創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),太仆寺企業(yè)網(wǎng)站建設(shè),太仆寺品牌網(wǎng)站建設(shè),網(wǎng)站定制,太仆寺網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,太仆寺網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
關(guān)于 AtomicInteger、AtomicLong、AtomicBoolean 相關(guān)的內(nèi)容請(qǐng)查閱
一場(chǎng) Atomic XXX 的魔幻之旅
關(guān)于 AtomicReference 這種 JDK 工具類的了解的文章比較枯燥，并不是代表著文章質(zhì)量的下降，因?yàn)槲蚁敫愠鲆徽?bestJavaer 的全方位解析，那就勢(shì)必離不開對(duì) JDK 工具類的了解。
記住：技術(shù)要做長線。
AtomicReference 基本使用
我們這里再聊起老生常談的賬戶問題，通過個(gè)人銀行賬戶問題，來逐漸引入 AtomicReference 的使用，我們首先來看一下基本的個(gè)人賬戶類
- public class BankCard {
- private final String accountName;
- private final int money;
- // 構(gòu)造函數(shù)初始化 accountName 和 money
- public BankCard(String accountName,int money){
- this.accountName = accountName;
- this.money = money;
- }
- // 不提供任何修改個(gè)人賬戶的 set 方法，只提供 get 方法
- public String getAccountName() {
- return accountName;
- }
- public int getMoney() {
- return money;
- }
- // 重寫 toString() 方法， 方便打印 BankCard
- @Override
- public String toString() {
- return "BankCard{" +
- "accountName='" + accountName + '\'' +
- ", money='" + money + '\'' +
- '}';
- }
- }
個(gè)人賬戶類只包含兩個(gè)字段：accountName 和 money，這兩個(gè)字段代表賬戶名和賬戶金額，賬戶名和賬戶金額一旦設(shè)置后就不能再被修改。
現(xiàn)在假設(shè)有多個(gè)人分別向這個(gè)賬戶打款，每次存入一定數(shù)量的金額，那么理想狀態(tài)下每個(gè)人在每次打款后，該賬戶的金額都是在不斷增加的，下面我們就來驗(yàn)證一下這個(gè)過程。
- public class BankCardTest {
- private static volatile BankCard bankCard = new BankCard("cxuan",100);
- public static void main(String[] args) {
- for(int i = 0;i < 10;i++){
- new Thread(() -> {
- // 先讀取全局的引用
- final BankCard card = bankCard;
- // 構(gòu)造一個(gè)新的賬戶，存入一定數(shù)量的錢
- BankCard newCard = new BankCard(card.getAccountName(),card.getMoney() + 100);
- System.out.println(newCard);
- // 最后把新的賬戶的引用賦給原賬戶
- bankCard = newCard;
- try {
- TimeUnit.MICROSECONDS.sleep(1000);
- }catch (Exception e){
- e.printStackTrace();
- }
- }).start();
- }
- }
- }
在上面的代碼中，我們首先聲明了一個(gè)全局變量 BankCard，這個(gè) BankCard 由 volatile進(jìn)行修飾，目的就是在對(duì)其引用進(jìn)行變化后對(duì)其他線程可見，然后每個(gè)打款人都存入一定數(shù)量的款項(xiàng)后，輸出賬戶的金額變化，我們可以觀察一下這個(gè)輸出結(jié)果。
可以看到，我們預(yù)想最后的結(jié)果應(yīng)該是 1100 元，但是最后卻只存入了 900 元，那 200 元去哪了呢?我們可以斷定上面的代碼不是一個(gè)線程安全的操作。
問題出現(xiàn)在哪里?
雖然每次 volatile 都能保證每個(gè)賬戶的金額都是最新的，但是由于上面的步驟中出現(xiàn)了組合操作，即獲取賬戶引用和更改賬戶引用，每個(gè)單獨(dú)的操作雖然都是原子性的，但是組合在一塊就不是原子性的了。所以最后的結(jié)果會(huì)出現(xiàn)偏差。
我們可以用如下線程切換圖來表示一下這個(gè)過程的變化。
可以看到，最后的結(jié)果可能是因?yàn)樵诰€程 t1 獲取最新賬戶變化后，線程切換到 t2，t2 也獲取了最新賬戶情況，然后再切換到 t1，t1 修改引用，線程切換到 t2，t2 修改引用，所以賬戶引用的值被修改了兩次。
那么該如何確保獲取引用和修改引用之間的線程安全性呢?
最簡單粗暴的方式就是直接使用 synchronized 關(guān)鍵字進(jìn)行加鎖了。
使用 synchronized 保證線程安全性
使用 synchronized 可以保證共享數(shù)據(jù)的安全性，代碼如下
- public class BankCardSyncTest {
- private static volatile BankCard bankCard = new BankCard("cxuan",100);
- public static void main(String[] args) {
- for(int i = 0;i < 10;i++){
- new Thread(() -> {
- synchronized (BankCardSyncTest.class) {
- // 先讀取全局的引用
- final BankCard card = bankCard;
- // 構(gòu)造一個(gè)新的賬戶，存入一定數(shù)量的錢
- BankCard newCard = new BankCard(card.getAccountName(), card.getMoney() + 100);
- System.out.println(newCard);
- // 最后把新的賬戶的引用賦給原賬戶
- bankCard = newCard;
- try {
- TimeUnit.MICROSECONDS.sleep(1000);
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- }).start();
- }
- }
- }
相較于 BankCardTest ，BankCardSyncTest 增加了 synchronized 鎖，運(yùn)行 BankCardSyncTest 后我們發(fā)現(xiàn)能夠得到正確的結(jié)果。
修改 BankCardSyncTest.class 為 bankCard 對(duì)象，我們發(fā)現(xiàn)同樣能夠確保線程安全性，這是因?yàn)樵谶@段程序中，只有 bankCard 會(huì)進(jìn)行變化，不會(huì)再有其他共享數(shù)據(jù)。
如果有其他共享數(shù)據(jù)的話，我們需要使用 BankCardSyncTest.clas 確保線程安全性。
除此之外，java.util.concurrent.atomic 包下的 AtomicReference 也可以保證線程安全性。
我們先來認(rèn)識(shí)一下 AtomicReference ，然后再使用 AtomicReference 改寫上面的代碼。
了解 AtomicReference
使用 AtomicReference 保證線程安全性
下面我們改寫一下上面的那個(gè)示例
- public class BankCardARTest {
- private static AtomicReference
bankCardRef = new AtomicReference<>(new BankCard("cxuan",100)); - public static void main(String[] args) {
- for(int i = 0;i < 10;i++){
- new Thread(() -> {
- while (true){
- // 使用 AtomicReference.get 獲取
- final BankCard card = bankCardRef.get();
- BankCard newCard = new BankCard(card.getAccountName(), card.getMoney() + 100);
- // 使用 CAS 樂觀鎖進(jìn)行非阻塞更新
- if(bankCardRef.compareAndSet(card,newCard)){
- System.out.println(newCard);
- }
- try {
- TimeUnit.SECONDS.sleep(1);
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- }).start();
- }
- }
- }
在上面的示例代碼中，我們使用了 AtomicReference 封裝了 BankCard 的引用，然后使用 get() 方法獲得原子性的引用，接著使用 CAS 樂觀鎖進(jìn)行非阻塞更新，更新的標(biāo)準(zhǔn)是如果使用 bankCardRef.get() 獲取的值等于內(nèi)存值的話，就會(huì)把銀行卡賬戶的資金 + 100，我們觀察一下輸出結(jié)果。
可以看到，有一些輸出是亂序執(zhí)行的，出現(xiàn)這個(gè)原因很簡單，有可能在輸出結(jié)果之前，進(jìn)行線程切換，然后打印了后面線程的值，然后線程切換回來再進(jìn)行輸出，但是可以看到，沒有出現(xiàn)銀行卡金額相同的情況。
AtomicReference 源碼解析
在了解上面這個(gè)例子之后，我們來看一下 AtomicReference 的使用方法
AtomicReference 和 AtomicInteger 非常相似，它們內(nèi)部都是用了下面三個(gè)屬性
Unsafe 是 sun.misc 包下面的類，AtomicReference 主要是依賴于 sun.misc.Unsafe 提供的一些 native 方法保證操作的原子性。
Unsafe 的 objectFieldOffset 方法可以獲取成員屬性在內(nèi)存中的地址相對(duì)于對(duì)象內(nèi)存地址的偏移量。這個(gè)偏移量也就是 valueOffset ，說得簡單點(diǎn)就是找到這個(gè)變量在內(nèi)存中的地址，便于后續(xù)通過內(nèi)存地址直接進(jìn)行操作。
value 就是 AtomicReference 中的實(shí)際值，因?yàn)橛?volatile ，這個(gè)值實(shí)際上就是內(nèi)存值。
不同之處就在于 AtomicInteger 是對(duì)整數(shù)的封裝，而 AtomicReference 則對(duì)應(yīng)普通的對(duì)象引用。也就是它可以保證你在修改對(duì)象引用時(shí)的線程安全性。
get and set
我們首先來看一下最簡單的 get 、set 方法：
get() : 獲取當(dāng)前 AtomicReference 的值
set() : 設(shè)置當(dāng)前 AtomicReference 的值
get() 可以原子性的讀取 AtomicReference 中的數(shù)據(jù)，set() 可以原子性的設(shè)置當(dāng)前的值，因?yàn)?get() 和 set() 最終都是作用于 value 變量，而 value 是由 volatile 修飾的，所以 get 、set 相當(dāng)于都是對(duì)內(nèi)存進(jìn)行讀取和設(shè)置。
lazySet 方法
volatile 有內(nèi)存屏障你知道嗎?
內(nèi)存屏障是啥啊?
內(nèi)存屏障，也稱內(nèi)存柵欄，內(nèi)存柵障，屏障指令等， 是一類同步屏障指令，是 CPU 或編譯器在對(duì)內(nèi)存隨機(jī)訪問的操作中的一個(gè)同步點(diǎn)，使得此點(diǎn)之前的所有讀寫操作都執(zhí)行后才可以開始執(zhí)行此點(diǎn)之后的操作。也是一個(gè)讓CPU 處理單元中的內(nèi)存狀態(tài)對(duì)其它處理單元可見的一項(xiàng)技術(shù)。
CPU 使用了很多優(yōu)化，使用緩存、指令重排等，其最終的目的都是為了性能，也就是說，當(dāng)一個(gè)程序執(zhí)行時(shí)，只要最終的結(jié)果是一樣的，指令是否被重排并不重要。所以指令的執(zhí)行時(shí)序并不是順序執(zhí)行的，而是亂序執(zhí)行的，這就會(huì)帶來很多問題，這也促使著內(nèi)存屏障的出現(xiàn)。
語義上，內(nèi)存屏障之前的所有寫操作都要寫入內(nèi)存;內(nèi)存屏障之后的讀操作都可以獲得同步屏障之前的寫操作的結(jié)果。因此，對(duì)于敏感的程序塊，寫操作之后、讀操作之前可以插入內(nèi)存屏障。
內(nèi)存屏障的開銷非常輕量級(jí)，但是再小也是有開銷的，LazySet 的作用正是如此，它會(huì)以普通變量的形式來讀寫變量。
也可以說是：懶得設(shè)置屏障了
getAndSet 方法
以原子方式設(shè)置為給定值并返回舊值。它的源碼如下
它會(huì)調(diào)用 unsafe 中的 getAndSetObject 方法，源碼如下
可以看到這個(gè) getAndSet 方法涉及兩個(gè) cpp 實(shí)現(xiàn)的方法，一個(gè)是 getObjectVolatile ，一個(gè)是 compareAndSwapObject 方法，他們用在 do...while 循環(huán)中，也就是說，每次都會(huì)先獲取最新對(duì)象引用的值，如果使用 CAS 成功交換兩個(gè)對(duì)象的話，就會(huì)直接返回 var5 的值，var5 此時(shí)應(yīng)該就是更新前的內(nèi)存值，也就是舊值。
compareAndSet 方法
這就是 AtomicReference 非常關(guān)鍵的 CAS 方法了，與 AtomicInteger 不同的是，AtomicReference 是調(diào)用的 compareAndSwapObject ，而 AtomicInteger 調(diào)用的是 compareAndSwapInt 方法。這兩個(gè)方法的實(shí)現(xiàn)如下
路徑在 hotspot/src/share/vm/prims/unsafe.cpp 中。
我們之前解析過 AtomicInteger 的源碼，所以我們接下來解析一下 AtomicReference 源碼。
因?yàn)閷?duì)象存在于堆中，所以方法 index_oop_from_field_offset_long 應(yīng)該是獲取對(duì)象的內(nèi)存地址，然后使用 atomic_compare_exchange_oop 方法進(jìn)行對(duì)象的 CAS 交換。
這段代碼會(huì)首先判斷是否使用了 UseCompressedOops，也就是指針壓縮。
這里簡單解釋一下指針壓縮的概念：JVM 最初的時(shí)候是 32 位的，但是隨著 64 位 JVM 的興起，也帶來一個(gè)問題，內(nèi)存占用空間更大了 ，但是 JVM 內(nèi)存最好不要超過 32 G，為了節(jié)省空間，在 JDK 1.6 的版本后，我們?cè)?64位中的 JVM 中可以開啟指針壓縮(UseCompressedOops)來壓縮我們對(duì)象指針的大小，來幫助我們節(jié)約內(nèi)存空間，在 JDK 8來說，這個(gè)指令是默認(rèn)開啟的。
如果不開啟指針壓縮的話，64 位 JVM 會(huì)采用 8 字節(jié)(64位)存儲(chǔ)真實(shí)內(nèi)存地址，比之前采用4字節(jié)(32位)壓縮存儲(chǔ)地址帶來的問題：
- 增加了 GC 開銷：64 位對(duì)象引用需要占用更多的堆空間，留給其他數(shù)據(jù)的空間將會(huì)減少， 從而加快了 GC 的發(fā)生，更頻繁的進(jìn)行 GC。
- 降低 CPU 緩存命中率：64 位對(duì)象引用增大了，CPU 能緩存的 oop 將會(huì)更少，從而降低了 CPU 緩存的效率。
由于 64 位存儲(chǔ)內(nèi)存地址會(huì)帶來這么多問題，程序員發(fā)明了指針壓縮技術(shù)，可以讓我們既能夠使用之前 4 字節(jié)存儲(chǔ)指針地址，又能夠擴(kuò)大內(nèi)存存儲(chǔ)。
可以看到，atomic_compare_exchange_oop 方法底層也是使用了 Atomic:cmpxchg 方法進(jìn)行 CAS 交換，然后把舊值進(jìn)行 decode 返回 (我這局限的 C++ 知識(shí)，只能解析到這里了，如果大家懂這段代碼一定告訴我，讓我請(qǐng)教一波)
weakCompareAndSet 方法
weakCompareAndSet: 媽的非常認(rèn)真看了好幾遍，發(fā)現(xiàn) JDK1.8 的這個(gè)方法和 compareAndSet 方法完全一摸一樣啊，坑我。。。
但是真的是這樣么?并不是，JDK 源碼很博大精深，才不會(huì)設(shè)計(jì)一個(gè)重復(fù)的方法，你想想 JDK 團(tuán)隊(duì)也不是會(huì)犯這種低級(jí)團(tuán)隊(duì)，但是原因是什么呢?
《Java 高并發(fā)詳解》這本書給出了我們一個(gè)答案。
總結(jié)
此篇文章主要介紹了 AtomicReference 的出現(xiàn)背景，AtomicReference 的使用場(chǎng)景，以及介紹了 AtomicReference 的源碼，重點(diǎn)方法的源碼分析。此篇 AtomicReference 的文章基本上涵蓋了網(wǎng)絡(luò)上所有關(guān)于 AtomicReference 的內(nèi)容了，遺憾的是就是 cpp 源碼可能分析的不是很到位，這需要充足的 C/C++ 編程知識(shí)，如果有讀者朋友們有最新的研究成果，請(qǐng)及時(shí)告訴我。
本文轉(zhuǎn)載自微信公眾號(hào)「Java建設(shè)者」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java建設(shè)者公眾號(hào)。
文章題目：為什么要有 AtomicReference ？
網(wǎng)頁地址：http://fisionsoft.com.cn/article/dpjjdch.html
