下圖匯總了各種鎖和其適用條件
1. 樂觀鎖 VS 悲觀鎖
對於同一個數據的並發操作，悲觀鎖認為自己在使用數據的時候一定有別的線程來修改數據，因此在獲取數據的時候會先加鎖，確保數據不會被別的線程修改。
Java中，synchronized關鍵字和Lock的實現類都是悲觀鎖。
而樂觀鎖認為自己在使用數據時不會有別的線程修改數據，所以不會添加鎖!
樂觀鎖和悲觀鎖的調用方式示例：
/ ------------------------- 悲觀鎖的調用方式 ------------------------- // synchronized public synchronized void testMethod() { // 操作同步資源 } // ReentrantLock private ReentrantLock lock = new ReentrantLock(); // 需要保證多個線程使用的是同一個鎖 public void modifyPublicResources() { lock.lock(); // 操作同步資源 lock.unlock(); } // ------------------------- 樂觀鎖的調用方式 ------------------------- private AtomicInteger atomicInteger = new AtomicInteger(); // 需要保證多個線程使用的是同一個AtomicInteger atomicInteger.incrementAndGet(); //執行自增1
2. 自旋鎖 VS 適應性自旋鎖
在許多場景中，同步資源的鎖定時間很短，為了這一小段時間去切換線程，線程掛起和恢復現場的花費可能會讓系統得不償失。如果物理機器有多個處理器，能夠讓兩個或以上的線程同時並行執行，我們就可以讓后面那個請求鎖的線程不放棄CPU的執行時間，看看持有鎖的線程是否很快就會釋放鎖。
而為了讓當前線程“稍等一下”，我們需讓當前線程進行自旋，如果在自旋完成后前面鎖定同步資源的線程已經釋放了鎖，那么當前線程就可以不必阻塞而是直接獲取同步資源，從而避免切換線程的開銷。這就是自旋鎖。
自旋鎖本身是有缺點的，它不能代替阻塞。自旋等待雖然避免了線程切換的開銷，但它要占用處理器時間。如果鎖被占用的時間很短，自旋等待的效果就會非常好。反之，如果鎖被占用的時間很長，那么自旋的線程只會白浪費處理器資源。所以，自旋等待的時間必須要有一定的限度，如果自旋超過了限定次數（默認是10次，可以使用-XX:PreBlockSpin來更改）沒有成功獲得鎖，就應當掛起線程。
自旋鎖在JDK1.4.2中引入，使用-XX:+UseSpinning來開啟。JDK 6中變為默認開啟，並且引入了自適應的自旋鎖（適應性自旋鎖）。
自適應意味着自旋的時間（次數）不再固定，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。如果在同一個鎖對象上，自旋等待剛剛成功獲得過鎖，並且持有鎖的線程正在運行中，那么虛擬機就會認為這次自旋也是很有可能再次成功，進而它將允許自旋等待持續相對更長的時間。如果對於某個鎖，自旋很少成功獲得過，那在以后嘗試獲取這個鎖時將可能省略掉自旋過程，直接阻塞線程，避免浪費處理器資源。
在自旋鎖中 另有三種常見的鎖形式:TicketLock、CLHlock和MCSlock
3. 無鎖 VS 偏向鎖 VS 輕量級鎖 VS 重量級鎖
這四種鎖是指鎖的狀態，專門針對synchronized的。在介紹這四種鎖狀態之前還需要介紹一些額外的知識。
首先為什么Synchronized能實現線程同步？
在回答這個問題之前我們需要了解兩個重要的概念：“Java對象頭”、“Monitor”。
Java對象頭
synchronized是悲觀鎖，在操作同步資源之前需要給同步資源先加鎖，這把鎖就是存在Java對象頭里的，而Java對象頭又是什么呢？
我們以Hotspot虛擬機為例，Hotspot的對象頭主要包括兩部分數據：Mark Word（標記字段）、Klass Pointer（類型指針）。
Mark Word：默認存儲對象的HashCode，分代年齡和鎖標志位信息。這些信息都是與對象自身定義無關的數據，所以Mark Word被設計成一個非固定的數據結構以便在極小的空間內存存儲盡量多的數據。它會根據對象的狀態復用自己的存儲空間，也就是說在運行期間Mark Word里存儲的數據會隨着鎖標志位的變化而變化。
Klass Point：對象指向它的類元數據的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。
Monitor
Monitor可以理解為一個同步工具或一種同步機制，通常被描述為一個對象。每一個Java對象就有一把看不見的鎖，稱為內部鎖或者Monitor鎖。
Monitor是線程私有的數據結構，每一個線程都有一個可用monitor record列表，同時還有一個全局的可用列表。每一個被鎖住的對象都會和一個monitor關聯，同時monitor中有一個Owner字段存放擁有該鎖的線程的唯一標識，表示該鎖被這個線程占用。
現在話題回到synchronized，synchronized通過Monitor來實現線程同步，Monitor是依賴於底層的操作系統的Mutex Lock（互斥鎖）來實現的線程同步。
如同我們在自旋鎖中提到的“阻塞或喚醒一個Java線程需要操作系統切換CPU狀態來完成，這種狀態轉換需要耗費處理器時間。如果同步代碼塊中的內容過於簡單，狀態轉換消耗的時間有可能比用戶代碼執行的時間還要長”。這種方式就是synchronized最初實現同步的方式，這就是JDK 6之前synchronized效率低的原因。這種依賴於操作系統Mutex Lock所實現的鎖我們稱之為“重量級鎖”，JDK 6中為了減少獲得鎖和釋放鎖帶來的性能消耗，引入了“偏向鎖”和“輕量級鎖”。
所以目前鎖一共有4種狀態，級別從低到高依次是：無鎖、偏向鎖、輕量級鎖和重量級鎖。鎖狀態只能升級不能降級。
通過上面的介紹，我們對synchronized的加鎖機制以及相關知識有了一個了解，那么下面我們給出四種鎖狀態對應的的Mark Word內容，然后再分別講解四種鎖狀態的思路以及特點：
| 鎖狀態 | 存儲內容 | 存儲內容 |
|---|---|---|
| 無鎖 | 對象的hashCode、對象分代年齡、是否是偏向鎖（0） | 01 |
| 偏向鎖 | 偏向線程ID、偏向時間戳、對象分代年齡、是否是偏向鎖（1） | 01 |
| 輕量級鎖 | 指向棧中鎖記錄的指針 | 00 |
| 重量級鎖 | 指向互斥量（重量級鎖）的指針 | 10 |
4. 公平鎖 VS 非公平鎖
公平鎖是指多個線程按照申請鎖的順序來獲取鎖，線程直接進入隊列中排隊，隊列中的第一個線程才能獲得鎖。公平鎖的優點是等待鎖的線程不會餓死。缺點是整體吞吐效率相對非公平鎖要低，等待隊列中除第一個線程以外的所有線程都會阻塞，CPU喚醒阻塞線程的開銷比非公平鎖大。
非公平鎖是多個線程加鎖時直接嘗試獲取鎖，獲取不到才會到等待隊列的隊尾等待。但如果此時鎖剛好可用，那么這個線程可以無需阻塞直接獲取到鎖，所以非公平鎖有可能出現后申請鎖的線程先獲取鎖的場景。非公平鎖的優點是可以減少喚起線程的開銷，整體的吞吐效率高，因為線程有幾率不阻塞直接獲得鎖，CPU不必喚醒所有線程。缺點是處於等待隊列中的線程可能會餓死，或者等很久才會獲得鎖。
5. 可重入鎖 VS 非可重入鎖
可重入鎖又名遞歸鎖，是指在同一個線程在外層方法獲取鎖的時候，再進入該線程的內層方法會自動獲取鎖（前提鎖對象得是同一個對象或者class），不會因為之前已經獲取過還沒釋放而阻塞。Java中ReentrantLock和synchronized都是可重入鎖，可重入鎖的一個優點是可一定程度避免死鎖。下面用示例代碼來進行分析：
public class Widget { public synchronized void doSomething() { System.out.println("方法1執行..."); doOthers(); } public synchronized void doOthers() { System.out.println("方法2執行..."); } }
在上面的代碼中，類中的兩個方法都是被內置鎖synchronized修飾的，doSomething()方法中調用doOthers()方法。因為內置鎖是可重入的，所以同一個線程在調用doOthers()時可以直接獲得當前對象的鎖，進入doOthers()進行操作。
如果是一個不可重入鎖，那么當前線程在調用doOthers()之前需要將執行doSomething()時獲取當前對象的鎖釋放掉，實際上該對象鎖已被當前線程所持有，且無法釋放。所以此時會出現死鎖。
6. 獨享鎖(排它鎖) VS 共享鎖
獨享鎖也叫排他鎖，是指該鎖一次只能被一個線程所持有。如果線程T對數據A加上排它鎖后，則其他線程不能再對A加任何類型的鎖。獲得排它鎖的線程即能讀數據又能修改數據。JDK中的synchronized和JUC中Lock的實現類就是互斥鎖。
共享鎖是指該鎖可被多個線程所持有。如果線程T對數據A加上共享鎖后，則其他線程只能對A再加共享鎖，不能加排它鎖。獲得共享鎖的線程只能讀數據，不能修改數據。
獨享鎖與共享鎖也是通過AQS來實現的，通過實現不同的方法，來實現獨享或者共享。
下圖為ReentrantReadWriteLock的部分源碼：
我們看到ReentrantReadWriteLock有兩把鎖：ReadLock和WriteLock，由詞知意，一個讀鎖一個寫鎖，合稱“讀寫鎖”。再進一步觀察可以發現ReadLock和WriteLock是靠內部類Sync實現的鎖。Sync是AQS的一個子類，這種結構在CountDownLatch、ReentrantLock、Semaphore里面也都存在。
在ReentrantReadWriteLock里面，讀鎖和寫鎖的鎖主體都是Sync，但讀鎖和寫鎖的加鎖方式不一樣。讀鎖是共享鎖，寫鎖是獨享鎖。讀鎖的共享鎖可保證並發讀非常高效，而讀寫、寫讀、寫寫的過程互斥，因為讀鎖和寫鎖是分離的。所以ReentrantReadWriteLock的並發性相比一般的互斥鎖有了很大提升。
參考文章：https://tech.meituan.com/2018/11/15/java-lock.html