您好,登錄后才能下訂單哦!
這篇文章主要介紹“State實現鎖的原理”,在日常操作中,相信很多人在State實現鎖的原理問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”State實現鎖的原理”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
今天我們就來聊一聊基于AQS實現的各種鎖。
我們先來看一下UML類圖:
從圖中可以看到,ReentrantLock使用抽象內部類Sync來實現了AQS的方法,然后基于Sync這個同步器實現了公平鎖和非公平鎖。主要實現了下面3個方法:
tryAcquire(int arg):獲取獨占鎖
tryRelease(int arg):釋放獨占鎖
isHeldExclusively:當前線程是否占有獨占鎖
ReentrantLock默認實現的是非公平鎖,可以在構造函數指定。
從實現的方法可以看到,ReentrantLock中獲取的鎖是獨占鎖,我們再來看一下獲取和釋放獨占鎖的代碼:
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }
獨占鎖的特點是調用上面acquire方法,傳入的參數是1。
獲取鎖首先判斷同步狀態(state)的值。
1.1.1 state等于0
這說明沒有線程占用鎖,當前線程如果符合下面兩個條件,就可以獲取到鎖:
沒有前任節點,如下圖:
CAS的方式更新state值(把0更新成1)成功。
如果獲取獨占鎖成功,會更新AQS中exclusiveOwnerThread為當前線程,這個很容易理解。
1.1.2 state不等于0
這說明已經有線程占有鎖,判斷占有鎖的線程是不是當前線程,如下圖:
state += 1值如果小于0,會拋出異常。
如果獲取鎖失敗,則進入AQS隊列等待喚醒。
跟公平鎖相比,非公平鎖的唯一不同是如果判斷到state等于0,不用判斷有沒有前任節點,只要CAS設置state值(把0更新成1)成功,就獲取到了鎖。
公平鎖和非公平鎖,釋放邏輯完全一樣,都是在內部類Sync中實現的。釋放鎖需要注意兩點,如下圖:
為什么state會大于1,因為是可以重入的,占有鎖的線程可以多次獲取鎖。
公平鎖的特點是每個線程都要進行排隊,不用擔心線程永遠獲取不到鎖,但有個缺點是每個線程入隊后都需要阻塞和被喚醒,這一定程度上影響了效率。非公平鎖的特點是每個線程入隊前都會先嘗試獲取鎖,如果獲取成功就不會入隊了,這比公平鎖效率高。但也有一個缺點,隊列中的線程有可能等待很長時間,高并發下甚至可能永遠獲取不到鎖。
我們先來看一下UML類圖:
從圖中可以看到,ReentrantReadWriteLock使用抽象內部類Sync來實現了AQS的方法,然后基于Sync這個同步器實現了公平鎖和非公平鎖。主要實現了下面3個方法:
tryAcquire(int arg):獲取獨占鎖
tryRelease(int arg):釋放獨占鎖
tryAcquireShared(int arg):獲取共享鎖
tryReleaseShared(int arg):釋放共享鎖
isHeldExclusively:當前線程是否占有獨占鎖
可見ReentrantReadWriteLock里面同時用到了共享鎖和獨占鎖。
下圖是定義的幾個常用變量:
下面這2個方法用戶獲取共享鎖和獨占鎖的數量:
static int sharedCount(int c) { return c >>> SHARED_SHIFT; } static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
從sharedCount可以看到,共享鎖的數量要右移16位獲取,也就是說共享鎖占了高16位。從上圖EXCLUSIVE_MASK的定義看到,跟EXCLUSIVE_MASK進行與運算,得到的是低16位的值,所以獨占鎖占了低16位。如下圖:
這樣上面獲取鎖數量的方法就很好理解了。參考1[1]
讀鎖的實現對應內部類ReadLock。
2.1.1 獲取讀鎖
獲取讀鎖實際上是ReadLock調用了AQS的下面方法,傳入參數是1:
public final void acquireShared(int arg) { if (tryAcquireShared(arg) < 0) doAcquireShared(arg); }
ReentrantReadWriteLock內部類Sync實現了tryAcquireShared方法,主要包括如下三種情況:
鴻蒙官方戰略合作共建——HarmonyOS技術社區
使用exclusiveCount方法查看state中是否有獨占鎖,如果有并且獨占線程不是當前線程,返回-1,獲取失敗。
使用sharedCount查看state中共享鎖數量,如果讀鎖數量小于最大值(MAX_COUNT=65535),則再滿足下面3個條件就可以獲取成功并返回1:
當前線程不需要阻塞(readerShouldBlock)。在公平鎖中,需要判斷是否有前置節點,如下圖就需要阻塞:
在非公平鎖中,則是判斷第一個節點是不是有獨占鎖,如下圖就需要阻塞:
使用CAS把state的值加SHARED_UNIT(65536)。
這里是不是就更理解讀鎖占高位的說法了,獲取一個讀鎖,state的值就要加SHARED_UNIT這么多個。
給當前線程的holdCount加1。
如果2失敗,自旋,重復上面的步驟直到獲取到鎖。
tryAcquireShared(獲取共享鎖)會返回一個整數,如下:
返回負數:獲取鎖失敗。
返回0:獲取鎖成功但是之后再由線程來獲取共享鎖時就會失敗。
返回正數:獲取鎖成功而且之后再有線程來獲取共享鎖時也可能會成功。
2.1.2 釋放讀鎖
ReentrantReadWriteLock釋放讀鎖是在ReadLock中調用了AQS下面方法,傳入的參數是1:
public final boolean releaseShared(int arg) { if (tryReleaseShared(arg)) { doReleaseShared(); return true; } return false; }
ReentrantReadWriteLock內部類Sync實現了releaseShared方法,具體邏輯分為下面兩步:
當前線程holdCounter值減1。
CAS的方式將state的值減去SHARED_UNIT。
寫鎖的實現對應內部類WriteLock。
2.2.1 獲取寫鎖
ReentrantReadWriteLock獲取寫鎖其實是在WriteLock中調用了AQS的下面方法,傳入參數1:
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }
在ReentrantReadWriteLock內部類Sync實現了tryAcquire方法,首先獲取state值和獨占鎖數量(exclusiveCount),之后分如下兩種情況,如下圖:
state不等于0:
獨占鎖數量等于0,這時說明有線程占用了共享鎖,如果當前線程不是獨占線程,獲取鎖失敗。
獨占鎖數量不等于0,獨占鎖數量加1后大于MAX_COUNT,獲取鎖失敗。
上面2種情況不符合,獲取鎖成功,state值加1。
state等于0,判斷當前線程是否需要阻塞(writerShouldBlock)。
在公平鎖中,跟readerShouldBlock的邏輯完全一樣,就是判斷隊列中head節點的后繼節點是不是當前線程。在非公平鎖中,直接返回false,即可以直接嘗試獲取鎖。
如果當前線程不需要阻塞,并且給state賦值成功,使用CAS方式把state值加1,把獨占線程置為當前線程。
2.2.2 釋放寫鎖
ReentrantReadWriteLock釋放寫鎖其實是在WriteLock中調用了AQS的下面方法,傳入參數1:
public final boolean release(int arg) { if (tryRelease(arg)) { Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false; }
ReentrantReadWriteLock在Sync中實現了tryRelease(arg)方法,邏輯如下:
判斷當前線程是不是獨占線程,如果不是,拋出異常。
state值減1后,用新state值判斷獨占鎖數量是否等于0
如果等于0,則把獨占線程置為空,返回true,這樣上面的代碼就可以喚醒隊列中的后置節點了
如果不等于0,返回false,不喚醒后繼節點。
我們先來看一下UML類圖:
從上面的圖中看出,CountDownLatch的內部類Sync實現了獲取共享鎖和釋放共享鎖的邏輯。
使用CountDownLatch時,構造函數會傳入一個int類型的參數count,表示調動count次的countDown后主線程才可以被喚醒。
public CountDownLatch(int count) { if (count < 0) throw new IllegalArgumentException("count < 0"); this.sync = new Sync(count); }
上面的Sync(count)就是將AQS中的state賦值為count。
CountDownLatch的await方法調用了AQS中的acquireSharedInterruptibly(int arg),傳入參數1,不過這個參數并沒有用。代碼如下:
public final void acquireSharedInterruptibly(int arg) throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); if (tryAcquireShared(arg) < 0) doAcquireSharedInterruptibly(arg); }
Sync中實現了tryAcquireShared方法,await邏輯如下圖:
上面的自旋過程就是等待state的值不斷減小,只有state值成為0的時候,主線程才會跳出自旋執行之后的邏輯。
CountDownLatch的countDown方法調用了AQS的releaseShared(int arg),傳入參數1,不過這個參數并沒有用。內部類Sync實現了tryReleaseShared方法,邏輯如下圖:
CountDownLatch的構造函數入參值會賦值給state變量,入隊操作是主線程入隊,每個子線程調用了countDown后state值減1,當state值成為0后喚醒主線程。
Semaphore是一個信號量,用來保護共享資源。如果線程要訪問共享資源,首先從Semaphore獲取鎖(信號量),如果信號量的計數器等于0,則當前線程進入AQS隊列阻塞等待。否則,線程獲取鎖成功,信號量減1。使用完共享資源后,釋放鎖(信號量加1)。
Semaphore跟管程模型不一樣的是,允許多個(構造函數的permits)線程進入管程內部,因此也常用它來做限流。
UML類圖如下:
Semaphore的構造函數會傳入一個int類型參數,用來初始化state的值。
獲取鎖的操作調用了AQS中的acquireSharedInterruptibly方法,傳入參數1,代碼見CountDownLatch中await小節。Semaphore在公平鎖和非公平鎖中分別實現了tryAcquireShared方法。
4.1.1 公平鎖
Semaphore默認使用非公平鎖,如果使用公平鎖,需要在構造函數指定。獲取公平鎖邏輯比較簡單,如下圖:
4.1.2 非公平鎖
acquire在非公平的鎖唯一的區別就是不會判斷AQS隊列是否有前置節點(hasQueuedPredecessors),而是直接嘗試獲取鎖。
除了acquire方法外,還有其他幾個獲取鎖的方法,原理類似,只是調用了AQS中的不同方法。
釋放鎖的操作調用了AQS中的releaseShared(int arg)方法,傳入參數1,在內部類Sync中實現了tryReleaseShared方法,邏輯很簡單:使用CAS的方式將state的值加1,之后喚醒隊列中的后繼節點。
ThreadPoolExecutor中也用到了AQS,看下面的UML類圖:
Worker主要在ThreadPoolExecutor中斷線程的時候使用。Worker自己實現了獨占鎖,在中斷線程時首先進行加鎖,中斷操作后釋放鎖。按照官方說法,這里不直接使用ReentrantLock的原因是防止調用控制線程池的方法(類似setCorePoolSize)時能夠重新獲取到鎖,
使用CAS的方式把AQS中state從0改為1,把當前線程置為獨占線程。
把獨占線程置為空,把AQS中state改為0。
Worker初始化的時候會把state置為-1,這樣是不能獲取鎖成功的。只有調用了runWorker方法,才會通過釋放鎖操作把state更為0。這樣保證了只中斷運行中的線程,而不會中斷等待中的線程。
到此,關于“State實現鎖的原理”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。