我告訴你一個 AtomicInteger 的驚天大祕密

i++ 不是執行緒安全的操作，因為它不是一個原子性操作。

那麼，如果我想要達到類似 i++ 的這種效果，我應該使用哪些集合或者說工具類呢？

在 JDK1.5 之前，為了確保在多執行緒下對某基本資料型別或者參照資料型別運算的原子性，必須依賴於外部關鍵字 synchronized，但是這種情況在 JDK1.5 之後發生了改觀，當然你依然可以使用 synchronized 來保證原子性，我們這裡所說的一種執行緒安全的方式是原子性的工具類，比如 AtomicInteger、AtomicBoolean 等。這些原子類都是執行緒安全的工具類，他們同時也是 Lock-Free 的。下面我們就來一起認識一下這些工具類以及 Lock - Free 是個什麼概念。

瞭解 AtomicInteger

AtomicInteger 是 JDK 1.5 新新增的工具類，我們首先來看一下它的繼承關係

與 int 的包裝類 Integer 一樣，都是繼承於 Number 類的。

這個 Number 類是基本資料型別的包裝類，一般和資料型別有關的物件都會繼承於 Number 類。

它的繼承體系很簡單，下面我們來看一下它的基本屬性和方法

AtomicInteger 的基本屬性

AtomicInteger 的基本屬性有三個

Unsafe 是 sun.misc 包下面的類，AtomicInteger 主要是依賴於 sun.misc.Unsafe 提供的一些 native 方法保證操作的原子性。

Unsafe 的 objectFieldOffset 方法可以獲取成員屬性在記憶體中的地址相對於物件記憶體地址的偏移量。說得簡單點就是找到這個變數在記憶體中的地址，便於後續通過記憶體地址直接進行操作，這個值就是 value

這個我們後面會再細說

value 就是 AtomicIneger 的值。

AtomicInteger 的構造方法

繼續往下看，AtomicInteger 的構造方法只有兩個，一個是無引數的構造方法，無引數的構造方法預設的 value 初始值是 0 ，帶引數的構造方法可以指定初始值。

AtomicInteger 中的方法

下面我們就來聊一下 AtomicInteger 中的方法。

Get 和 Set

我們首先來看一下最簡單的 get 、set 方法：

get() : 獲取當前 AtomicInteger 的值

set() : 設定當前 AtomicInteger 的值

get() 可以原子性的讀取 AtomicInteger 中的資料，set() 可以原子性的設定當前的值，因為 get() 和 set() 最終都是作用於 value 變數，而 value 是由 volatile 修飾的，所以 get 、set 相當於都是對記憶體進行讀取和設定。如下圖所示

我們上面提到了 i++ 和 i++ 的非原子性操作，我們說可以使用 AtomicInteger 中的方法進行替換。

Incremental 操作

AtomicInteger 中的 Incremental 相關方法可以滿足我們的需求

getAndIncrement() : 原子性的增加當前的值，並把結果返回。相當於 i++ 的操作。

為了驗證是不是執行緒安全的，我們用下面的例子進行測試

public class TAtomicTest implements Runnable{

    AtomicInteger atomicInteger = new AtomicInteger();

    @Override
    public void run() {
        for(int i = 0;i < 10000;i++){
            System.out.println(atomicInteger.getAndIncrement());
        }
    }
    public static void main(String[] args) {

        TAtomicTest tAtomicTest = new TAtomicTest();

        Thread t1 = new Thread(tAtomicTest);
        Thread t2 = new Thread(tAtomicTest);
        t1.start();
        t2.start();
    }

}

通過輸出結果你會發現它是一個執行緒安全的操作，你可以修改 i 的值，但是最後的結果仍然是 i - 1，因為先取值，然後再 + 1，它的示意圖如下。

incrementAndGet 與此相反，首先執行 + 1 操作，然後返回自增後的結果，該操作方法能夠確保對 value 的原子性操作。如下圖所示

Decremental 操作

與此相對，x-- 或者 x = x - 1 這樣的自減操作也是原子性的。我們仍然可以使用 AtomicInteger 中的方法來替換

getAndDecrement : 返回當前型別的 int 值，然後對 value 的值進行自減運算。下面是測試程式碼

class TAtomicTestDecrement implements Runnable{

    AtomicInteger atomicInteger = new AtomicInteger(20000);

    @Override
    public void run() {
        for(int i = 0;i < 10000 ;i++){
            System.out.println(atomicInteger.getAndDecrement());
        }
    }

    public static void main(String[] args) {

        TAtomicTestDecrement tAtomicTest = new TAtomicTestDecrement();

        Thread t1 = new Thread(tAtomicTest);
        Thread t2 = new Thread(tAtomicTest);
        t1.start();
        t2.start();

    }

}

下面是 getAndDecrement 的示意圖

decrementAndGet：同樣的，decrementAndGet 方法就是先執行遞減操作，然後再獲取 value 的值，示意圖如下

LazySet 方法

volatile 有記憶體屏障你知道嗎？

記憶體屏障是啥啊？

