詳解Java高并發編程之AtomicReference
我們這里再聊起老生常談的賬戶問題，通過個人銀行賬戶問題，來逐漸引入 AtomicReference 的使用，我們首先來看一下基本的個人賬戶類
public class BankCard { private final String accountName; private final int money; // 構造函數初始化 accountName 和 money public BankCard(String accountName,int money){this.accountName = accountName;this.money = money; } // 不提供任何修改個人賬戶的 set 方法，只提供 get 方法 public String getAccountName() {return accountName; } public int getMoney() {return money; } // 重寫 toString() 方法， 方便打印 BankCard @Override public String toString() {return 'BankCard{' +'accountName=’' + accountName + ’’’ +', money=’' + money + ’’’ +’}’; }}
個人賬戶類只包含兩個字段：accountName 和 money，這兩個字段代表賬戶名和賬戶金額，賬戶名和賬戶金額一旦設置后就不能再被修改。
現在假設有多個人分別向這個賬戶打款，每次存入一定數量的金額，那么理想狀態下每個人在每次打款后，該賬戶的金額都是在不斷增加的，下面我們就來驗證一下這個過程。
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;// 構造一個新的賬戶，存入一定數量的錢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();} }}
在上面的代碼中，我們首先聲明了一個全局變量 BankCard，這個 BankCard 由 volatile進行修飾，目的就是在對其引用進行變化后對其他線程可見，在每個打款人都存入一定數量的款項后，輸出賬戶的金額變化，我們可以觀察一下這個輸出結果。
可以看到，我們預想最后的結果應該是 1100 元，但是最后卻只存入了 900 元，那 200 元去哪了呢？我們可以斷定上面的代碼不是一個線程安全的操作。
問題出現在哪里？
雖然每次 volatile 都能保證每個賬戶的金額都是最新的，但是由于上面的步驟中出現了組合操作，即獲取賬戶引用和更改賬戶引用，每個單獨的操作雖然都是原子性的，但是組合在一起就不是原子性的了。所以最后的結果會出現偏差。
我們可以用如下線程切換圖來表示一下這個過程的變化。
可以看到，最后的結果可能是因為在線程 t1 獲取最新賬戶變化后，線程切換到 t2，t2 也獲取了最新賬戶情況，然后再切換到 t1，t1 修改引用，線程切換到 t2，t2 修改引用，所以賬戶引用的值被修改了兩次。
那么該如何確保獲取引用和修改引用之間的線程安全性呢？
最簡單粗暴的方式就是直接使用 synchronized 關鍵字進行加鎖了。
1.1、使用 synchronized 保證線程安全性使用 synchronized 可以保證共享數據的安全性，代碼如下
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; // 構造一個新的賬戶，存入一定數量的錢 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 鎖，運行 BankCardSyncTest 后我們發現能夠得到正確的結果。
修改 BankCardSyncTest.class 為 bankCard 對象，我們發現同樣能夠確保線程安全性，這是因為在這段程序中，只有 bankCard 會進行變化，不會再有其他共享數據。
如果有其他共享數據的話，我們需要使用 BankCardSyncTest.clas 確保線程安全性。
除此之外，java.util.concurrent.atomic 包下的 AtomicReference 也可以保證線程安全性。
我們先來認識一下 AtomicReference ，然后再使用 AtomicReference 改寫上面的代碼。
二、了解 AtomicReference2.1、使用 AtomicReference 保證線程安全性下面我們改寫一下上面的那個示例
public class BankCardARTest { private static AtomicReference<BankCard> 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 樂觀鎖進行非阻塞更新 if(bankCardRef.compareAndSet(card,newCard)){System.out.println(newCard); } try {TimeUnit.SECONDS.sleep(1); } catch (Exception e) {e.printStackTrace(); }} }).start();} }}
在上面的示例代碼中，我們使用了 AtomicReference 封裝了 BankCard 的引用，然后使用 get() 方法獲得原子性的引用，接著使用 CAS 樂觀鎖進行非阻塞更新，更新的標準是如果使用 bankCardRef.get() 獲取的值等于內存值的話，就會把銀行卡賬戶的資金 + 100，我們觀察一下輸出結果。
可以看到，有一些輸出是亂序執行的，出現這個原因很簡單，有可能在輸出結果之前，進行線程切換，然后打印了后面線程的值，然后線程切換回來再進行輸出，但是可以看到，沒有出現銀行卡金額相同的情況。
2.2、AtomicReference 源碼解析在了解上面這個例子之后，我們來看一下 AtomicReference 的使用方法
AtomicReference 和 AtomicInteger 非常相似，它們內部都是用了下面三個屬性
Unsafe 是 sun.misc 包下面的類，AtomicReference 主要是依賴于 sun.misc.Unsafe 提供的一些 native 方法保證操作的原子性。
Unsafe 的 objectFieldOffset 方法可以獲取成員屬性在內存中的地址相對于對象內存地址的偏移量。這個偏移量也就是 valueOffset ，說得簡單點就是找到這個變量在內存中的地址，便于后續通過內存地址直接進行操作。
value 就是 AtomicReference 中的實際值，因為有 volatile ，這個值實際上就是內存值。
不同之處就在于 AtomicInteger 是對整數的封裝，而 AtomicReference 則對應普通的對象引用。也就是它可以保證你在修改對象引用時的線程安全性。
2.2.1、get and set我們首先來看一下最簡單的 get 、set 方法：
get() : 獲取當前 AtomicReference 的值
set() : 設置當前 AtomicReference 的值
get() 可以原子性的讀取 AtomicReference 中的數據，set() 可以原子性的設置當前的值，因為 get() 和 set() 最終都是作用于 value 變量，而 value 是由 volatile 修飾的，所以 get 、set 相當于都是對內存進行讀取和設置。如下圖所示
volatile 有內存屏障你知道嗎？
內存屏障是啥啊？
內存屏障，也稱內存柵欄，內存柵障，屏障指令等， 是一類同步屏障指令，是 CPU 或編譯器在對內存隨機訪問的操作中的一個同步點，使得此點之前的所有讀寫操作都執行后才可以開始執行此點之后的操作。也是一個讓CPU 處理單元中的內存狀態對其它處理單元可見的一項技術。
CPU 使用了很多優化，使用緩存、指令重排等，其最終的目的都是為了性能，也就是說，當一個程序執行時，只要最終的結果是一樣的，指令是否被重排并不重要。所以指令的執行時序并不是順序執行的，而是亂序執行的，這就會帶來很多問題，這也促使著內存屏障的出現。
語義上，內存屏障之前的所有寫操作都要寫入內存；內存屏障之后的讀操作都可以獲得同步屏障之前的寫操作的結果。因此，對于敏感的程序塊，寫操作之后、讀操作之前可以插入內存屏障。
內存屏障的開銷非常輕量級，但是再小也是有開銷的，LazySet 的作用正是如此，它會以普通變量的形式來讀寫變量。
也可以說是：懶得設置屏障了
2.2.3、getAndSet 方法以原子方式設置為給定值并返回舊值。它的源碼如下
它會調用 unsafe 中的 getAndSetObject 方法，源碼如下
可以看到這個 getAndSet 方法涉及兩個 cpp 實現的方法，一個是 getObjectVolatile ，一個是 compareAndSwapObject 方法，他們用在 do...while 循環中，也就是說，每次都會先獲取最新對象引用的值，如果使用 CAS 成功交換兩個對象的話，就會直接返回 var5 的值，var5 此時應該就是更新前的內存值，也就是舊值。
2.2.4、compareAndSet 方法這就是 AtomicReference 非常關鍵的 CAS 方法了，與 AtomicInteger 不同的是，AtomicReference 是調用的 compareAndSwapObject ，而 AtomicInteger 調用的是 compareAndSwapInt 方法。這兩個方法的實現如下
路徑在 hotspot/src/share/vm/prims/unsafe.cpp 中。
我們之前解析過 AtomicInteger 的源碼，所以我們接下來解析一下 AtomicReference 源碼。
因為對象存在于堆中，所以方法 index_oop_from_field_offset_long 應該是獲取對象的內存地址，然后使用 atomic_compare_exchange_oop 方法進行對象的 CAS 交換。
這段代碼會首先判斷是否使用了 UseCompressedOops，也就是指針壓縮。
這里簡單解釋一下指針壓縮的概念：JVM 最初的時候是 32 位的，但是隨著 64 位 JVM 的興起，也帶來一個問題，內存占用空間更大了 ，但是 JVM 內存最好不要超過 32 G，為了節省空間，在 JDK 1.6 的版本后，我們在 64位中的 JVM 中可以開啟指針壓縮（UseCompressedOops）來壓縮我們對象指針的大小，來幫助我們節省內存空間，在 JDK 8來說，這個指令是默認開啟的。
如果不開啟指針壓縮的話，64 位 JVM 會采用 8 字節（64位）存儲真實內存地址，比之前采用4字節（32位）壓縮存儲地址帶來的問題：
增加了 GC 開銷：64 位對象引用需要占用更多的堆空間，留給其他數據的空間將會減少，從而加快了 GC 的發生，更頻繁的進行 GC。 降低 CPU 緩存命中率：64 位對象引用增大了，CPU 能緩存的 oop 將會更少，從而降低了 CPU 緩存的效率。由于 64 位存儲內存地址會帶來這么多問題，程序員發明了指針壓縮技術，可以讓我們既能夠使用之前 4 字節存儲指針地址，又能夠擴大內存存儲。
可以看到，atomic_compare_exchange_oop 方法底層也是使用了 Atomic:cmpxchg 方法進行 CAS 交換，然后把舊值進行 decode 返回 (我這局限的 C++ 知識，只能解析到這里了，如果大家懂這段代碼一定告訴我，讓我請教一波)
2.2.5、weakCompareAndSet 方法weakCompareAndSet: 非常認真看了好幾遍，發現 JDK1.8 的這個方法和 compareAndSet 方法完全一摸一樣啊，坑我。。。
但是真的是這樣么？并不是，JDK 源碼很博大精深，才不會設計一個重復的方法，你想想 JDK 團隊也不是會犯這種低級團隊，但是原因是什么呢？
《Java 高并發詳解》這本書給出了我們一個答案
以上就是詳解Java高并發編程之AtomicReference的詳細內容，更多關于Java高并發編程 AtomicReference的資料請關注好吧啦網其它相關文章！
相關文章：
網公網安備