JDK并發包中的ReentrantLock函數有什么作用

這篇文章主要講解了“JDK并發包中的ReentrantLock函數有什么作用”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“JDK并發包中的ReentrantLock函數有什么作用”吧！

顯式鎖-Lock與ReadWriteLock

JDK針對Lock的主要實現是ReentrantLock，ReadWriteLock實現是ReentrantReadWriteLock。

ReentrantReadWriteLock

兩把鎖共享一個等待隊列，兩把鎖的狀態都由一個原子變量表示，特有的獲取鎖和釋放鎖邏輯。

ReentrantReadWriteLock的基本原理：

• 讀鎖的獲取,只要求寫鎖沒有被線程持有就可以獲取，檢查等待隊列，逐個喚醒等待讀鎖線程，遇到等待寫鎖線程則停止.

• 讀鎖的釋放,釋放后，檢查寫鎖和讀鎖是否被持有，若都沒有被持有則喚醒下一個等待線程.

• 寫鎖的獲取,只有讀寫鎖都未被持有才會獲取寫鎖。

• 寫鎖的釋放，喚醒等待隊列的下一個線程。

ReentrantLock

主要方法

• void lock();獲取鎖，阻塞，不響應中斷，但會記錄中斷標志位。

• void lockInterruptibly() throws InterruptedException;獲取鎖，響應中斷

• boolean tryLock();獲取鎖，不阻塞，實時返回，一般需循環調用

• boolean tryLock(long time, TimeUnit unit) throws InterruptedException;在time的時間內阻塞獲取鎖，響應中斷

• void unlock();釋放鎖

• Condition newCondition();新建顯式條件

注： 這里的響應中斷意思是若被其他線程中斷（調用interrupt方法）會拋出InterruptedException異常。

原理支持

1. 依賴CAS方法,可重入實現用的計數就是用的原子變量。

2. 依賴LockSupport中的方法:

• public static void park()：放棄CPU執行權，CPU不在進行調度，響應中斷，當有中斷發生時，park會返回，線程中斷狀態會被設置，另外park也有可能無緣無故的返回，所以一般需要循環檢查park的等待條件是否滿足。。

• public static void parkNanos(long nanos)：在nanos納秒內放棄CPU執行權

• public static void parkUntil(long deadline)：放棄執行權直到deadline時間（距離1970年毫秒數）。

• public static void unpark(Thread thread)：重新恢復線程，讓其爭奪CPU執行權。

實現基礎AQS

AQS-AbstractQueuedSynchronizer（抽象隊列同步器）。

ReadWriteLock在內部注入了AbstractQueuedSynchronizer，上鎖和釋放鎖核心方法都在AQS類當中，AQS維護了兩個核心變量，一個是state（當前可重入計數，初始值為0），一個是exclusiveOwnerThread（當前持有鎖的線程Thread對象）。另外還維護了一個鎖等待隊列。

ReentrantLock構造方法傳入的boolean值ture為公平鎖，false為不公平鎖。以不公平鎖為例先講一下上鎖和釋放鎖的原理：

上鎖

1. 如果當前鎖狀態為0（未被鎖），則使用CAS獲得鎖，并設置當前鎖內的線程為自己。

2. 如果不為0，且持有鎖的線程不是自己，則添加到隊列尾部，并調用LockSupport中的park()方法放棄CPU執行權。直到當鎖被釋放的時候被喚醒，被喚醒后檢查自己是否是第一個等待的線程，如果是且能獲得鎖，則返回，否則繼續等待，這個過程中如果發生了中斷，lock會記錄中斷標志位，但不會提前返回或拋出異常。

3. 如果不為0，但持有鎖線程是自己，則直接將state加1。

釋放鎖

就是將AQS內的state變量的值遞減1，如果state值為0，則徹底釋放鎖，會將“加鎖線程”變量也設置為null，同時喚醒等待隊列中的第一個線程。

公平鎖

為什么說上面的是不公平鎖，釋放鎖時不是喚醒隊列中第一個線程嗎？為什么還會出現不公平的情況了，原因在于如果剛好釋放鎖，此時有一個線程進來嘗試獲取鎖，可能會存在插隊的情況。

公平鎖原理

構造方法bollean傳入true則代表的是公平鎖，在獲取鎖方法中多了一個檢查，意義是只有不存在其他等待時間更長的線程，它才會嘗試獲取鎖。對比不公平鎖，其整體性能比較低，低的原因不是這個檢查慢，而是會讓活躍線程得不到鎖，進入等待狀態，引起上下文切換，降低了整體的效率，

與synchrnized的區別

• tryLock可避免死鎖造成的無限等待

• 擁有獲取鎖信息方法的各種API

• 可以響應中斷

• 可以限時

建議： synchronized以前的效率不如顯式鎖，但現在的版本兩者效率上幾乎沒有區別，所以建議能用synchronized就用synchronized，需要實現synchronized辦不到的需求如以上區別時，再考慮ReentrantLock。

顯示條件

什么是顯示條件

與wait和notify對應，用于線程協作，通過Lock的Condition newCondition()方法創建對應顯示鎖的顯示條件;

方法

主要方法是await()和signal()，await()對應于Object的wait()，signal()對應于notify，signalAll()對應于notifyAll()

用法示例

public class WaitThread extends Thread {
    private volatile boolean fire = false;
    private Lock lock = new ReentrantLock();
    private Condition condition = lock.newCondition();

    @Override
    public void run() {
        try {
            lock.lock();
            try {
                while (!fire) {
                    condition.await();
                }
            } finally {
                lock.unlock();
            }
            System.out.println("fired");
        } catch (InterruptedException e) {
            Thread.interrupted();
        }
    }

    public void fire() {
        lock.lock();
        try {
            this.fire = true;
            condition.signal();
        } finally {
            lock.unlock();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        WaitThread waitThread = new WaitThread();
        waitThread.start();
        Thread.sleep(1000);
        System.out.println("fire");
        waitThread.fire();
    }
}

當主線程調用fire方法時，子線程才被喚醒繼續執行。

感謝各位的閱讀，以上就是“JDK并發包中的ReentrantLock函數有什么作用”的內容了，經過本文的學習后，相信大家對JDK并發包中的ReentrantLock函數有什么作用這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！