干飯人！多執行緒鎖分類你不看看嗎？肆

開篇閑扯

打工人，你是不是也不喜歡吃掛面？吃多了面試容易掛！咔~~好冷的段子，分享一個小故事，中午我物件聊天，她說中午食堂吃的海鮮拌面，我立馬就羨慕的問有啥海鮮，你猜怎么著？人家說就放了兩塊魚豆腐...食堂的文案作業者為了業績也是辛苦了！致敬這不講武德的宣傳

回歸正題，年輕人，醒醒吧！此時不搏何時搏！本文主要講一下常見的CAS理論，因為上文也提到了，但是沒來得及解釋，再者就是說一下鎖的分類，什么樂觀鎖啊，悲觀鎖、重入鎖等等，這篇文章要一網打盡，都介紹一下，最后想說一下，其實這篇文章應該在講Synchronized之前寫的，結果寫的時候搞錯了，可我就是不想改！

把CAS按在地上摩擦

中文名：比較并交換

英文名：Compare And Swap

英文縮寫：CAS

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

解釋一下：當A、B兩個執行緒都操作value值時，執行緒A如果一切順利，會在進行預期值與記憶體值做比較且相等，這個動作是原子化操作，這時候執行原子的修改value值的操作，修改完成后，B執行緒也來修改，發現有敵情，只好原地回圈等待，直到條件符合時才進行記憶體值的操作，還有一點要注意的是，比對和修改兩個動作都是原子的，但是原子操作 + 原子操作 != 原子操作，因此在高并發下存在ABA問題，這個在前面《打工人！肝了這套多執行緒吧！壹》中有說明，感興趣可以翻看一下，多執行緒高并發，搞的額頭沒頭發，

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

鎖的分類

樂觀鎖與悲觀鎖

這二位其實并不是實際存在的鎖，僅僅是對鎖的抽象定義，樂觀鎖的目的就是不加鎖，從而提升效率，這一思想在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....");
    }
}

共享鎖和獨占鎖

獨享鎖

是一種吃獨食的鎖，一次只能被一個執行緒持有，如果執行緒A對共享資料獨占鎖以后，那么其他執行緒就都沒有機會再加鎖了，獲得排它鎖的執行緒就擁有了對該資料的讀寫權限，JDK中的Synchronized以及Lock的實作類就是互斥鎖，

共享鎖

是指這類鎖可被多個執行緒持有，如果執行緒A對共享資料加上共享鎖后，則其他執行緒也只能對共享資料加共享鎖，不能加排它鎖，而獲得共享鎖的執行緒只能讀資料，不能修改資料，

這兩類鎖會在下一篇講Lock時結合實體詳細講解，今天就講到這里，太晚了，睡覺，晚安！

最后貼一張鎖分類圖：

感謝各位觀眾老爺，點贊關注加轉發！謝謝
更多文章請掃碼關注或微信搜索Java堆疊點公眾號！

標籤：Java

上一篇：hi-nginx-java的無配置路由配置

下一篇：批量快速生成員工檔案夾工具