開篇閒扯
打工人，你是不是也不喜歡吃掛麵？吃多了面試容易掛！咔~~好冷的段子。分享一個小故事，中午我物件聊天，她說中午食堂吃的海鮮拌麵。我立馬就羨慕的問有啥海鮮，你猜怎麼著？人家說就放了兩塊魚豆腐...食堂的文案工作者為了業績也是辛苦了！致敬這不講武德的宣傳
迴歸正題，年輕人，醒醒吧！此時不搏何時搏！本文主要講一下常見的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棧點公眾號！
