摘要:更新成功返回,否則返回這個操作是原子的,不會出現線程安全問題,這里面涉及到這個類的操作,一級涉及到這個屬性的意義。
簡單解釋一下J.U.C,是JDK中提供的并發工具包,java.util.concurrent。里面提供了很多并發編程中很常用的實用工具類,比如atomic原子操作、比如lock同步鎖、fork/join等。從Lock作為切入點
我想以lock作為切入點來講解AQS,畢竟同步鎖是解決線程安全問題的通用手段,也是我們工作中用得比較多的方式。
Lock APILock是一個接口,方法定義如下
void lock() // 如果鎖可用就獲得鎖,如果鎖不可用就阻塞直到鎖釋放 void lockInterruptibly() // 和 lock()方法相似, 但阻塞的線程可中斷,拋出 java.lang.InterruptedException異常 boolean tryLock() // 非阻塞獲取鎖;嘗試獲取鎖,如果成功返回true boolean tryLock(long timeout, TimeUnit timeUnit) //帶有超時時間的獲取鎖方法 void unlock() // 釋放鎖Lock的實現
實現Lock接口的類有很多,以下為幾個常見的鎖實現
ReentrantLock:表示重入鎖,它是唯一一個實現了Lock接口的類。重入鎖指的是線程在獲得鎖之后,再次獲取該鎖不需要阻塞,而是直接關聯一次計數器增加重入次數
ReentrantReadWriteLock:重入讀寫鎖,它實現了ReadWriteLock接口,在這個類中維護了兩個鎖,一個是ReadLock,一個是WriteLock,他們都分別實現了Lock接口。讀寫鎖是一種適合讀多寫少的場景下解決線程安全問題的工具,基本原則是:讀和讀不互斥、讀和寫互斥、寫和寫互斥。也就是說涉及到影響數據變化的操作都會存在互斥。
StampedLock: stampedLock是JDK8引入的新的鎖機制,可以簡單認為是讀寫鎖的一個改進版本,讀寫鎖雖然通過分離讀和寫的功能使得讀和讀之間可以完全并發,但是讀和寫是有沖突的,如果大量的讀線程存在,可能會引起寫線程的饑餓。stampedLock是一種樂觀的讀策略,使得樂觀鎖完全不會阻塞寫線程
ReentrantLock的簡單實用如何在實際應用中使用ReentrantLock呢?我們通過一個簡單的demo來演示一下
public class Demo { private static int count=0; static Lock lock=new ReentrantLock(); public static void inc(){ lock.lock(); try { Thread.sleep(1); count++; } catch (InterruptedException e) { e.printStackTrace(); }finally{ lock.unlock(); } }
這段代碼主要做一件事,就是通過一個靜態的incr()方法對共享變量count做連續遞增,在沒有加同步鎖的情況下多線程訪問這個方法一定會存在線程安全問題。所以用到了ReentrantLock來實現同步鎖,并且在finally語句塊中釋放鎖。
那么我來引出一個問題,大家思考一下
多個線程通過lock競爭鎖時,當競爭失敗的鎖是如何實現等待以及被喚醒的呢?什么是AQS
aqs全稱為AbstractQueuedSynchronizer,它提供了一個FIFO隊列,可以看成是一個用來實現同步鎖以及其他涉及到同步功能的核心組件,常見的有:ReentrantLock、CountDownLatch等。
AQS是一個抽象類,主要是通過繼承的方式來使用,它本身沒有實現任何的同步接口,僅僅是定義了同步狀態的獲取以及釋放的方法來提供自定義的同步組件。
可以這么說,只要搞懂了AQS,那么J.U.C中絕大部分的api都能輕松掌握。
從使用層面來說,AQS的功能分為兩種:獨占和共享
獨占鎖,每次只能有一個線程持有鎖,比如前面給大家演示的ReentrantLock就是以獨占方式實現的互斥鎖
共享鎖,允許多個線程同時獲取鎖,并發訪問共享資源,比如ReentrantReadWriteLock
ReentrantLock的類圖仍然以ReentrantLock為例,來分析AQS在重入鎖中的使用。畢竟單純分析AQS沒有太多的含義。先理解這個類圖,可以方便我們理解AQS的原理
AQS的實現依賴內部的同步隊列,也就是FIFO的雙向隊列,如果當前線程競爭鎖失敗,那么AQS會把當前線程以及等待狀態信息構造成一個Node加入到同步隊列中,同時再阻塞該線程。當獲取鎖的線程釋放鎖以后,會從隊列中喚醒一個阻塞的節點(線程)。
AQS隊列內部維護的是一個FIFO的雙向鏈表,這種結構的特點是每個數據結構都有兩個指針,分別指向直接的后繼節點和直接前驅節點。所以雙向鏈表可以從任意一個節點開始很方便的訪問前驅和后繼。每個Node其實是由線程封裝,當線程爭搶鎖失敗后會封裝成Node加入到ASQ隊列中去
Node類的組成如下
static final class Node { static final Node SHARED = new Node(); static final Node EXCLUSIVE = null; static final int CANCELLED = 1; static final int SIGNAL = -1; static final int CONDITION = -2; static final int PROPAGATE = -3; volatile int waitStatus; volatile Node prev; //前驅節點 volatile Node next; //后繼節點 volatile Thread thread;//當前線程 Node nextWaiter; //存儲在condition隊列中的后繼節點 //是否為共享鎖 final boolean isShared() { return nextWaiter == SHARED; } final Node predecessor() throws NullPointerException { Node p = prev; if (p == null) throw new NullPointerException(); else return p; } Node() { // Used to establish initial head or SHARED marker } //將線程構造成一個Node,添加到等待隊列 Node(Thread thread, Node mode) { // Used by addWaiter this.nextWaiter = mode; this.thread = thread; } //這個方法會在Condition隊列使用,后續多帶帶寫一篇文章分析condition Node(Thread thread, int waitStatus) { // Used by Condition this.waitStatus = waitStatus; this.thread = thread; } }釋放鎖以及添加線程對于隊列的變化 添加節點
當出現鎖競爭以及釋放鎖的時候,AQS同步隊列中的節點會發生變化,首先看一下添加節點的場景。
這里會涉及到兩個變化
新的線程封裝成Node節點追加到同步隊列中,設置prev節點以及修改當前節點的前置節點的next節點指向自己
通過CAS講tail重新指向新的尾部節點
釋放鎖移除節點head節點表示獲取鎖成功的節點,當頭結點在釋放同步狀態時,會喚醒后繼節點,如果后繼節點獲得鎖成功,會把自己設置為頭結點,節點的變化過程如下
這個過程也是涉及到兩個變化
修改head節點指向下一個獲得鎖的節點
新的獲得鎖的節點,將prev的指針指向null
這里有一個小的變化,就是設置head節點不需要用CAS,原因是設置head節點是由獲得鎖的線程來完成的,而同步鎖只能由一個線程獲得,所以不需要CAS保證,只需要把head節點設置為原首節點的后繼節點,并且斷開原head節點的next引用即可
AQS的源碼分析清楚了AQS的基本架構以后,我們來分析一下AQS的源碼,仍然以ReentrantLock為模型。
ReentrantLock的時序圖調用ReentrantLock中的lock()方法,源碼的調用過程我使用了時序圖來展現
從圖上可以看出來,當鎖獲取失敗時,會調用addWaiter()方法將當前線程封裝成Node節點加入到AQS隊列,基于這個思路,我們來分析AQS的源碼實現
public void lock() { sync.lock(); }
這個是獲取鎖的入口,調用sync這個類里面的方法,sync是什么呢?
abstract static class Sync extends AbstractQueuedSynchronizer
sync是一個靜態內部類,它繼承了AQS這個抽象類,前面說過AQS是一個同步工具,主要用來實現同步控制。我們在利用這個工具的時候,會繼承它來實現同步控制功能。
通過進一步分析,發現Sync這個類有兩個具體的實現,分別是NofairSync(非公平鎖),FailSync(公平鎖).
公平鎖 表示所有線程嚴格按照FIFO來獲取鎖
非公平鎖 表示可以存在搶占鎖的功能,也就是說不管當前隊列上是否存在其他線程等待,新線程都有機會搶占鎖
公平鎖和非公平鎖的實現上的差異,我會在文章后面做一個解釋,接下來的分析仍然以非公平鎖作為主要分析邏輯。
NonfairSync.lockfinal void lock() { if (compareAndSetState(0, 1)) //通過cas操作來修改state狀態,表示爭搶鎖的操作 setExclusiveOwnerThread(Thread.currentThread());//設置當前獲得鎖狀態的線程 else acquire(1); //嘗試去獲取鎖 }
這段代碼簡單解釋一下
由于這里是非公平鎖,所以調用lock方法時,先去通過cas去搶占鎖
如果搶占鎖成功,保存獲得鎖成功的當前線程
搶占鎖失敗,調用acquire來走鎖競爭邏輯
compareAndSetState
compareAndSetState的代碼實現邏輯如下
// See below for intrinsics setup to support this return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
這段代碼其實邏輯很簡單,就是通過cas樂觀鎖的方式來做比較并替換。上面這段代碼的意思是,如果當前內存中的state的值和預期值expect相等,則替換為update。更新成功返回true,否則返回false. 這個操作是原子的,不會出現線程安全問題,這里面涉及到Unsafe這個類的操作,一級涉及到state這個屬性的意義。 **state**
當state=0時,表示無鎖狀態
當state>0時,表示已經有線程獲得了鎖,也就是state=1,但是因為ReentrantLock允許重入,所以同一個線程多次獲得同步鎖的時候,state會遞增,比如重入5次,那么state=5。 而在釋放鎖的時候,同樣需要釋放5次直到state=0其他線程才有資格獲得鎖
acquireprivate volatile int state;需要注意的是:不同的AQS實現,state所表達的含義是不一樣的。
Unsafe
Unsafe類是在sun.misc包下,不屬于Java標準。但是很多Java的基礎類庫,包括一些被廣泛使用的高性能開發庫都是基于Unsafe類開發的,比如Netty、Hadoop、Kafka等;Unsafe可認為是Java中留下的后門,提供了一些低層次操作,如直接內存訪問、線程調度等public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);這個是一個native方法, 第一個參數為需要改變的對象,第二個為偏移量(即之前求出來的headOffset的值),第三個參數為期待的值,第四個為更新后的值
整個方法的作用是如果當前時刻的值等于預期值var4相等,則更新為新的期望值 var5,如果更新成功,則返回true,否則返回false;
acquire是AQS中的方法,如果CAS操作未能成功,說明state已經不為0,此時繼續acquire(1)操作,這里大家思考一下,acquire方法中的1的參數是用來做什么呢?如果沒猜中,往前面回顧一下state這個概念
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }
這個方法的主要邏輯是
通過tryAcquire嘗試獲取獨占鎖,如果成功返回true,失敗返回false
如果tryAcquire失敗,則會通過addWaiter方法將當前線程封裝成Node添加到AQS隊列尾部
acquireQueued,將Node作為參數,通過自旋去嘗試獲取鎖。
如果大家看過我寫的Synchronized源碼分析的文章,就應該能夠明白自旋存在的意義NonfairSync.tryAcquire
這個方法的作用是嘗試獲取鎖,如果成功返回true,不成功返回false
它是重寫AQS類中的tryAcquire方法,并且大家仔細看一下AQS中tryAcquire方法的定義,并沒有實現,而是拋出異常。按照一般的思維模式,既然是一個不實現的模版方法,那應該定義成abstract,讓子類來實現呀?大家想想為什么
protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires); }nonfairTryAcquire
tryAcquire(1)在NonfairSync中的實現代碼如下
ffinal boolean nonfairTryAcquire(int acquires) { //獲得當前執行的線程 final Thread current = Thread.currentThread(); int c = getState(); //獲得state的值 if (c == 0) { //state=0說明當前是無鎖狀態 //通過cas操作來替換state的值改為1,大家想想為什么要用cas呢? //理由是,在多線程環境中,直接修改state=1會存在線程安全問題,你猜到了嗎? if (compareAndSetState(0, acquires)) { //保存當前獲得鎖的線程 setExclusiveOwnerThread(current); return true; } } //這段邏輯就很簡單了。如果是同一個線程來獲得鎖,則直接增加重入次數 else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; //增加重入次數 if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; }
獲取當前線程,判斷當前的鎖的狀態
如果state=0表示當前是無鎖狀態,通過cas更新state狀態的值
如果當前線程是屬于重入,則增加重入次數
addWaiter當tryAcquire方法獲取鎖失敗以后,則會先調用addWaiter將當前線程封裝成Node,然后添加到AQS隊列
private Node addWaiter(Node mode) { //mode=Node.EXCLUSIVE //將當前線程封裝成Node,并且mode為獨占鎖 Node node = new Node(Thread.currentThread(), mode); // Try the fast path of enq; backup to full enq on failure // tail是AQS的中表示同步隊列隊尾的屬性,剛開始為null,所以進行enq(node)方法 Node pred = tail; if (pred != null) { //tail不為空的情況,說明隊列中存在節點數據 node.prev = pred; //講當前線程的Node的prev節點指向tail if (compareAndSetTail(pred, node)) {//通過cas講node添加到AQS隊列 pred.next = node;//cas成功,把舊的tail的next指針指向新的tail return node; } } enq(node); //tail=null,將node添加到同步隊列中 return node; }
將當前線程封裝成Node
判斷當前鏈表中的tail節點是否為空,如果不為空,則通過cas操作把當前線程的node添加到AQS隊列
如果為空或者cas失敗,調用enq將節點添加到AQS隊列
enqenq就是通過自旋操作把當前節點加入到隊列中
private Node enq(final Node node) { //自旋,不做過多解釋,不清楚的關注公眾號[架構師修煉寶典] for (;;) { Node t = tail; //如果是第一次添加到隊列,那么tail=null if (t == null) { // Must initialize //CAS的方式創建一個空的Node作為頭結點 if (compareAndSetHead(new Node())) //此時隊列中只一個頭結點,所以tail也指向它 tail = head; } else { //進行第二次循環時,tail不為null,進入else區域。將當前線程的Node結點的prev指向tail,然后使用CAS將tail指向Node node.prev = t; if (compareAndSetTail(t, node)) { //t此時指向tail,所以可以CAS成功,將tail重新指向Node。此時t為更新前的tail的值,即指向空的頭結點,t.next=node,就將頭結點的后續結點指向Node,返回頭結點 t.next = node; return t; } } } }
假如有兩個線程t1,t2同時進入enq方法,t==null表示隊列是首次使用,需要先初始化
另外一個線程cas失敗,則進入下次循環,通過cas操作將node添加到隊尾
到目前為止,通過addwaiter方法構造了一個AQS隊列,并且將線程添加到了隊列的節點中acquireQueued
將添加到隊列中的Node作為參數傳入acquireQueued方法,這里面會做搶占鎖的操作
final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { final Node p = node.predecessor();// 獲取prev節點,若為null即刻拋出NullPointException if (p == head && tryAcquire(arg)) {// 如果前驅為head才有資格進行鎖的搶奪 setHead(node); // 獲取鎖成功后就不需要再進行同步操作了,獲取鎖成功的線程作為新的head節點 //凡是head節點,head.thread與head.prev永遠為null, 但是head.next不為null p.next = null; // help GC failed = false; //獲取鎖成功 return interrupted; } //如果獲取鎖失敗,則根據節點的waitStatus決定是否需要掛起線程 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())// 若前面為true,則執行掛起,待下次喚醒的時候檢測中斷的標志 interrupted = true; } } finally { if (failed) // 如果拋出異常則取消鎖的獲取,進行出隊(sync queue)操作 cancelAcquire(node); } }
獲取當前節點的prev節點
如果prev節點為head節點,那么它就有資格去爭搶鎖,調用tryAcquire搶占鎖
搶占鎖成功以后,把獲得鎖的節點設置為head,并且移除原來的初始化head節點
如果獲得鎖失敗,則根據waitStatus決定是否需要掛起線程
最后,通過cancelAcquire取消獲得鎖的操作
前面的邏輯都很好理解,主要看一下shouldParkAfterFailedAcquire這個方法和parkAndCheckInterrupt的作用
shouldParkAfterFailedAcquire從上面的分析可以看出,只有隊列的第二個節點可以有機會爭用鎖,如果成功獲取鎖,則此節點晉升為頭節點。對于第三個及以后的節點,if (p == head)條件不成立,首先進行shouldParkAfterFailedAcquire(p, node)操作
shouldParkAfterFailedAcquire方法是判斷一個爭用鎖的線程是否應該被阻塞。它首先判斷一個節點的前置節點的狀態是否為Node.SIGNAL,如果是,是說明此節點已經將狀態設置-如果鎖釋放,則應當通知它,所以它可以安全的阻塞了,返回true。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { int ws = pred.waitStatus; //前繼節點的狀態 if (ws == Node.SIGNAL)//如果是SIGNAL狀態,意味著當前線程需要被unpark喚醒 return true; 如果前節點的狀態大于0,即為CANCELLED狀態時,則會從前節點開始逐步循環找到一個沒有被“CANCELLED”節點設置為當前節點的前節點,返回false。在下次循環執行shouldParkAfterFailedAcquire時,返回true。這個操作實際是把隊列中CANCELLED的節點剔除掉。 if (ws > 0) {// 如果前繼節點是“取消”狀態,則設置 “當前節點”的 “當前前繼節點” 為 “‘原前繼節點"的前繼節點”。 do { node.prev = pred = pred.prev; } while (pred.waitStatus > 0); pred.next = node; } else { // 如果前繼節點為“0”或者“共享鎖”狀態,則設置前繼節點為SIGNAL狀態。 /* * waitStatus must be 0 or PROPAGATE. Indicate that we * need a signal, but don"t park yet. Caller will need to * retry to make sure it cannot acquire before parking. */ compareAndSetWaitStatus(pred, ws, Node.SIGNAL); } return false; }parkAndCheckInterrupt
如果shouldParkAfterFailedAcquire返回了true,則會執行:parkAndCheckInterrupt()方法,它是通過LockSupport.park(this)將當前線程掛起到WATING狀態,它需要等待一個中斷、unpark方法來喚醒它,通過這樣一種FIFO的機制的等待,來實現了Lock的操作。
private final boolean parkAndCheckInterrupt() { LockSupport.park(this); return Thread.interrupted(); }
鎖的釋放 ReentrantLock.unlockLockSupport
LockSupport類是Java6引入的一個類,提供了基本的線程同步原語。LockSupport實際上是調用了Unsafe類里的函數,歸結到Unsafe里,只有兩個函數:public native void unpark(Thread jthread); public native void park(boolean isAbsolute, long time);unpark函數為線程提供“許可(permit)”,線程調用park函數則等待“許可”。這個有點像信號量,但是這個“許可”是不能疊加的,“許可”是一次性的。
permit相當于0/1的開關,默認是0,調用一次unpark就加1變成了1.調用一次park會消費permit,又會變成0。 如果再調用一次park會阻塞,因為permit已經是0了。直到permit變成1.這時調用unpark會把permit設置為1.每個線程都有一個相關的permit,permit最多只有一個,重復調用unpark不會累積
加鎖的過程分析完以后,再來分析一下釋放鎖的過程,調用release方法,這個方法里面做兩件事,1,釋放鎖 ;2,喚醒park的線程
public final boolean release(int arg) { if (tryRelease(arg)) { Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false; }tryRelease
這個動作可以認為就是一個設置鎖狀態的操作,而且是將狀態減掉傳入的參數值(參數是1),如果結果狀態為0,就將排它鎖的Owner設置為null,以使得其它的線程有機會進行執行。
在排它鎖中,加鎖的時候狀態會增加1(當然可以自己修改這個值),在解鎖的時候減掉1,同一個鎖,在可以重入后,可能會被疊加為2、3、4這些值,只有unlock()的次數與lock()的次數對應才會將Owner線程設置為空,而且也只有這種情況下才會返回true。
protected final boolean tryRelease(int releases) { int c = getState() - releases; // 這里是將鎖的數量減1 if (Thread.currentThread() != getExclusiveOwnerThread())// 如果釋放的線程和獲取鎖的線程不是同一個,拋出非法監視器狀態異常 throw new IllegalMonitorStateException(); boolean free = false; if (c == 0) { // 由于重入的關系,不是每次釋放鎖c都等于0, // 直到最后一次釋放鎖時,才會把當前線程釋放 free = true; setExclusiveOwnerThread(null); } setState(c); return free; }unparkSuccessor
在方法unparkSuccessor(Node)中,就意味著真正要釋放鎖了,它傳入的是head節點(head節點是占用鎖的節點),當前線程被釋放之后,需要喚醒下一個節點的線程
private void unparkSuccessor(Node node) { int ws = node.waitStatus; if (ws < 0) compareAndSetWaitStatus(node, ws, 0); Node s = node.next; if (s == null || s.waitStatus > 0) {//判斷后繼節點是否為空或者是否是取消狀態, s = null; for (Node t = tail; t != null && t != node; t = t.prev) if (t.waitStatus <= 0) //然后從隊列尾部向前遍歷找到最前面的一個waitStatus小于0的節點, 至于為什么從尾部開始向前遍歷,因為在doAcquireInterruptibly.cancelAcquire方法的處理過程中只設置了next的變化,沒有設置prev的變化,在最后有這樣一行代碼:node.next = node,如果這時執行了unparkSuccessor方法,并且向后遍歷的話,就成了死循環了,所以這時只有prev是穩定的 s = t; } //內部首先會發生的動作是獲取head節點的next節點,如果獲取到的節點不為空,則直接通過:“LockSupport.unpark()”方法來釋放對應的被掛起的線程,這樣一來將會有一個節點喚醒后繼續進入循環進一步嘗試tryAcquire()方法來獲取鎖 if (s != null) LockSupport.unpark(s.thread); //釋放許可 }總結
通過這篇文章基本將AQS隊列的實現過程做了比較清晰的分析,主要是基于非公平鎖的獨占鎖實現。在獲得同步鎖時,同步器維護一個同步隊列,獲取狀態失敗的線程都會被加入到隊列中并在隊列中進行自旋;移出隊列(或停止自旋)的條件是前驅節點為頭節點且成功獲取了同步狀態。在釋放同步狀態時,同步器調用tryRelease(int arg)方法釋放同步狀態,然后喚醒頭節點的后繼節點。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/72692.html
摘要:在創建對象時,需要轉入一個值,用于初始化的成員變量,該成員變量表示屏障攔截的線程數。當到達屏障的線程數小于時,這些線程都會被阻塞住。當所有線程到達屏障后,將會被更新,表示進入新一輪的運行輪次中。 1.簡介 在分析完AbstractQueuedSynchronizer(以下簡稱 AQS)和ReentrantLock的原理后,本文將分析 java.util.concurrent 包下的兩個...
摘要:其二如果返回值等于表示當前線程獲取共享鎖成功,但它后續的線程是無法繼續獲取的,也就是不需要把它后面等待的節點喚醒。 在了解了AQS獨占鎖模式以后,接下來再來看看共享鎖的實現原理。 原文地址:http://www.jianshu.com/p/1161... 搞清楚AQS獨占鎖的實現原理之后,再看共享鎖的實現原理就會輕松很多。兩種鎖模式之間很多通用的地方本文只會簡單說明一下,就不在贅述了,...
摘要:為了避免一篇文章的篇幅過長,于是一些比較大的主題就都分成幾篇來講了,這篇文章是筆者所有文章的目錄,將會持續更新,以給大家一個查看系列文章的入口。 前言 大家好,筆者是今年才開始寫博客的,寫作的初衷主要是想記錄和分享自己的學習經歷。因為寫作的時候發現,為了弄懂一個知識,不得不先去了解另外一些知識,這樣以來,為了說明一個問題,就要把一系列知識都了解一遍,寫出來的文章就特別長。 為了避免一篇...
摘要:獲取鎖的過程當線程調用申請獲取鎖資源,如果成功,則進入臨界區。如果隊列中有其他等待鎖資源的線程需要喚醒,則喚醒隊列中的第一個等待節點先入先出。釋放鎖時,如果隊列中有等待的線程就進行喚醒。 每一個Java工程師應該都或多或少了解過AQS,我自己也是前前后后,反反復復研究了很久,看了忘,忘了再看,每次都有不一樣的體會。這次趁著寫博客,打算重新拿出來系統的研究下它的源碼,總結成文章,便于以后...
閱讀 489·2021-09-03 00:22
閱讀 1365·2021-08-03 14:03
閱讀 2082·2021-07-25 21:37
閱讀 646·2019-08-30 13:18
閱讀 1875·2019-08-29 16:19
閱讀 2682·2019-08-29 13:22
閱讀 1293·2019-08-29 12:16
閱讀 2587·2019-08-26 12:16