您好,登錄后才能下訂單哦!
這篇文章主要講解了“JDK并發(fā)包中的ReentrantLock函數(shù)有什么作用”,文中的講解內(nèi)容簡單清晰,易于學(xué)習(xí)與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“JDK并發(fā)包中的ReentrantLock函數(shù)有什么作用”吧!
JDK針對Lock的主要實現(xiàn)是ReentrantLock,ReadWriteLock實現(xiàn)是ReentrantReadWriteLock。
兩把鎖共享一個等待隊列,兩把鎖的狀態(tài)都由一個原子變量表示,特有的獲取鎖和釋放鎖邏輯。
讀鎖的獲取,只要求寫鎖沒有被線程持有就可以獲取,檢查等待隊列,逐個喚醒等待讀鎖線程,遇到等待寫鎖線程則停止.
讀鎖的釋放,釋放后,檢查寫鎖和讀鎖是否被持有,若都沒有被持有則喚醒下一個等待線程.
寫鎖的獲取,只有讀寫鎖都未被持有才會獲取寫鎖。
寫鎖的釋放,喚醒等待隊列的下一個線程。
void lock();獲取鎖,阻塞,不響應(yīng)中斷,但會記錄中斷標(biāo)志位。
void lockInterruptibly() throws InterruptedException;獲取鎖,響應(yīng)中斷
boolean tryLock();獲取鎖,不阻塞,實時返回,一般需循環(huán)調(diào)用
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;在time的時間內(nèi)阻塞獲取鎖,響應(yīng)中斷
void unlock();釋放鎖
Condition newCondition();新建顯式條件
注: 這里的響應(yīng)中斷意思是若被其他線程中斷(調(diào)用interrupt方法)會拋出InterruptedException異常。
依賴CAS方法,可重入實現(xiàn)用的計數(shù)就是用的原子變量。
依賴LockSupport中的方法:
public static void park():放棄CPU執(zhí)行權(quán),CPU不在進行調(diào)度,響應(yīng)中斷,當(dāng)有中斷發(fā)生時,park會返回,線程中斷狀態(tài)會被設(shè)置,另外park也有可能無緣無故的返回,所以一般需要循環(huán)檢查park的等待條件是否滿足。。
public static void parkNanos(long nanos):在nanos納秒內(nèi)放棄CPU執(zhí)行權(quán)
public static void parkUntil(long deadline):放棄執(zhí)行權(quán)直到deadline時間(距離1970年毫秒數(shù))。
public static void unpark(Thread thread):重新恢復(fù)線程,讓其爭奪CPU執(zhí)行權(quán)。
AQS-AbstractQueuedSynchronizer(抽象隊列同步器)。
ReadWriteLock在內(nèi)部注入了AbstractQueuedSynchronizer,上鎖和釋放鎖核心方法都在AQS類當(dāng)中,AQS維護了兩個核心變量,一個是state(當(dāng)前可重入計數(shù),初始值為0),一個是exclusiveOwnerThread(當(dāng)前持有鎖的線程Thread對象)。另外還維護了一個鎖等待隊列。
ReentrantLock構(gòu)造方法傳入的boolean值ture為公平鎖,false為不公平鎖。以不公平鎖為例先講一下上鎖和釋放鎖的原理:
如果當(dāng)前鎖狀態(tài)為0(未被鎖),則使用CAS獲得鎖,并設(shè)置當(dāng)前鎖內(nèi)的線程為自己。
如果不為0,且持有鎖的線程不是自己,則添加到隊列尾部,并調(diào)用LockSupport中的park()方法放棄CPU執(zhí)行權(quán)。直到當(dāng)鎖被釋放的時候被喚醒,被喚醒后檢查自己是否是第一個等待的線程,如果是且能獲得鎖,則返回,否則繼續(xù)等待,這個過程中如果發(fā)生了中斷,lock會記錄中斷標(biāo)志位,但不會提前返回或拋出異常。
如果不為0,但持有鎖線程是自己,則直接將state加1。
就是將AQS內(nèi)的state變量的值遞減1,如果state值為0,則徹底釋放鎖,會將“加鎖線程”變量也設(shè)置為null,同時喚醒等待隊列中的第一個線程。
為什么說上面的是不公平鎖,釋放鎖時不是喚醒隊列中第一個線程嗎?為什么還會出現(xiàn)不公平的情況了,原因在于如果剛好釋放鎖,此時有一個線程進來嘗試獲取鎖,可能會存在插隊的情況。
構(gòu)造方法bollean傳入true則代表的是公平鎖,在獲取鎖方法中多了一個檢查,意義是只有不存在其他等待時間更長的線程,它才會嘗試獲取鎖。對比不公平鎖,其整體性能比較低,低的原因不是這個檢查慢,而是會讓活躍線程得不到鎖,進入等待狀態(tài),引起上下文切換,降低了整體的效率,
tryLock可避免死鎖造成的無限等待
擁有獲取鎖信息方法的各種API
可以響應(yīng)中斷
可以限時
建議: synchronized以前的效率不如顯式鎖,但現(xiàn)在的版本兩者效率上幾乎沒有區(qū)別,所以建議能用synchronized就用synchronized,需要實現(xiàn)synchronized辦不到的需求如以上區(qū)別時,再考慮ReentrantLock。
與wait和notify對應(yīng),用于線程協(xié)作,通過Lock的Condition newCondition()方法創(chuàng)建對應(yīng)顯示鎖的顯示條件;
主要方法是await()和signal(),await()對應(yīng)于Object的wait(),signal()對應(yīng)于notify,signalAll()對應(yīng)于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(); } }
當(dāng)主線程調(diào)用fire方法時,子線程才被喚醒繼續(xù)執(zhí)行。
感謝各位的閱讀,以上就是“JDK并發(fā)包中的ReentrantLock函數(shù)有什么作用”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對JDK并發(fā)包中的ReentrantLock函數(shù)有什么作用這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關(guān)知識點的文章,歡迎關(guān)注!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。