資訊專欄INFORMATION COLUMN
摘要：所以大家看下面的圖，就是線程跑過(guò)來(lái)加鎖的一個(gè)過(guò)程。好線程現(xiàn)在就重新嘗試加鎖，這時(shí)還是用操作將從變?yōu)?，此時(shí)就會(huì)成功，成功之后代表加鎖成功，就會(huì)將設(shè)置為。此外，還要把加鎖線程設(shè)置為線程自己，同時(shí)線程自己就從等待隊(duì)列中出隊(duì)了。
ReentrantLock和AQS的關(guān)系 ReentrantLock使用
AbstractQueuedSynchronizer，抽象隊(duì)列同步器；給大家畫一個(gè)圖先，看一下ReentrantLock和AQS之間的關(guān)系。
AbstractQueuedSynchronizer為ReentrantLock的靜態(tài)內(nèi)部類
2、默認(rèn)為非公平鎖
3、最終會(huì)調(diào)用AbstractQueuedSynchronizer子類NonfairSync.lock()方法；
lock（）方法做了什么事呢？
首先需要知道AQS會(huì)維護(hù)兩個(gè)變量state（初始值0）、exclusiveOwnerThread（初始值null），源碼如下，記錄線程狀態(tài)與當(dāng)前加鎖線程
線程1跑過(guò)來(lái)調(diào)用ReentrantLock的lock()方法嘗試進(jìn)行加鎖，這個(gè)加鎖的過(guò)程，直接就是用CAS操作將state值從0變?yōu)?。
如果之前沒人加過(guò)鎖，那么state的值肯定是0，此時(shí)線程1就可以加鎖成功。
一旦線程1加鎖成功了之后，就可以設(shè)置當(dāng)前加鎖線程是自己。所以大家看下面的圖，就是線程1跑過(guò)來(lái)加鎖的一個(gè)過(guò)程。
state記錄加鎖次數(shù)，為0時(shí)釋放鎖
鎖的互斥是如何實(shí)現(xiàn)的？線程2跑過(guò)來(lái)一下看到，哎呀！state的值不是0?。克訡AS操作將state從0變?yōu)?的過(guò)程會(huì)失敗，因?yàn)閟tate的值當(dāng)前為1，說(shuō)明已經(jīng)有人加鎖了！
接著線程2會(huì)看一下，是不是自己之前加的鎖?。慨?dāng)然不是了，“加鎖線程”這個(gè)變量明確記錄了是線程1占用了這個(gè)鎖，所以線程2此時(shí)就是加鎖失敗。
接著，線程2會(huì)將自己放入AQS中的一個(gè)等待隊(duì)列，因?yàn)樽约簢L試加鎖失敗了，此時(shí)就要將自己放入隊(duì)列中來(lái)等待，等待線程1釋放鎖之后，自己就可以重新嘗試加鎖了
所以大家可以看到，AQS是如此的核心！AQS內(nèi)部還有一個(gè)等待隊(duì)列，專門放那些加鎖失敗的線程！
同樣，給大家來(lái)一張圖，一起感受一下：
源碼
線程2進(jìn)來(lái)加鎖失敗后，會(huì)進(jìn)入等待隊(duì)列；等待隊(duì)列為鏈表
接著，線程1在執(zhí)行完自己的業(yè)務(wù)邏輯代碼之后，就會(huì)釋放鎖！他釋放鎖的過(guò)程非常的簡(jiǎn)單，就是將AQS內(nèi)的state變量的值遞減1，如果state值為0，則徹底釋放鎖，會(huì)將“加鎖線程”變量也設(shè)置為null！
整個(gè)過(guò)程，參見下圖：
LockSupport.unpark(s.thread);
接下來(lái)，會(huì)從等待隊(duì)列的隊(duì)頭喚醒線程2重新嘗試加鎖。
好！線程2現(xiàn)在就重新嘗試加鎖，這時(shí)還是用CAS操作將state從0變?yōu)?，此時(shí)就會(huì)成功，成功之后代表加鎖成功，就會(huì)將state設(shè)置為1。
此外，還要把“加鎖線程”設(shè)置為線程2自己，同時(shí)線程2自己就從等待隊(duì)列中出隊(duì)了。
最后再來(lái)一張圖，大家來(lái)看看這個(gè)過(guò)程。
參考資料https://juejin.im/post/5c07e5...
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/72655.html
摘要：概述前面已經(jīng)講解了關(guān)于的非公平鎖模式，關(guān)于非公平鎖，內(nèi)部其實(shí)告訴我們誰(shuí)先爭(zhēng)搶到鎖誰(shuí)就先獲得資源，下面就來(lái)分析一下公平鎖內(nèi)部是如何實(shí)現(xiàn)公平的如果沒有看過(guò)非公平鎖的先去了解下非公平鎖，因?yàn)檫@篇文章前面不會(huì)講太多內(nèi)部結(jié)構(gòu)，直接會(huì)對(duì)源碼進(jìn)行分析前文 概述 前面已經(jīng)講解了關(guān)于AQS的非公平鎖模式，關(guān)于NonfairSync非公平鎖，內(nèi)部其實(shí)告訴我們誰(shuí)先爭(zhēng)搶到鎖誰(shuí)就先獲得資源，下面就來(lái)分析一下公平...
摘要：內(nèi)部提供了兩種的實(shí)現(xiàn)，一種公平模式，一種是非公平模式，如果沒有特別指定在構(gòu)造器中，默認(rèn)是非公平的模式，我們可以看一下無(wú)參的構(gòu)造函數(shù)。 概述 并發(fā)編程中，ReentrantLock的使用是比較多的，包括之前講的LinkedBlockingQueue和ArrayBlockQueue的內(nèi)部都是使用的ReentrantLock，談到它又不能的不說(shuō)AQS，AQS的全稱是AbstractQueue...
摘要：的主要功能和關(guān)鍵字一致，均是用于多線程的同步。而僅支持通過(guò)查詢當(dāng)前線程是否持有鎖。由于和使用的是同一把可重入鎖，所以線程可以進(jìn)入方法，并再次獲得鎖，而不會(huì)被阻塞住。公平與非公平公平與非公平指的是線程獲取鎖的方式。 1.簡(jiǎn)介 可重入鎖ReentrantLock自 JDK 1.5 被引入，功能上與synchronized關(guān)鍵字類似。所謂的可重入是指，線程可對(duì)同一把鎖進(jìn)行重復(fù)加鎖，而不會(huì)被阻...
摘要：公平策略在多個(gè)線程爭(zhēng)用鎖的情況下，公平策略傾向于將訪問(wèn)權(quán)授予等待時(shí)間最長(zhǎng)的線程。使用方式的典型調(diào)用方式如下二類原理的源碼非常簡(jiǎn)單，它通過(guò)內(nèi)部類實(shí)現(xiàn)了框架，接口的實(shí)現(xiàn)僅僅是對(duì)的的簡(jiǎn)單封裝，參見原理多線程進(jìn)階七鎖框架獨(dú)占功能剖析 showImg(https://segmentfault.com/img/remote/1460000016012582); 本文首發(fā)于一世流云的專欄：https...
摘要：作者畢來(lái)生微信鎖狀態(tài)轉(zhuǎn)換分類以后幫助我們提供了線程同步機(jī)制，通過(guò)顯示定義同步鎖來(lái)實(shí)現(xiàn)對(duì)象之間的同步。等待重新嘗試因?yàn)樵谥惺怯藐P(guān)鍵字聲明的，故可以在線程間可見再次判斷一下能否持有鎖可能線程同步代碼執(zhí)行得比較快，已經(jīng)釋放了鎖，不可以就返回。 作者 : 畢來(lái)生微信: 878799579 鎖狀態(tài)轉(zhuǎn)換 showImg(https://segmentfault.com/img/remote/...
閱讀 3548·2021-09-22 15:50
閱讀 3245·2019-08-30 15:54
閱讀 2757·2019-08-30 14:12
閱讀 3067·2019-08-30 11:22
閱讀 2089·2019-08-29 11:16
閱讀 3585·2019-08-26 13:43
閱讀 1198·2019-08-23 18:33
閱讀 930·2019-08-23 18:32
