推薦閱讀：
年輕人，醒醒吧！此時不搏何時搏！本文主要講一下常見的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....");
}
}
共享鎖和獨佔鎖
獨享鎖
是一種喫獨食的鎖，一次只能被一個線程持有。如果線程A對共享數據獨佔鎖以後，那麼其他線程就都沒有機會再加鎖了，獲得排它鎖的線程就擁有了對該數據的讀寫權限。JDK中的Synchronized以及Lock的實現類就是互斥鎖。
共享鎖
是指這類鎖可被多個線程持有。如果線程A對共享數據加上共享鎖後，則其他線程也只能對共享數據加共享鎖，不能加排它鎖。而獲得共享鎖的線程只能讀數據，不能修改數據。
最後貼一張鎖分類圖：