記憶體屏障，也稱記憶體柵欄，記憶體柵障，屏障指令等，是一類同步屏障指令，是 CPU 或編譯器在對記憶體隨機存取的操作中的一個同步點，使得此點之前的所有讀寫操作都執行後才可以開始執行此點之後的操作。也是一個讓CPU 處理單元中的記憶體狀態對其它處理單元可見的一項技術。

CPU 使用了很多優化，使用快取、指令重排等，其最終的目的都是為了效能，也就是說，當一個程式執行時，只要最終的結果是一樣的，指令是否被重排並不重要。所以指令的執行時序並不是順序執行的，而是亂序執行的，這就會帶來很多問題，這也促使著記憶體屏障的出現。

語意上，記憶體屏障之前的所有寫操作都要寫入記憶體；記憶體屏障之後的讀操作都可以獲得同步屏障之前的寫操作的結果。因此，對於敏感的程式塊，寫操作之後、讀操作之前可以插入記憶體屏障。

記憶體屏障的開銷非常輕量級，但是再小也是有開銷的，LazySet 的作用正是如此，它會以普通變數的形式來讀寫變數。

也可以說是：懶得設定屏障了

GetAndSet 方法

以原子方式設定為給定值並返回舊值。

它的原始碼就是呼叫了一下 unsafe 中的 getAndSetInt 方法，如下所示

就是先進行迴圈，然後呼叫 getIntVolatile 方法，這個方法我在 cpp 中沒有找到，找到的小夥伴們記得及時告訴讓我學習一下。

迴圈直到 compareAndSwapInt 返回 false，這就說明使用 CAS 並沒有更新為新的值，所以 var5 返回的就是最新的記憶體值。

CAS 方法

我們一直常說的 CAS 其實就是 CompareAndSet 方法，這個方法顧名思義，就是 比較並更新 的意思，當然這是字面理解，字面理解有點偏差，其實人家的意思是先比較，如果滿足那麼再進行更新。

上面給出了 CAS Java 層面的原始碼，JDK 官方給它的解釋就是 如果當前值等於 expect 的值，那麼就以原子性的方式將當前值設定為 update 給定值，這個方法會返回一個 boolean 型別，如果是 true 就表示比較並更新成功，否則表示失敗。

CAS 同時也是一種無鎖並行機制，也稱為 Lock Free，所以你覺得 Lock Free 很高大上嗎？並沒有。

下面我們構建一個加鎖解鎖的 CASLock

class CASLock {

    AtomicInteger atomicInteger = new AtomicInteger();
    Thread currentThread = null;

    public void tryLock() throws Exception{

        boolean isLock = atomicInteger.compareAndSet(0, 1);
        if(!isLock){
            throw new Exception("加鎖失敗");
        }

        currentThread = Thread.currentThread();
        System.out.println(currentThread + " tryLock");

    }

    public void unlock() {

        int lockValue = atomicInteger.get();
        if(lockValue == 0){
            return;
        }
        if(currentThread == Thread.currentThread()){
            atomicInteger.compareAndSet(1,0);
            System.out.println(currentThread + " unlock");
        }
    }

    public static void main(String[] args) {

        CASLock casLock = new CASLock();

        for(int i = 0;i < 5;i++){

            new Thread(() -> {
                try {
                    casLock.tryLock();
                    Thread.sleep(10000);
                } catch (Exception e) {
                    e.printStackTrace();
                }finally {
                    casLock.unlock();
                }
            }).start();
        }

    }
}

在上面的程式碼中，我們構建了一個 CASLock，在 tryLock 方法中，我們先使用 CAS 方法進行更新，如果更新不成功則丟擲異常，並把當前執行緒設定為加鎖執行緒。在 unLock 方法中，我們先判斷當前值是否為 0 ，如果是 0 就是我們願意看到的結果，直接返回。否則是 1，則表示當前執行緒還在加鎖，我們再來判斷一下當前執行緒是否是加鎖執行緒，如果是則執行解鎖操作。

那麼我們上面提到的 compareAndSet，它其實可以解析為如下操作

// 虛擬碼

// 當前值
int v = 0;
int a = 0;
int b = 1;

if(compare(0,0) == true){
  set(0,1);
}
else{
  // 繼續向下執行
}

也可以拿生活場景中的買票舉例子，你去景區旅遊肯定要持票才能進，如果你拿著是假票或者不符合景區的票肯定是能夠被識別出來的，如果你沒有拿票拿你也肯定進不去景區。

廢話少說，這就祭出來 compareAndSet 的示意圖

weakCompareAndSet: 媽的非常認真看了好幾遍，發現 JDK1.8 的這個方法和 compareAndSet 方法完全一摸一樣啊，坑我。。。

但是真的是這樣麼？並不是，JDK 原始碼很博大精深，才不會設計一個重複的方法，你想想 JDK 團隊也不是會犯這種低階團隊，但是原因是什麼呢？

《Java 高並行詳解》這本書給出了我們一個答案

AddAndGet

AddAndGet 和 getAndIncrement、getAndAdd、incrementAndGet 等等方法都是使用了 do … while + CAS 操作，其實也就相當於是一個自旋鎖，如果 CAS 修改成功就會一直迴圈，修改失敗才會返回。示意圖如下

