CAS這個機制就給實現(xiàn)線程安全版本的代碼，提供了一個新的思路，之前通過加鎖，把多個指令打包成整體，來實現(xiàn)線程安全。現(xiàn)在就可以考慮直接基與CAS來實現(xiàn)一些修改操作，也能保證線程安全（不需要加鎖）

1.什么是 CAS

CAS: 全稱Compare and swap，字面意思:”比較并交換“，一個 CAS 涉及到以下操作：

我們假設內存中的原數(shù)據(jù)V，舊的預期值A，需要修改的新值B。
1. 比較 A 與 V 是否相等。（比較）
2. 如果比較相等，將 B 寫入 V。（交換）
3. 返回操作是否成功。

CAS 偽代碼

下面寫的代碼不是原子的, 真實的 CAS 是一個原子的硬件指令完成的. 這個偽代碼只是輔助理解
CAS 的工作流程.

    boolean CAS(address, expectValue, swapValue) {if (&address == expectedValue){&address = swapValue;return true;}return false;}

當多個線程同時對某個資源進行CAS操作，只能有一個線程操作成功，但是并不會阻塞其他線程,其他線程只會收到操作失敗的信號.

CAS 可以視為是一種樂觀鎖. (或者可以理解成 CAS 是樂觀鎖的一種實現(xiàn)方式)
?

2.CAS 是怎么實現(xiàn)

針對不同的操作系統(tǒng)，JVM 用到了不同的 CAS 實現(xiàn)原理，簡單來講：

• java 的 CAS 利用的的是 unsafe 這個類提供的 CAS 操作；
• unsafe 的 CAS 依賴了的是 jvm 針對不同的操作系統(tǒng)實現(xiàn)的 Atomic::cmpxchg；
• Atomic::cmpxchg 的實現(xiàn)使用了匯編的 CAS 操作，并使用 cpu 硬件提供的 lock 機制保證其原子性

簡而言之，是因為硬件予以了支持，軟件層面才能做到.
?

3.CAS 有哪些應用

（1）實現(xiàn)原子類

標準庫中提供了 java.util.concurrent.atomic 包, 里面的類都是基于這種方式來實現(xiàn)的.
典型的就是 AtomicInteger 類. 其中的 getAndIncrement 相當于 i++ 操作.
?

package thread2;import java.util.concurrent.atomic.AtomicInteger;public class Test7 {private static AtomicInteger num = new AtomicInteger(0);public static void main(String[] args) throws InterruptedException {Thread thread1 = new Thread(() -> {for (int i = 0; i < 50000; i++) {num.getAndIncrement();}});Thread thread2 = new Thread(() -> {for (int i = 0; i < 50000; i++) {num.getAndIncrement();}});thread1.start();thread2.start();thread1.join();thread2.join();System.out.println(num.get());}}

?

不會出現(xiàn)線程安全問題！

偽代碼實現(xiàn)getAndIncrement：

class AtomicInteger {private int value;public int getAndIncrement() {int oldValue = value;while (CAS(value, oldValue, oldValue + 1) != true) {oldValue = value;}return oldValue;}
}

假設兩個線程同時調用 getAndIncrement

（1）兩個線程都讀取 value 的值到 oldValue 中. (oldValue 是一個局部變量, 在棧上. 每個線程有自己的棧)

?

?（2）?線程1 先執(zhí)行 CAS 操作. 由于 oldValue 和 value 的值相同, 直接進行對 value 賦值.

• CAS 是直接讀寫內存的, 而不是操作寄存器.
• CAS 的讀內存, 比較, 寫內存操作是一條硬件指令, 是原子的.
  ?

（3）?線程2 再執(zhí)行 CAS 操作, 第一次 CAS 的時候發(fā)現(xiàn) oldValue 和 value 不相等, 不能進行賦值. 因此需要進入循環(huán).在循環(huán)里重新讀取 value 的值賦給 oldValue

?

(4)線程2 接下來第二次執(zhí)行 CAS, 此時 oldValue 和 value 相同, 于是直接執(zhí)行賦值操作.

?

(5) 線程1 和 線程2 返回各自的 oldValue 的值即可.

通過形如上述代碼就可以實現(xiàn)一個原子類. 不需要使用重量級鎖, 就可以高效的完成多線程的自增操作.

本來 check and set 這樣的操作在代碼角度不是原子的. 但是在硬件層面上可以讓一條指令完成這
個操作, 也就變成原子的了.

(2)實現(xiàn)自旋鎖

基于 CAS 實現(xiàn)更靈活的鎖, 獲取到更多的控制權

