一、序言
本文講述僅針對 JVM 層次的內建鎖，不涉及分散式鎖。
鎖有多種分類形式，比如公平鎖與非公平鎖、可重入鎖與非重入鎖、獨享鎖與共享鎖、樂觀鎖與悲觀鎖、互斥鎖與讀寫鎖、自旋鎖、分段鎖和偏向鎖/輕量級鎖/重量級鎖。
下面將配合示例講解各種鎖的概念，期望能夠達到如下目標：一是在生產環境中不錯誤的使用鎖；二是在生產環境中選擇恰當的鎖。
對鎖瞭解不多的情況下，應該首先保證業務的正確性，然後考慮效能，比如萬金油synchronized鎖或者自帶多重屬性的ReentrantReadWriteLock鎖。不因併發導致業務錯誤，不出現死鎖。
隨著對鎖的瞭解增多，需要更加精準的選擇各類鎖以保證更高效能要求。
二、鎖的分類
Java 中有兩種加鎖的方式：一是 synchronized 關鍵字，二是用 Lock 介面的實現類。
需要通過加（互斥）鎖來解決執行緒安全問題的鎖稱之為悲觀鎖；不通過加鎖來解決執行緒安全問題的鎖稱之為樂觀鎖。
鎖的效能比較：互斥鎖 < 讀寫鎖、自旋鎖 < 樂觀鎖。
讀寫鎖和自旋鎖分別從兩個不同角度提升鎖的效率，前者通過共享讀鎖來提高效率；後者通過迴避阻塞-喚醒上下文切換來提高效率。
（一）公平鎖/非公平鎖
公平鎖和非公平鎖具體實現類有Semaphore、ReentrantLock和ReentrantReadWriteLock。
公平與否是指參與競爭的執行緒是否都有機會獲得鎖，公平鎖：多個執行緒按照申請鎖的順序來獲取鎖；非公平鎖並不是按照申請鎖的順序來獲取鎖，極端情況下可能會有執行緒一直無法獲取到鎖。
公平鎖維護一個虛擬的先進先出佇列，按照次序排隊申請獲取鎖。
1、概念解讀
為何按鎖的申請順序按照先進先出的順序獲取鎖能夠保證公平？當採用先進先出的排隊機制時，所有處於等待佇列中的執行緒理論上都有機會獲得鎖，並且隨著時間的推移，獲得鎖的機會越來越大。
不是按照申請鎖的順序來獲取鎖如何解讀？synchronized 鎖是典型的非公平鎖，表現形式是所有參與獲取鎖的執行緒是否能夠獲得鎖是不可預測的。
公平鎖的深層次內涵是隻要執行緒有獲得鎖的需求，在絕對的時間裡，一定能夠獲得鎖。比如伺服器連線資源，不存在客戶端連線不上的情況，這是公平鎖的典型的應用。
2、鎖程式碼層次表示
Semaphore
// 非公平鎖
Semaphore unfairLock = new Semaphore(5);
// 公平鎖
Semaphore fairLock = new Semaphore(5,true);
ReentrantLock
// 非公平鎖
ReentrantLock unfairLock = new ReentrantLock();
// 公平鎖
ReentrantLock fairLock = new ReentrantLock(true);
ReentrantReadWriteLock
// 非公平鎖
ReentrantReadWriteLock unfairLock = new ReentrantReadWriteLock();
// 公平可鎖
ReentrantReadWriteLock fairLock = new ReentrantReadWriteLock(true);
上面提到的 3 個鎖的實現類能配置公平鎖或者非公平鎖，真正實現鎖的公平與否是由AbstractQueuedSynchronizer抽象類的子類定義的。
3、優劣對比
| 鎖 | 獲取鎖事件 | 鎖的效率 | 備註 |
|---|---|---|---|
| 公平鎖 | 可以樂觀估計 | 相對較低 | |
| 非公平鎖 | 飢餓狀態 | 相對較高 | 如果對鎖沒有特別的要求，優先選用非公平鎖 |
公平鎖的效率比非公平鎖低的原因如下：
- 所有想獲取鎖的執行緒必須先到先進先出佇列註冊，排隊才能獲取鎖，從獲取鎖的流程上增加額外的操作；
- 有佇列必然涉及執行緒的阻塞與喚醒操作，增加了作業系統層次上下文切換排程開銷。
（二）可重入鎖/非可重入鎖
可重入鎖是指某個執行緒獲得特定鎖後，同一個執行緒內可以多次獲得該鎖。synchronized關鍵字、ReentrantLock和ReentrantReadWriteLock屬於可重入鎖，Jdk 內建除此之外其它的鎖都是不可重入鎖。
可重入鎖有兩個重要的特性：同一個執行緒、重複獲取鎖。
1、可重入鎖必要性分析
可重入鎖能夠避免同一執行緒多次獲取鎖時的死鎖現象。
/**
* 競爭執行緒呼叫入口方法
*/
public synchronized void facadeMethod(){
// 處理業務
innerMethod();
}
public void innerMethod(){
// 處理業務
}
當只在呼叫入口方法上新增 synchronized 鎖，內部呼叫鏈所涉及的方法都不新增鎖，線上程競爭條件下也是執行緒安全的。這種條件下即使 synchronized 不是可重入鎖，也不會發生死鎖。原因如下：方法呼叫是以方法棧的形式呼叫的，在入口方法加鎖相當於內部呼叫鏈的方法都鎖的約束之下，因此是執行緒安全的。
2、非可重入鎖危害程度分析
假如 synchronized 不是可重入鎖，業務層有死鎖發生時，應用在測試環境壓測必然能夠發現，未進入生產環境便可提前處理。因為這種死鎖是一種必然發生事件，排查起來較為容易。
當死鎖發生時，第一步排查當前鎖是否是可重入的，其次再考慮是否是業務層程式碼邏輯本身存在缺陷。
/**
* 競爭執行緒呼叫入口方法
*/
public synchronized void facadeMethod(){
// 處理業務
innerMethod();
}
public synchronized void innerMethod(){
// 處理業務
}
可重入鎖是對鎖的一次改良，提高了開發效率是顯而易見的，與此同時也給使用鎖的使用者造成不必要的困擾：在使用鎖的過程中，是否可重入並不是避免死鎖的充分條件。
（三）獨享鎖/共享鎖
獨享鎖是指該鎖一次只能被一個執行緒所持有；共享鎖是指該鎖可被多個執行緒所持有。實現ReadWriteLock介面的鎖，其中讀鎖是共享鎖、寫鎖是獨享鎖。
在內建的鎖中，除了讀寫鎖中的讀鎖是共享鎖，其餘皆是獨享鎖。
1、降低鎖的顆粒度
競爭執行緒在處理競爭資源時有如下四種情形：讀讀、讀寫、寫讀、寫寫，對於大部分應用來說，讀操作的比寫操作的頻度要高，更清楚的表述是在大部分時間裡讀讀是執行緒間處理競爭資源形態，因此降低鎖的顆粒度現實意義比較明顯。
2、共享讀鎖與樂觀讀鎖
共享讀鎖是為了解決獨佔鎖只能被一個執行緒佔有的問題，它支援多個執行緒同時持有鎖，本質上屬於悲觀鎖的範疇。
樂觀讀鎖更為徹底，將加鎖的環節取消，但通過特殊機制仍能夠保證執行緒安全。
加鎖和釋放鎖是一個重操作，因此樂觀讀鎖比共享讀鎖效率更高。
鎖的彙總
// 非公平可重入讀寫鎖
ReentrantReadWriteLock unfairLock = new ReentrantReadWriteLock();
// 公平可重入讀寫鎖
ReentrantReadWriteLock fairLock = new ReentrantReadWriteLock(true);
（四）樂觀鎖/悲觀鎖
樂觀鎖與悲觀鎖的內涵是當併發發生時處理併發同步的態度。悲觀鎖認為當併發發生時，被鎖的物件一定會發生修改，如果放任不管，併發操作一定會給業務帶來副作用。
悲觀鎖需要加鎖，樂觀鎖不加鎖但仍能通過一定機制保證執行緒安全。
互斥鎖、自旋鎖、讀寫鎖都屬於悲觀鎖。
1、典型樂觀鎖
嚴格意義來講，只有悲觀鎖才能稱之為鎖，樂觀鎖本身不通過加鎖來解決併發問題，因此稱之為樂觀“鎖”更合適。
樂觀“鎖”處理併發問題有兩種常見方式：一是以AtomicInteger為代表的原子操作類，這種處理方式本身不加鎖，但仍能解決併發產生的問題；二是樂觀鎖StampedLock類中的樂觀讀。
（五）自旋鎖
自旋鎖是相對於互斥鎖而言的，本質上屬於悲觀鎖的一種（仍然需要加鎖）。
1、自旋鎖的原理
當執行緒申請獲取鎖時，發現已經被其它執行緒佔有，此時不斷的迴圈嘗試獲取鎖，直到獲取鎖成功。執行緒自旋獲取鎖需要消耗 CPU，如果一直獲取不到鎖，執行緒會一直自旋，持續消耗 CPU。
自旋鎖是對執行緒申請獲取鎖時出現的阻塞與喚醒上下文切換的一種優化，即用 CPU 資源換取執行緒狀態切換時間，當執行緒通過自旋獲取鎖的時間超過普通的阻塞-喚醒排程時間，那麼就不適合選用自旋鎖。
2、自旋鎖使用場景及優缺點
（1）使用場景
如果持有鎖的執行緒能在很短時間內釋放鎖資源，選用自旋鎖非常合適。執行緒平均佔有鎖的時間很短，其它執行緒稍微等待（自旋）便能立刻獲取鎖，效率比阻塞-喚醒執行緒狀態切換高得多。
一般而言，競爭資源涉及記憶體計算時，佔有鎖的時間平均都比較短，適合自旋鎖；對於磁碟讀寫 IO 操作、網路操作等，執行緒佔有鎖的時間平均較長，不適合使用自旋鎖。
程式碼塊或者輕量級方法，執行緒競爭不激烈的場景下，適合自旋鎖。
（2）優缺點
自旋鎖儘可能的減少執行緒的阻塞，對於鎖的競爭不激烈且佔用鎖時間非常短的程式碼塊來說效能提升明顯。自旋的時間消耗會小於執行緒阻塞掛起再喚醒的操作的消耗，迴避了執行緒兩次上下文切換。
3、自旋鎖與樂觀鎖
自旋鎖與樂觀鎖的區別是很明顯的，很多地方常用 CAS 技術對兩者舉例，以致於讓它們的邊界比較模糊。
| 鎖 | 樂觀（悲觀）鎖 | 獨佔（共享）鎖 | 消耗 CPU 資源的目的 | 提升效率優化核心點 |
|---|---|---|---|---|
| 自旋鎖 | 悲觀鎖 | 獨佔鎖 | 申請獲取鎖 | 用 CPU 資源置換執行緒阻塞-喚醒排程時間 |
| 樂觀鎖 | 樂觀鎖 | 共享鎖 | 比較與交換 | 不加鎖，如果需要處理執行緒問題，則採取相應的措施 |
除了原子操作類中用樂觀鎖處理讀寫外，StampedLock類主要用到樂觀讀鎖。
三、關鍵字鎖
synchronized關鍵字屬於內建鎖，可作用於物件和方法。新增到方法上的鎖，鎖到在哪裡？
對於例項方法，鎖新增到持有方法的例項上；對於類方法，鎖新增到類物件（Class 物件）上。
（一）感性認識
關鍵字synchronized建立的是一把可重入的鎖，不是簡單的輕量級或者重量級的鎖，也不是簡單的公平與非公平鎖。
Java8 內建的synchronized是經過優化的鎖，有偏向鎖、輕量級鎖、重量級鎖等狀態。
重量級鎖影響效能的根本原因是伴隨著加鎖與釋放鎖，競爭鎖的工作執行緒發生上下文切換。
1、公平性分析
鎖處於輕量級時，因為不存線上程間獲取鎖的實質性碰撞行為，理論情況下“競爭”執行緒不存在飢餓狀態的發生，因此屬於公平鎖。
鎖處於重量級時，無法保證競爭執行緒一定不存在飢餓狀態發生，因此屬於非公平鎖。
2、非公平如何理解
使用 synchronized 加鎖的執行緒，沒有先進先出的佇列機制保證有序獲取鎖，因此它是非公平鎖。
（1）競爭執行緒隨機獲取鎖？
隨機必然伴隨著概率事件，獲取鎖既有成功的概率也有失敗的概率，如果是嚴格隨機，理論情況下是不存在飢餓狀態發生的，這種情況下也就不屬於非公平鎖之說。
競爭執行緒不是隨機獲取鎖，儘管從執行緒的角度看像是一種“隨機”行為，因此它是一把非公平鎖。
（2）競爭執行緒可預測獲取鎖？
（重量級鎖）在競爭鎖條件下必然存在作業系統級別的（執行緒阻塞與喚醒）系統排程行為。作業系統的排程是按照既定的規則進行執行緒排程的，執行緒被作業系統喚醒，才有機會獲取鎖，因此可以粗略的理解獲取鎖的行為也是可以預測的。
（3）可預測獲取鎖是公平鎖？
假如作業系統是按照優先順序高低完成執行緒排程的，極端情況下，新申請獲取鎖的執行緒優先順序永遠比等待佇列中執行緒優先順序要高，那麼等待佇列必然會發生飢餓狀態，因此儘管獲取鎖的行為是有規律的、能夠預測的，它依然是非公平鎖。
3、互斥鎖
互斥鎖即重量級鎖，互斥依靠通過作業系統來實現。
互斥的表現形式如下：當多執行緒競爭資源條件下，未獲得鎖的其它執行緒均處於阻塞狀態，當持有鎖的執行緒釋放鎖後，阻塞狀態的執行緒被喚醒競爭獲取鎖，未獲取成功的鎖繼續阻塞，如此迴圈。執行緒排程需要作業系統切換上下文，佔用 CPU 時間，影響效能。
作業系統 CPU 時間片大致可分為兩類，一是工作時間；二是排程時間，排程時間越長相應的便會縮短工作時長。
（二）鎖的膨脹
這裡不講鎖的膨脹過程，只講鎖在膨脹過程中涉及的中間狀態，以及如何理解。鎖的膨脹是單向的，只能升級不能降級。
1、偏向鎖
執行緒間不存在鎖的競爭行為，至多隻有一個執行緒有獲取鎖的需求，常見場景為單執行緒程式。
2、輕量級鎖
執行緒間存在鎖的偽競爭行為，即同一時刻絕對不會存在兩個執行緒申請獲取鎖，各執行緒儘管都有使用鎖的需求，但是是交替使用鎖。
3、重量級鎖
執行緒間存在鎖的實質性競爭行為，執行緒間都有獲取鎖的需求，但是時間不可交錯，互斥鎖的阻塞等待。
四、介面鎖
（一）Lock
Lock是所有介面實現類的父類介面，定義了鎖操作的基本規範。
public interface Lock {
// 阻塞等待獲取鎖
void lock();
// 阻塞等待獲取鎖（可相應中斷）
void lockInterruptibly() throws InterruptedException;
// 非阻塞獲取鎖
boolean tryLock();
// 等待指定時間非阻塞獲取鎖
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
// 釋放鎖
void unlock();
}
（二）StampedLock
1、StampedLock優勢
高效能
StampedLock在讀執行緒非常多而寫執行緒較少的場景下效能非常高，樂觀讀鎖屬於無鎖程式設計，可以簡單理解為沒有加鎖。
迴避寫鎖飢餓
非公平讀寫鎖在讀多寫少的場景下可能發生寫鎖飢餓，而在高併發的場景下，都會優先使用非公平鎖。StampedLock能解決這個矛盾問題：既能使用非公平讀寫鎖，又能迴避寫鎖飢餓。
迴避寫鎖飢餓的機制是能將任一讀鎖轉化為寫鎖。
2、典型應用
排它寫鎖
/**
* 排它寫鎖（an exclusively locked method）
*/
void move(double deltaX, double deltaY) {
long stamp = stampedLock.writeLock();
try {
x += deltaX;
y += deltaY;
} finally {
stampedLock.unlockWrite(stamp);
}
}
排它寫鎖能安全的修改資料，在為釋放鎖之前，其它執行緒無法獲取鎖。
此種方式可能會發生寫鎖飢餓的情況。
排它寫鎖（改進）
普通寫鎖可能會發生寫鎖飢餓，下面方式能夠避免寫鎖飢餓——讀鎖轉寫鎖。
/**
* 無飢餓寫鎖
*/
void moveNoHunger(double deltaX, double deltaY) {
long stamp = stampedLock.readLock();
try {
while (x == 0.0 && y == 0.0) {
long ws = stampedLock.tryConvertToWriteLock(stamp);
if (ws != 0L) {
stamp = ws;
x += deltaX;
y += deltaY;
break;
} else {
stampedLock.unlockRead(stamp);
stamp = stampedLock.writeLock();
}
}
} finally {
stampedLock.unlock(stamp);
}
}
樂觀鎖
/**
* 樂觀讀鎖
*/
double distanceFromOrigin() { // A read-only method
long stamp = stampedLock.tryOptimisticRead();
double currentX = x, currentY = y;
if (!stampedLock.validate(stamp)) {
stamp = stampedLock.readLock();
try {
currentX = x;
currentY = y;
} finally {
stampedLock.unlockRead(stamp);
}
}
return Math.sqrt(currentX * currentX + currentY * currentY);
}