年輕人，醒醒吧！此時不搏何時搏！本文主要講一下常見的CAS理論。再者就是說一下鎖的分類，什么樂觀鎖啊，悲觀鎖、重入鎖等等。這篇文章要一網打盡，都介紹一下。

把CAS按在地上摩擦

中文名：比較并交換

英文名：Compare And Swap

英文縮寫：CAS

他是一種無鎖化基于樂觀鎖思想實現的算法，目的是在不使用鎖的情況下實現多線程之間的共享數據同步。在JAVA的java.util.concurrent包中的原子類（不是原子彈）就是基于CAS的實現的。在CAS的算法世界中，存在三大護法：value（要更新的變量）、expected（預期值）和new（要新寫入的值）。下面畫圖說明CAS是如何實現不加鎖的情況下協調多線程同步共享數據的：

解釋一下：當A、B兩個線程都操作value值時，線程A如果一切順利，會在進行預期值與內存值做比較且相等，這個動作是原子化操作，這時候執行原子的修改value值的操作。修改完成后，B線程也來修改，發現有敵情，只好原地循環等待，直到條件符合時才進行內存值的操作。還有一點要注意的是，比對和修改兩個動作都是原子的，但是原子操作 + 原子操作 != 原子操作。多線程高并發，搞的額頭沒頭發。

理想與現實的差距就是這么大....

鎖的分類

樂觀鎖與悲觀鎖

這二位其實并不是實際存在的鎖，僅僅是對鎖的抽象定義。樂觀鎖的目的就是不加鎖，從而提升效率。這一思想在Java以及基于數據庫實現的樂觀鎖中都有實踐。

在樂觀鎖的概念里，認為所有的數據都是為我當前線程服務的，在我使用的過程中不會有別的線程修改我的數據（哼，想多了），但是為了保險起見，在更新目標數據的時候還是要做一次對比，即前面說的CAS過程。不過樂觀鎖是思想，CAS是算法。搞清楚這個就行了。

在悲觀鎖的概念里，跟樂觀鎖恰好相反，它的核心是“總有刁民想害朕”即所有線程都可能修改自己持有的數據。因此在讀取數據的時候就趕緊上鎖，其他人都別想動我的寶貝！大家都立正，一個一個按順序來。比如前面寫到的Synchronized和后面將要寫的Lock接口，還有就是基于數據庫的悲觀鎖：select xx from xx where xxx for update。

自旋鎖與非自旋鎖

自旋鎖其實就是前一篇中說的輕量級鎖，還有兄弟是自適應自旋鎖，目前自旋鎖是被廢了的太子，自適應自旋鎖頂替了太子之位了，因為它可以自動的動態調整自旋次數，以達到最高效的運行狀態，具體根據那些參數自動調整。而非自旋鎖則是當目標資源被占用時，直接進入休眠狀態了（遇到困難，睡大覺），等資源就緒后會被再次喚醒并嘗試獲取鎖，這樣就造成了反復的內核態與用戶態的切換，浪費系統資源。一張圖，展示一下自旋與非自旋的差異性：

畫圖是真的費眼睛，大家有什么比較好的畫圖方式嗎？可以分享一下。這里再解釋一下，自旋鎖并不完美，有很多缺點，比如自旋時如果此時控制不當，會造成CPU資源的浪費，JDK也在不斷的優化這些鎖的性能。

再往深了說，其實在自旋鎖中還分為三種：TicketLock、CLHlock和MCSlock。

TicketLock

看名字就知道：票據鎖，即想要獲取鎖，你要出示對應的憑證，對上號了，才能把鎖給你。跟你去銀行取錢似的，拿對卡，輸對密碼才能給你取錢。

/**
 * FileName: TicketLock
 * Author:   RollerRunning
 * Date:     2020/12/3 9:34 PM
 * Description:
 */
public class TicketLock {
    //保證可見性
    volatile int flag = 0;
    AtomicInteger ticket = new AtomicInteger(0);
    void lock() {
        int getTicket = ticket.getAndIncrement();
        while (getTicket != flag) {

        }
    }

    void unlock() {
        flag++;
    }
}

還記得前面講的Volatile是基于總線監聽實現的可見性嗎？這里如果線程特別多，大家都在監聽flag，這對于帶寬容量有限的主存來說，線程的不斷增加，壓力會越來越大，這也桑暢TicketLock的缺點。

CLHlock

CLHLock其實是三個人發明的：Craig, Landin和Hagersten所以叫CLH了，它的底層是基于鏈表的公平自旋鎖。赫赫有名的AQS（AbstractQueuedSynchronizer）就是基于這種鎖變種而來的。在CLH中，所有相互競爭的線程都被放到一個鏈表中排隊，每一個線程被抽象成一個鏈表的節點，每一個節點在前趨結點的locked域上自旋等待。當前驅釋放鎖狀態，則后續節點就可以進行獲取鎖的操作。在以后的文章里會手撕AQS的，今天主要介紹一下有啥，埋個種子。

MCSlock

CLHLock這么牛13了，還整個MCSLock干啥呢？原因竟然是為了兼容硬件系統，從架構上來看，分為三大怪物：SMP, MPP和NUMA，問題就出在了這個NUMA上了。它的中文名是：非一致存儲訪問結構。正是因為這種結構，導致了在使用CLHLock時，后節點在獲取前節點中的locked域狀態時內存過遠。行了，當做八股文背住就行了，面試估計也沒人問這個，寫BUG更用不到。

公平鎖與非公平鎖

公平鎖

是指多個線程按照申請鎖的順序來依次獲取鎖，線程直接進入隊列中排隊，當共享資源可用時，只有隊列中的第一個線程才能獲得鎖。公平鎖的優點是等待鎖的線程不會餓死。但是整體吞吐效率相對非公平鎖要低，等待隊列中除第一個線程以外的所有線程都會阻塞，CPU喚醒阻塞線程的開銷比非公平鎖大。

非公平鎖

是指多個線程加鎖時直接嘗試獲取鎖，加鎖失敗時，才會被放入隊列中去。但如果此時鎖剛好可用，那么這個線程可以直接獲取到鎖，所以非公平鎖有可能出現后申請鎖的線程先獲取鎖的場景。優點是可以減少喚起線程的開銷，吞吐效率高，因為線程有幾率不阻塞直接獲得鎖，CPU不必喚醒所有線程。缺點是處于等待隊列中的線程可能會餓死，或者等很久才會獲得鎖。

重入鎖和不可重入鎖

可重入鎖

以Java為例ReentrantLock和Synchronized都是可重入鎖，是指在同一個線程在外層方法獲取鎖的時候,如果其內部調用的方法也有鎖，則可以直接獲取鎖，不會因為之前的鎖還沒釋放而阻塞，一定程度上避免了死鎖。在下面的代碼中，testRoller()和testRunning() 都是加了鎖的兩個方法，因為Synchronized是可重入鎖，所以在testRoller()中調用testRunning()時，可以直接獲取鎖。

/**
 * FileName: TestLock
 * Author:   RollerRunning
 * Date:     2020/12/3 9:34 PM
 * Description:
 */
public class TestLock {
    public synchronized void testRoller() {
        System.out.println("testRoller....");
        testRunning();
    }

    public synchronized void testRunning() {
        System.out.println("testRunning....");
    }
}