深入 AtomicInteger

我們上面探討了 AtomicInteger 的具體使用，同時我們知道 AtomicInteger 是依靠 volatile 和 CAS 來保證原子性的，那麼我們下面就來分析一下為什麼 CAS 能夠保證原子性，它的底層是什麼？AtomicInteger 與樂觀鎖又有什麼關係呢？

AtomicInteger 的底層實現原理

我們再來瞧瞧這個可愛的 compareAndSetL(CAS) 方法，為什麼就這兩行程式碼就保證原子性了？

我們可以看到，這個 CAS 方法相當於是呼叫了 unsafe 中的 compareAndSwapInt 方法，我們進到 unsafe 方能發中看一下具體實現。

compareAndSwapInt 是 sun.misc 中的方法，這個方法是一個 native 方法，它的底層是 C/C++ 實現的，所以我們需要看 C/C++ 的原始碼。

知道 C/C++ 的牛逼之處了麼。使用 Java 就是玩應用和架構的，C/C++ 是玩伺服器、底層的。

compareAndSwapInt 的原始碼在 jdk8u-dev/hotspot/src/share/vm/prims/unsafe.app 路徑下，它的原始碼實現是

也就是 Unsafe_CompareAndSwapInt 方法，我們找到這個方法

C/C++ 原始碼我也看不懂，但是這不妨礙我們找到關鍵程式碼 Atomic::cmpxchg ，cmpxchg 是 x86 CPU 架構的組合指令，它的主要作用就是比較並交換運算元。我們繼續往下跟找一下這個指令的定義。

我們會發現對應不同的 os，其底層實現方式不一樣

我們找到 Windows 的實現方式如下

我們繼續向下找，它其實定義的是第 216 行的程式碼，我們找進去

此時就需要組合指令和暫存器相關的知識了。

上面的 os::is-MP() 是多處理作業系統的介面，下面是 __asm ，它是 C/C++ 的關鍵字，用於呼叫內聯組合程式。

__asm 中的程式碼是組合程式，大致來說就是把 dest、exchange_value 、compare_value 的值都放在暫存器中，下面的 LOCK_IF_MP 中程式碼的大致意思就是

如果是多處理器的話就會執行 lock，然後進行比較操作。其中的 cmp 表示比較，mp 表示的就是 MultiProcess，je 表示相等跳轉，L0 表示的是標識位。

我們回到上面的組合指令，我們可以看到，CAS 的底層就是 cmpxchg 指令。

樂觀鎖

你有沒有這個疑問，為什麼 AtomicInteger 可以獲取當前值，那為什麼還會出現 expectValue 和 value 不一致的情況呢？

因為 AtomicInteger 只是一個原子性的工具類，它不具有排他性，它不像是 synchronized 或者是 lock 一樣具有互斥和排他性，還記得 AtomicInteger 中有兩個方法 get 和 set 嗎？它們只是用 volatile 修飾了一下，而 volatile 不具有原子性，所以可能會存在 expectValue 和 value 的當前值不一致的情況，因此可能會出現重複修改。

針對上面這種情況的解決辦法有兩種，一種是使用 synchronized 和 lock 等類似的加鎖機制，這種鎖具有獨佔性，也就是說同一時刻只能有一個執行緒來進行修改，這種方式能夠保證原子性，但是相對開銷比較大，這種鎖也叫做悲觀鎖。另外一種解決辦法是使用版本號或者是 CAS 方法。

版本號

版本號機制是在資料表中加上一個 version 欄位來實現的，表示資料被修改的次數，當執行寫操作並且寫入成功後，version = version + 1，當執行緒 A 要更新資料時，在讀取資料的同時也會讀取 version 值，在提交更新時，若剛才讀取到的 version 值為當前資料庫中的 version 值相等時才更新，否則重試更新操作，直到更新成功。

CAS 方法

還有一種方式就是 CAS 了，我們上面用了大量的篇幅來介紹 CAS 方法，那麼我們認為你現在已經對其執行機制有一定的瞭解了，我們就不再闡述它的執行機制了。

任何事情都是有利也有弊，軟體行業沒有完美的解決方案只有最優的解決方案，所以樂觀鎖也有它的弱點和缺陷，那就是 ABA 問題。

ABA 問題

ABA 問題說的是，如果一個變數第一次讀取的值是 A，準備好需要對 A 進行寫操作的時候，發現值還是 A，那麼這種情況下，能認為 A 的值沒有被改變過嗎？可以是由 A -> B -> A 的這種情況，但是 AtomicInteger 卻不會這麼認為，它只相信它看到的，它看到的是什麼就是什麼。舉個例子來說

假如現在有一個單連結串列，如下圖所示

A.next = B ，B.next = null，此時有兩個執行緒 T1 和 T2 分別從單連結串列中取出 A ，由於一些特殊原因，T2 把 A 改為 B ，然後又改為 A ，此時 T1 執行 CAS 方法，發現單連結串列仍然是 A ，就會執行 CAS 方法，雖然結果沒錯，但是這種操作會造成一些潛在的問題。