public class SpinLock {private Thread owner = null;public void lock() {
// 通過 CAS 看當前鎖是否被某個線程持有.
// 如果這個鎖已經(jīng)被別的線程持有, 那么就自旋等待.
// 如果這個鎖沒有被別的線程持有, 那么就把 owner 設為當前嘗試加鎖的線程.while (!CAS(this.owner, null, Thread.currentThread())) {}}public void unlock() {this.owner = null;}
}

通過CAS,比較一下, owner是不是null (問問這個鎖,是不是空閑的,沒人用的)
如果是空閑的,就直接把當前線程的值,賦值給這里owner就相當于表示了當前的鎖被這個線程給獲取到了~~
如果當前鎖不是空閑的,此處CAS的比較就會失敗,直接返回false,循環(huán)繼續(xù)再進行一次再重復上述的CAS過程~
直到owner為 null,這個循環(huán)CAS操作比較交換成功,才能從lock方法中返回~~
自旋鎖的特點,就是在其他線程釋放了鎖的瞬間,就能感知到,并且獲取到鎖~~

4.CAS 的 ABA 問題

假設存在兩個線程 t1 和 t2. 有一個共享變量 num, 初始值為 A.接下來, 線程 t1 想使用 CAS 把 num 值改成 Z, 那么就需要

• 先讀取 num 的值, 記錄到 oldNum 變量中.
• 使用 CAS 判定當前 num 的值是否為 A, 如果為 A, 就修改成 Z

但是, 在 t1 執(zhí)行這兩個操作之間, t2 線程可能把 num 的值從 A 改成了 B, 又從 B 改成了 A

線程 t1 的 CAS 是期望 num 不變就修改. 但是 num 的值已經(jīng)被 t2 給改了. 只不過又改成 A 了. 這個時候 t1 究竟是否要更新 num 的值為 Z 呢?

到這一步, t1 線程無法區(qū)分當前這個變量始終是 A, 還是經(jīng)歷了一個變化過程.

ABA 問題引來的 BUG

大部分的情況下, t2 線程這樣的一個反復橫跳改動, 對于 t1 是否修改 num 是沒有影響的. 但是不排除一些特殊情況

假設 滑稽老哥 有 100 存款. 滑稽想從 ATM 取 50 塊錢. 取款機創(chuàng)建了兩個線程, 并發(fā)的來執(zhí)行 -50
操作.我們期望一個線程執(zhí)行 -50 成功, 另一個線程 -50 失敗.如果使用 CAS 的方式來完成這個扣款過程就可能出現(xiàn)問題.

正常的過程

1. 存款 100. 線程1 獲取到當前存款值為 100, 期望更新為 50; 線程2 獲取到當前存款值為 100, 期望更新為 50.
2. 線程1 執(zhí)行扣款成功, 存款被改成 50. 線程2 阻塞等待中.
3. 輪到線程2 執(zhí)行了, 發(fā)現(xiàn)當前存款為 50, 和之前讀到的 100 不相同, 執(zhí)行失敗.

異常的過程

1. 存款 100. 線程1 獲取到當前存款值為 100, 期望更新為 50; 線程2 獲取到當前存款值為 100, 期望更新為 50.
2. 線程1 執(zhí)行扣款成功, 存款被改成 50. 線程2 阻塞等待中.
3. 在線程2 執(zhí)行之前, 滑稽的朋友正好給滑稽轉賬 50, 賬戶余額變成 100 !!
4. 輪到線程2 執(zhí)行了, 發(fā)現(xiàn)當前存款為 100, 和之前讀到的 100 相同, 再次執(zhí)行扣款操作這個時候, 扣款操作被執(zhí)行了兩次!!! 都是 ABA 問題搞的鬼

解決方案

給要修改的值, 引入版本號. 在 CAS 比較數(shù)據(jù)當前值和舊值的同時, 也要比較版本號是否符合預期.

• CAS 操作在讀取舊值的同時, 也要讀取版本號

真正修改的時候,

• 如果當前版本號和讀到的版本號相同, 則修改數(shù)據(jù), 并把版本號 + 1.
• 如果當前版本號高于讀到的版本號. 就操作失敗(認為數(shù)據(jù)已經(jīng)被修改過了).
  ?

對比理解上面的轉賬例子

假設 滑稽老哥 有 100 存款. 滑稽想從 ATM 取 50 塊錢. 取款機創(chuàng)建了兩個線程, 并發(fā)的來執(zhí)行 -50
操作.
我們期望一個線程執(zhí)行 -50 成功, 另一個線程 -50 失敗.
為了解決 ABA 問題, 給余額搭配一個版本號, 初始設為 1.
1.存款 100. 線程1 獲取到 存款值為 100, 版本號為 1, 期望更新為 50; 線程2 獲取到存款值為 100,
版本號為 1, 期望更新為 50.

2.線程1 執(zhí)行扣款成功, 存款被改成 50, 版本號改為2. 線程2 阻塞等待中.

3.在線程2 執(zhí)行之前, 滑稽的朋友正好給滑稽轉賬 50, 賬戶余額變成 100, 版本號變成3.

4.輪到線程2 執(zhí)行了, 發(fā)現(xiàn)當前存款為 100, 和之前讀到的 100 相同, 但是當前版本號為 3, 之前讀
到的版本號為 1, 版本小于當前版本, 認為操作失敗.

都版本不一樣了咋辦？線程一是version=2，線程2是version=1，都讀取失敗，重新從內存讀取至版本和值。?

在 Java 標準庫中提供了 AtomicStampedReference<E> 類. 這個類可以對某個類進行包裝, 在內部就提供了上面描述的版本管理功能.
?

1) 講解下你自己理解的 CAS 機制

全稱 Compare and swap, 即 "比較并交換". 相當于通過一個原子的操作, 同時完成 "讀取內存, 比
較是否相等, 修改內存" 這三個步驟. 本質上需要 CPU 指令的支撐.

2) ABA問題怎么解決？

給要修改的數(shù)據(jù)引入版本號. 在 CAS 比較數(shù)據(jù)當前值和舊值的同時, 也要比較版本號是否符合預期.
如果發(fā)現(xiàn)當前版本號和之前讀到的版本號一致, 就真正執(zhí)行修改操作, 并讓版本號自增; 如果發(fā)現(xiàn)當
前版本號比之前讀到的版本號大, 就認為操作失敗


?