JDK內置鎖深入探究

一、序言

本文講述僅針對 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 技術對兩者舉例，以致于讓它們的邊界比較模糊，

除了原子操作類中用樂觀鎖處理讀寫外，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);
}

喜歡本文就【??推薦??】一下，激勵我持續創作，這個Github同樣精彩，收到您的star我會很激動，本文歸檔在專題博客，視頻講解在B站，

標籤：Java

上一篇：Spring 原始碼（5）BeanFactory使用的準備及自定義屬性值決議器

下一篇：Java 18 新特性：簡單Web服務器 jwebserver