【漫畫】CAS原理分析!無鎖原子類也能解決併發問題!
阿新 • • 發佈:2020-05-19
> 本文來源於微信公眾號【胖滾豬學程式設計】、轉載請註明出處
在漫畫併發程式設計系統博文中,我們講了N篇關於鎖的知識,確實,鎖是解決併發問題的萬能鑰匙,可是併發問題只有鎖能解決嗎?今天要出場一個大BOSS:CAS無鎖演算法,可謂是併發程式設計核心中的核心!
![_1](https://yqfile.alicdn.com/ace443f0e423a535bef405deb0907815a1992df7.jpeg)
# 溫故
首先我們再回顧一下原子性問題的原因,參考[【漫畫】JAVA併發程式設計 如何解決原子性問題](https://mp.weixin.qq.com/s?__biz=MzA3MjY1MTcyNw==&mid=2247484289&idx=1&sn=381562e6dccaa61eaa26b7301f162b5e&chksm=9f1a4521a86dcc3747f6dc986b16d6dc8d1f75434c0f56eb99ce9fbb8ebdfbaa85c33f11f740&token=23367173&lang=zh_CN#rd)。
![image.png](https://img2020.cnblogs.com/other/2027276/202005/2027276-20200518221800980-485780981.png)
兩個執行緒同時把count=0載入到自己的工作記憶體,執行緒B先執行count++操作,此時主記憶體已經變化成了1,但是**執行緒A依舊以為count=0,這是導致問題的根源**。
所以解決方案就是:**不能讓執行緒A以為count=0**,而是要和主記憶體進行一次**compare(比較)**,如果記憶體中的值是0,說明沒有其他執行緒更新過count值,那麼就**swap(交換)**,把新值寫回主記憶體。如果記憶體中的值不是0,比如本案例中,記憶體中count就已經被執行緒B更新成了1,比較0!=1,因此compare失敗,不把新值寫回主記憶體。
![_2](https://yqfile.alicdn.com/ca2c8b3e780d77d969af83c71419fd2fae7f4ce8.jpeg)
> 本文來源於微信公眾號【胖滾豬學程式設計】。一個集顏值與才華於一身的女程式媛、以漫畫形式讓程式設計so easy and interesting!轉載請註明出處
# CAS概念
CAS (compareAndSwap),中文叫比較交換,一種**無鎖原子演算法**。
**CAS演算法包含 3 個引數 CAS(V,E,N),V表示要更新變數在記憶體中的值,E表示舊的預期值,N表示新值。**
**僅當 V值等於E值時,才會將V的值設為N**。
**如果V值和E值不同,則說明已經有其他執行緒做兩個更新,那麼當前執行緒不做更新,而是自旋。**
![_3](https://yqfile.alicdn.com/123b8ae6d9eca5deead6481f3d461bb08fbde6b7.jpeg)
# 模擬CAS實現
既然我們瞭解了CAS的思想,那可以手寫一個簡單的CAS模型:
```
// count必須用volatile修飾 保證不同執行緒之間的可見性
private volatile static int count;
public void addOne() {
int newValue;
do {
newValue = count++;
} while (!compareAndSwapInt(expectCount, newValue)); //自旋 迴圈
}
public final boolean compareAndSwapInt(int expectCount, int newValue) {
// 讀目前 count 的值
int curValue = count;
// 比較目前 count 值是否 == 期望值
if (curValue == expectCount) {
// 如果是,則更新 count 的值
count = newValue;
return true;
}
//否則返回false 然後迴圈
return false;
}
```
這個簡單的模擬程式碼,其實基本上把CAS的思想體現出來了,但實際上CAS原理可要複雜很多哦,我們還是看看JAVA是怎麼實現CAS的吧!
# 原子類
要了解JAVA中CAS的實現,那不得不提到大名鼎鼎的原子類,原子類的使用非常簡單,而其中深奧的原理就是CAS無鎖演算法。
Java 併發包裡提供的原子類內容很豐富,我們可以將它們分為五個類別:**原子化的基本資料型別、原子化的物件引用型別、原子化陣列、原子化物件屬性更新器和原子化的累加器。**
![image.png](https://img2020.cnblogs.com/other/2027276/202005/2027276-20200518221801450-1088624288.png)
原子類的使用可謂非常簡單,相信只要看一下api就知道如何使用,因此不過多解釋,如有需要可以參考本人github程式碼。
此處只以AtomicInteger為例子,測試一下原子類是否名副其實可以保證原子性:
```
private static AtomicInteger count = new AtomicInteger(0);
private static int count1 = 0;
//省略程式碼 同時啟動10個執行緒 分別測試AtomicInteger和普通int的輸出結果
private static void add10K() {
int idx = 0;
while (idx++ < 10000) {
//使用incrementAndGet實現i++功能
count.incrementAndGet();
}
countDownLatch.countDown();
}
private static void add10K1() {
int idx = 0;
while (idx++ < 10000) {
count1++;
}
countDownLatch.countDown();
}
```
通過測試可以發現,使用AtomicInteger可以保證輸出結果為100000,而普通int則不能保證。
> 本文來源於微信公眾號【胖滾豬學程式設計】。一個集顏值與才華於一身的女程式媛、以漫畫形式讓程式設計so easy and interesting!轉載請註明出處
# CAS原始碼分析
據此,我們又可以迴歸正題,JAVA是怎麼實現CAS的呢?跟蹤一下AtomicInteger中的incrementAndGet()方法,相信就會有答案了。
首先關注一下AtomicInteger.java中這麼幾個東西:
```
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;//資料在記憶體中的地址偏移量,通過偏移地址可以獲取資料原值
static {
try {
//計算變數 value 在類物件中的偏移量
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
private volatile int value;//要修改的值 volatile保證可見性
public final int incrementAndGet() {
return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
```
Unsafe,是CAS的核心類,由於Java方法無法直接訪問底層系統,需要通過本地(native)方法來訪問,Unsafe相當於一個後門,基於該類可以直接操作特定記憶體的資料。
變數valueOffset,表示該變數值在記憶體中的偏移地址,因為Unsafe就是根據記憶體偏移地址獲取資料的。
變數value必須用volatile修飾,保證了多執行緒之間的記憶體可見性。
當然具體實現我們還是得瞧瞧getAndAddInt方法:
```
//內部使用自旋的方式進行CAS更新(while迴圈進行CAS更新,如果更新失敗,則迴圈再次重試)
public final int getAndAddInt(Object var1, long var2, int var4) {
//var1為當前這個物件,如count.getAndIncrement(),則var1為count這個物件
//第二個引數為AtomicInteger物件value成員變數在記憶體中的偏移量
//第三個引數為要增加的值
int var5;
do {
//var5 獲取物件記憶體地址偏移量上的數值v 即預期舊值
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));//迴圈判斷記憶體位置的值與預期原值是否相匹配
return var5;
}
```
此時我們還想繼續瞭解compareAndSwapInt的實現,點進去看,首先映入眼簾的是四個引數:1、當前的例項 2、例項變數的記憶體地址偏移量 3、預期的舊值 4、要更新的值
```
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
```
還想繼續刨根問底,會發現點不動了。因為用native修飾的方法代表是底層方法,當然如果你非得一探究竟你也可以找找對應的unsafe.cpp 檔案進行深度解析C程式碼:
![image.png](https://img2020.cnblogs.com/other/2027276/202005/2027276-20200518221801733-1235708481.png)
![image.png](https://img2020.cnblogs.com/other/2027276/202005/2027276-20200518221801948-1057021416.png)
個人認為沒必要深究,畢竟術業有專攻,你只需要知道其實核心程式碼就是一條 **cmpxchg 指令**。
cmpxchg: 即“比較並交換”指令。與我們上面說的思想是一樣的:將 eax 暫存器中的值(compare_value)與 [edx] 雙字記憶體單元中的值進行對比,如果相同,則將 ecx 暫存器中的值(exchange_value)存入 [edx] 記憶體單元中。
總之:**你只需要記住:CAS是靠硬體實現的,從而在硬體層面提升效率。實現方式是基於硬體平臺的彙編指令,在intel的CPU中,使用的是cmpxchg指令。** 核心思想就是:**比較要更新變數的值V和預期值E(compare),相等才會將V的值設為新值N(swap)。**
# CAS真有這麼好嗎?
CAS和鎖都解決了原子性問題,和鎖相比,由於其**非阻塞**的,它對死鎖問題天生免疫,並且,**執行緒間的相互影響也非常小**。更為重要的是,使用無鎖的方式完全**沒有鎖競爭帶來的系統開銷,也沒有執行緒間頻繁排程帶來的開銷**,因此,他要比基於鎖的方式擁有**更優越的效能**。
但是,CAS真的有那麼好嗎?又到挑刺時間了!
要讓我們失望了,CAS並沒有那麼好,主要表現在三個方面:
- 1、迴圈時間太長
- 2、只能保證一個共享變數原子操作
- 3、ABA問題。
**迴圈時間太長**
如果CAS長時間地不成功,我們知道會持續迴圈、自旋。必然會給CPU帶來非常大的開銷。在JUC中有些地方就限制了CAS自旋的次數,例如BlockingQueue的SynchronousQueue。
**只能保證一個共享變數原子操作**
看了CAS的實現就知道這隻能針對一個共享變數,如果是多個共享變數就只能使用鎖了,當然如果你有辦法把多個變數整成一個變數,利用CAS也不錯。例如讀寫鎖中state的高低位。
**ABA問題**
這可是個面試重點問題哦!認真聽好!
CAS需要檢查操作值有沒有發生改變,如果沒有發生改變則更新。但是存在這樣一種情況:如果一個值原來是A,變成了B,然後又變成了A,那麼在CAS檢查的時候會發現沒有改變,但是實質上它已經發生了改變,這就是所謂的ABA問題。
某些情況我們並不關心 ABA 問題,例如數值的原子遞增,但也不能所有情況下都不關心,例如原子化的更新物件很可能就需要關心 ABA 問題,因為兩個 A 雖然相等,但是第二個 A 的屬性可能已經發生變化了。
對於ABA問題其解決方案是加上版本號,即在每個變數都加上一個版本號,每次改變時加1,即A —> B —> A,變成1A —> 2B —> 3A。
**原子類之AtomicStampedReference可以解決ABA問題**,它內部不僅維護了物件值,還維護了一個Stamp(可把它理解為版本號,它使用整數來表示狀態值)。當AtomicStampedReference對應的數值被修改時,除了更新資料本身外,還必須要更新版本號。當AtomicStampedReference設定物件值時,物件值以及版本號都必須滿足期望值,寫入才會成功。因此,即使物件值被反覆讀寫,寫回原值,只要版本號發生變化,就能防止不恰當的寫入。
```
// 引數依次為:期望值 寫入新值 期望版本號 新版本號
public boolean compareAndSet(V expectedReference, V
newReference, int expectedStamp, int newStamp);
//獲得當前物件引用
public V getReference();
//獲得當前版本號
public int getStamp();
//設定當前物件引用和版本號
public void set(V newReference, int newStamp);
```
說理論太多也沒用,還是親自實驗它是否能解決ABA問題吧:
```
private static AtomicStampedR