【漫畫】CAS原理分析！無鎖原子類也能解決併發問題！

時間 2020-05-19

標籤 cas 原理分析子類解決併發問題简体版

原文原文鏈接

本文來源於微信公衆號【胖滾豬學編程】、轉載請註明出處

在漫畫併發編程系統博文中，咱們講了N篇關於鎖的知識，確實，鎖是解決併發問題的萬能鑰匙，但是併發問題只有鎖能解決嗎？今天要出場一個大BOSS：CAS無鎖算法，可謂是併發編程核心中的核心！java

溫故

首先咱們再回顧一下原子性問題的緣由，參考【漫畫】JAVA併發編程如何解決原子性問題。
git

兩個線程同時把count=0加載到本身的工做內存，線程B先執行count++操做，此時主內存已經變化成了1，可是線程A依舊覺得count=0，這是致使問題的根源。github

因此解決方案就是：不能讓線程A覺得count=0，而是要和主內存進行一次compare(比較)，若是內存中的值是0，說明沒有其餘線程更新過count值，那麼就swap(交換)，把新值寫回主內存。若是內存中的值不是0，好比本案例中，內存中count就已經被線程B更新成了1，比較0!=1，所以compare失敗，不把新值寫回主內存。面試

本文來源於微信公衆號【胖滾豬學編程】。一個集顏值與才華於一身的女程序媛、以漫畫形式讓編程so easy and interesting！轉載請註明出處

CAS概念

CAS （compareAndSwap），中文叫比較交換，一種無鎖原子算法。算法

CAS算法包含 3 個參數 CAS（V，E，N），V表示要更新變量在內存中的值，E表示舊的預期值，N表示新值。
僅當 V值等於E值時，纔會將V的值設爲N。
若是V值和E值不一樣，則說明已經有其餘線程作兩個更新，那麼當前線程不作更新，而是自旋。編程

模擬CAS實現

既然咱們瞭解了CAS的思想，那能夠手寫一個簡單的CAS模型：api

// 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 併發包裏提供的原子類內容很豐富，咱們能夠將它們分爲五個類別：原子化的基本數據類型、原子化的對象引用類型、原子化數組、原子化對象屬性更新器和原子化的累加器。多線程

原子類的使用可謂很是簡單，相信只要看一下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的實現，點進去看，首先映入眼簾的是四個參數：一、當前的實例二、實例變量的內存地址偏移量三、預期的舊值四、要更新的值

public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

還想繼續刨根問底，會發現點不動了。由於用native修飾的方法表明是底層方法，固然若是你非得一探究竟你也能夠找找對應的unsafe.cpp 文件進行深度解析C代碼：

我的認爲不必深究，畢竟術業有專攻，你只須要知道其實核心代碼就是一條 cmpxchg 指令。
cmpxchg: 即「比較並交換」指令。與咱們上面說的思想是同樣的：將 eax 寄存器中的值（compare_value）與 [edx] 雙字內存單元中的值進行對比，若是相同，則將 ecx 寄存器中的值（exchange_value）存入 [edx] 內存單元中。

總之：你只須要記住：CAS是靠硬件實現的，從而在硬件層面提高效率。實現方式是基於硬件平臺的彙編指令，在intel的CPU中，使用的是cmpxchg指令。 核心思想就是：比較要更新變量的值V和預期值E（compare），相等纔會將V的值設爲新值N（swap）。

CAS真有這麼好嗎？

CAS和鎖都解決了原子性問題，和鎖相比，因爲其非阻塞的，它對死鎖問題天生免疫，而且，線程間的相互影響也很是小。更爲重要的是，使用無鎖的方式徹底沒有鎖競爭帶來的系統開銷，也沒有線程間頻繁調度帶來的開銷，所以，他要比基於鎖的方式擁有更優越的性能。

可是，CAS真的有那麼好嗎？又到挑刺時間了！

要讓咱們失望了，CAS並無那麼好，主要表如今三個方面：

一、循環時間太長
二、只能保證一個共享變量原子操做
三、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 AtomicStampedReference<Integer> count = new AtomicStampedReference<>(10, 0);

    public static void main(String[] args) {
        Thread main = new Thread(() -> {
            int stamp = count.getStamp(); //獲取當前版本

            log.info("線程{} 當前版本{}",Thread.currentThread(),stamp);
            try {
                Thread.sleep(1000); //等待1秒 ，以便讓干擾線程執行
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            boolean isCASSuccess = count.compareAndSet(10, 12, stamp, stamp + 1);  //此時expectedReference未發生改變，可是stamp已經被修改了,因此CAS失敗
            log.info("CAS是否成功={}",isCASSuccess);
        }, "主操做線程");

        Thread other = new Thread(() -> {
            int stamp = count.getStamp(); //獲取當前版本
            log.info("線程{} 當前版本{}",Thread.currentThread(),stamp);
            count.compareAndSet(10, 12, stamp, stamp + 1);
            log.info("線程{} 增長後版本{}",Thread.currentThread(),count.getStamp());

            // 模擬ABA問題 先更新成12 又更新回10
            int stamp1 = count.getStamp(); //獲取當前版本
            count.compareAndSet(12, 10, stamp1, stamp1 + 1);
            log.info("線程{} 減小後版本{}",Thread.currentThread(),count.getStamp());
        }, "干擾線程");

        main.start();
        other.start();
    }

輸出結果以下：

線程Thread[主操做線程,5,main] 當前版本0
[干擾線程] INFO - 線程Thread[干擾線程,5,main] 當前版本0
[干擾線程] INFO  - 線程Thread[干擾線程,5,main] 增長後版本1
[干擾線程] INFO - 線程Thread[干擾線程,5,main] 減小後版本2
[主操做線程] INFO  - CAS是否成功=false