史上最全 Java 中各種鎖的介紹
更多精彩原創內容請關注：JavaInterview，歡迎 star，支援鼓勵以下作者，萬分感謝。
鎖的分類介紹
樂觀鎖與悲觀鎖
鎖的一種巨集觀分類是樂觀鎖與悲觀鎖。樂觀鎖與悲觀鎖並不是特定的指哪個鎖（Java 中也沒有那個具體鎖的實現名就叫
樂觀鎖或悲觀鎖），而是在併發情況下兩種不同的策略。
樂觀鎖（Optimistic Lock）就是很樂觀，每次去拿資料的時候都認為別人不會修改。所以不會上鎖。但是如果想要更新資料，
則會在更新之前檢查在讀取至更新這段時間別人有沒有修改過這個資料。如果修改過，則重新讀取，再次嘗試更新，迴圈上述
步驟直到更新成功（當然也允許更新失敗的執行緒放棄更新操作）。
悲觀鎖（Pessimistic Lock）就是很悲觀，每次去拿資料的時候都認為別人會修改。所以每次都在拿資料的時候上鎖。
這樣別人拿資料的時候就會被擋住，直到悲觀鎖釋放，想獲取資料的執行緒再去獲取鎖，然後再獲取資料。
悲觀鎖阻塞事務，樂觀鎖回滾重試，它們個有優缺點，沒有好壞之分，只有適應場景的不同區別。比如：樂觀鎖適合用於寫
比較少的情況下，即衝突真的很少發生的場景，這樣可以省去鎖的開銷，加大了系統的整個吞吐量。但是如果經常產生衝突，上層
應用會不斷的進行重試，這樣反而降低了效能，所以這種場景悲觀鎖比較合適。
總結：樂觀鎖適合寫比較少，衝突很少發生的場景；而寫多，衝突多的場景適合使用悲觀鎖。
樂觀鎖的基礎 --- CAS
在樂觀鎖的實現中，我們必須要了解的一個概念：CAS。
什麼是 CAS 呢？ Compare-and-Swap，即比較並替換，或者比較並設定。
比較：讀取到一個值 A，在將其更新為 B 之前，檢查原值是否為 A（未被其它執行緒修改過，這裡忽略 ABA 問題）。
替換：如果是，更新 A 為 B，結束。如果不是，則不會更新。
上面兩個步驟都是原子操作，可以理解為瞬間完成，在 CPU 看來就是一步操作。
有了 CAS，就可以實現一個樂觀鎖：
public class OptimisticLockSample{ public void test(){ int data = 123; // 共享資料 // 更新資料的執行緒會進行如下操作 for (;;) { int oldData = data; int newData = doSomething(oldData); // 下面是模擬 CAS 更新操作，嘗試更新 data 的值 if (data == oldData) { // compare data = newData; // swap break; // finish } else { // 什麼都不做，迴圈重試 } } } /** * * 很明顯，test() 裡面的程式碼根本不是原子性的，只是展示了下 CAS 的流程。 * 因為真正的 CAS 利用了 CPU 指令。 * * */ }
在 Java 中也是通過 native 方法實現的 CAS。
public final class Unsafe {
...
public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);
...
}
上面寫了一個簡單直觀的樂觀鎖（確切的來說應該是樂觀鎖流程）的實現，它允許多個執行緒同時讀取（因為根本沒有加鎖操作），如果更新資料的話，
有且僅有一個執行緒可以成功更新資料，並導致其它執行緒需要回滾重試。CAS 利用 CPU 指令，從硬體層面保證了原子性，以達到類似於鎖的效果。
從樂觀鎖的整個流程中可以看出，並沒有加鎖和解鎖的操作，因此樂觀鎖策略也被稱作為無鎖程式設計。換句話說，樂觀鎖其實不是"鎖"，
它僅僅是一個迴圈重試的 CAS 演算法而已。
自旋鎖
synchronized 與 Lock interface
Java 中兩種實現加鎖的方式：一種是使用 synchronized 關鍵字，另一種是使用 Lock 介面的實現類。
在一篇文章中看到一個好的對比，非常形象，synchronized 關鍵字就像是自動擋，可以滿足一切的駕駛需求。
但是如果你想要做更高階的操作，比如玩漂移或者各種高階的騷操作，那麼就需要手動擋，也就是 Lock 介面的實現類。
而 synchronized 在經過 Java 每個版本的各種優化後，效率也變得很高了。只是使用起來沒有 Lock 介面的實現類那麼方便。
synchronized 鎖升級過程就是其優化的核心：偏向鎖 -> 輕量級鎖 -> 重量級鎖
class Test{
private static final Object object = new Object();
public void test(){
synchronized(object) {
// do something
}
}
}
使用 synchronized 關鍵字鎖住某個程式碼塊的時候，一開始鎖物件（就是上述程式碼中的 object）並不是重量級鎖，而是偏向鎖。
偏向鎖的字面意思就是"偏向於第一個獲取它的執行緒"的鎖。執行緒執行完同步程式碼塊之後，並不會主動釋放偏向鎖。當第二次到達同步
程式碼塊時，執行緒會判斷此時持有鎖的執行緒是否就是自己（持有鎖的執行緒 ID 在物件頭裡儲存），如果是則正常往下執行。由於之前沒有釋放，
這裡就不需要重新加鎖，如果從頭到尾都是一個執行緒在使用鎖，很明顯偏向鎖幾乎沒有額外開銷，效能極高。
一旦有第二個執行緒加入鎖競爭，偏向鎖轉換為輕量級鎖（自旋鎖）。鎖競爭：如果多個執行緒輪流獲取一個鎖，但是每次獲取的時候
都很順利，沒有發生阻塞，那麼就不存在鎖競爭。只有當某執行緒獲取鎖的時候，發現鎖已經被佔用，需要等待其釋放，則說明發生了鎖競爭。
在輕量級鎖狀態上繼續鎖競爭，沒有搶到鎖的執行緒進行自旋操作，即在一個迴圈中不停判斷是否可以獲取鎖。獲取鎖的操作，就是通過 CAS 操
作修改物件頭裡的鎖標誌位。先比較當前鎖標誌位是否為釋放狀態，如果是，將其設定為鎖定狀態，比較並設定是原子性操作，這個
是 JVM 層面保證的。當前執行緒就算持有了鎖，然後執行緒將當前鎖的持有者資訊改為自己。
假如我們獲取到鎖的執行緒操作時間很長，比如會進行復雜的計算，資料量很大的網路傳輸等；那麼其它等待鎖的執行緒就會進入長時間的自旋操作，這個
過程是非常耗資源的。其實這時候相當於只有一個執行緒在有效地工作，其它的執行緒什麼都幹不了，在白白地消耗 CPU，這種現象叫做忙等
（busy-waiting）。所以如果多個執行緒使用獨佔鎖，但是沒有發生鎖競爭，或者發生了很輕微的鎖競爭，那麼 synchronized 就是輕量
級鎖，允許短時間的忙等現象。這是一種擇中的想法，短時間的忙等，換取執行緒在使用者態和核心態之間切換的開銷。
顯然，忙等是有限度的（JVM 有一個計數器記錄自旋次數，預設允許迴圈 10 次，可以通過虛擬機器引數更改）。如果鎖競爭情況嚴重，
達到某個最大自旋次數的執行緒，會將輕量級鎖升級為重量級鎖（依然是通過 CAS 修改鎖標誌位，但不修改持有鎖的執行緒 ID）。當後續執行緒嘗試獲取
鎖時，發現被佔用的鎖是重量級鎖，則直接將自己掛起（而不是上面說的忙等，即不會自旋），等待釋放鎖的執行緒去喚醒。在 JDK1.6 之前， synchronized
直接加重量級鎖，很明顯現在通過一系列的優化過後，效能明顯得到了提升。
JVM 中，synchronized 鎖只能按照偏向鎖、輕量級鎖、重量級鎖的順序逐漸升級（也有把這個稱為鎖膨脹的過程），不允許降級。
可重入鎖（遞迴鎖）
可重入鎖的字面意思是"可以重新進入的鎖"，即允許同一個執行緒多次獲取同一把鎖。比如一個遞迴函式裡有加鎖操作，遞迴函式裡這個鎖會阻塞自己麼？
如果不會，那麼這個鎖就叫可重入鎖（因為這個原因可重入鎖也叫做遞迴鎖）。
Java 中以 Reentrant 開頭命名的鎖都是可重入鎖，而且 JDK 提供的所有現成 Lock 的實現類，包括 synchronized 關鍵字鎖都是可重入的。
如果真的需要不可重入鎖，那麼就需要自己去實現了，獲取去網上搜索一下，有很多，自己實現起來也很簡單。
如果不是可重入鎖，在遞迴函式中就會造成死鎖，所以 Java 中的鎖基本都是可重入鎖，不可重入鎖的意義不是很大，我暫時沒有想到什麼場景下會用到；
注意：有想到需要不可重入鎖場景的小夥伴們可以留言一起探討。
下圖展示一下 Lock 的相關實現類：
公平鎖和非公平鎖
如果多個執行緒申請一把公平鎖，那麼獲得鎖的執行緒釋放鎖的時候，先申請的先得到，很公平。如果是非公平鎖，後申請的執行緒可能先獲得鎖，是
隨機獲取還是其它方式，都是根據實現演算法而定的。
對 ReentrantLock 類來說，通過建構函式可以指定該鎖是否是公平鎖，預設是非公平鎖。因為在大多數情況下，非公平鎖的吞吐量比公平鎖的大，
如果沒有特殊要求，優先考慮使用非公平鎖。
而對於 synchronized 鎖而言，它只能是一種非公平鎖，沒有任何方式使其變成公平鎖。這也是 ReentrantLock 相對於 synchronized 鎖的一個
優點，更加的靈活。
以下是 ReentrantLock 構造器程式碼：
/**
* Creates an instance of {@code ReentrantLock} with the
* given fairness policy.
*
* @param fair {@code true} if this lock should use a fair ordering policy
*/
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
ReentrantLock 內部實現了 FairSync 和 NonfairSync 兩個內部類來實現公平鎖和非公平鎖。具體原始碼分析會在接下來的章節給出，敬請關注
該專案，歡迎 fork和 star。
可中斷鎖
字面意思是"可以響應中斷的鎖"。
首先，我們需要理解的是什麼是中斷。 Java 中並沒有提供任何可以直接中斷執行緒的方法，只提供了中斷機制。那麼何為中斷機制呢？
執行緒 A 向執行緒 B 發出"請你停止執行"的請求，就是呼叫 Thread.interrupt() 的方法（當然執行緒 B 本身也可以給自己傳送中斷請求，
即 Thread.currentThread().interrupt()），但執行緒 B 並不會立即停止執行，而是自行選擇在合適的時間點以自己的方式響應中斷，也可以
直接忽略此中斷。也就是說，Java 的中斷不能直接終止執行緒，只是設定了狀態為響應中斷的狀態，需要被中斷的執行緒自己決定怎麼處理。這就像
在讀書的時候，老師在晚自習時叫學生自己複習功課，但學生是否複習功課，怎麼複習功課則完全取決於學生自己。
回到鎖的分析上來，如果執行緒 A 持有鎖，執行緒 B 等待持獲取該鎖。由於執行緒 A 持有鎖的時間過長，執行緒 B 不想繼續等了，我們可以讓執行緒 B 中斷
自己或者在別的執行緒裡面中斷 B，這種就是 可中段鎖。
在 Java 中， synchronized 鎖是不可中斷鎖，而 Lock 的實現類都是 可中斷鎖。從而可以看出 JDK 自己實現的 Lock 鎖更加的
靈活，這也就是有了 synchronized 鎖後，為什麼還要實現那麼些 Lock 的實現類。
Lock 介面的相關定義：
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
Condition newCondition();
}
其中 lockInterruptibly 就是獲取可中斷鎖。
共享鎖
字面意思是多個執行緒可以共享一個鎖。一般用共享鎖都是在讀資料的時候，比如我們可以允許 10 個執行緒同時讀取一份共享資料，這時候我們
可以設定一個有 10 個憑證的共享鎖。
在 Java 中，也有具體的共享鎖實現類，比如 Semaphore。 該類的原始碼分析會在後續章節進行分析，敬請關注該專案，歡迎 fork和 star。
互斥鎖
字面意思是執行緒之間互相排斥的鎖，也就是表明鎖只能被一個執行緒擁有。
在 Java 中， ReentrantLock、synchronized 鎖都是互斥鎖。
讀寫鎖
讀寫鎖其實是一對鎖，一個讀鎖（共享鎖）和一個寫鎖（互斥鎖、排他鎖）。
在 Java 中， ReadWriteLock 介面只規定了兩個方法，一個返回讀鎖，一個返回寫鎖。
public interface ReadWriteLock {
/**
* Returns the lock used for reading.
*
* @return the lock used for reading
*/
Lock readLock();
/**
* Returns the lock used for writing.
*
* @return the lock used for writing
*/
Lock writeLock();
}
文章前面講過樂觀鎖策略，所有執行緒可以隨時讀，僅在寫之前判斷值有沒有被更改。
讀寫鎖其實做的事情是一樣的，但是策略稍有不同。很多情況下，執行緒知道自己讀取資料後，是否是為了更改它。那麼為何不在加鎖的時候直接明確
這一點呢？如果我讀取值是為了更新它（SQL 的 for update 就是這個意思），那麼加鎖的時候直接加寫鎖，我持有寫鎖的時候，別的執行緒
無論是讀還是寫都需要等待；如果讀取資料僅僅是為了前端展示，那麼加鎖時就明確加一個讀鎖，其它執行緒如果也要加讀鎖，不需要等待，可以
直接獲取（讀鎖計數器加 1）。
雖然讀寫鎖感覺與樂觀鎖有點像，但是讀寫鎖是悲觀鎖策略。因為讀寫鎖並沒有在更新前判斷值有沒有被修改過，而是在加鎖前決定
應該用讀鎖還是寫鎖。樂觀鎖特指無鎖程式設計。
JDK 內部提供了一個唯一一個 ReadWriteLock 介面實現類是 ReentrantReadWriteLock。通過名字可以看到該鎖提供了讀寫鎖，並且也是
可重入鎖。
總結
Java 中使用的各種鎖基本都是悲觀鎖，那麼 Java 中有樂觀鎖麼？結果是肯定的，那就是 java.util.concurrent.atomic 下面的
原子類都是通過樂觀鎖實現的。如下：
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
通過上述原始碼可以發現，在一個迴圈裡面不斷 CAS，直到成功為止。
引數介紹
-XX:-UseBiasedLocking=false 關閉偏向鎖
JDK1.6
-XX:+UseSpinning 開啟自旋鎖
-XX:PreBlockSpin=10 設定自旋次數
JDK1.7 之後 去掉此引數，由 JVM 控制