JDK內置鎖深入探究

2022 年 4 月 20 日
筆記
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 技術對兩者舉例，以致於讓它們的邊界比較模糊。

鎖	樂觀（悲觀）鎖	獨佔（共享）鎖	消耗 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);
}

Tags: JDK鎖鎖