【死磕Java併發】-----J.U.C之AQS:阻塞和喚醒執行緒
此篇部落格所有原始碼均來自JDK 1.8
線上程獲取同步狀態時如果獲取失敗,則加入CLH同步佇列,通過通過自旋的方式不斷獲取同步狀態,但是在自旋的過程中則需要判斷當前執行緒是否需要阻塞,其主要方法在acquireQueued():
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
通過這段程式碼我們可以看到,在獲取同步狀態失敗後,執行緒並不是立馬進行阻塞,需要檢查該執行緒的狀態,檢查狀態的方法為 shouldParkAfterFailedAcquire(Node pred, Node node) 方法,該方法主要靠前驅節點判斷當前執行緒是否應該被阻塞,程式碼如下:
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
//前驅節點
int ws = pred.waitStatus;
//狀態為signal,表示當前執行緒處於等待狀態,直接放回true
if (ws == Node.SIGNAL)
return true;
//前驅節點狀態 > 0 ,則為Cancelled,表明該節點已經超時或者被中斷了,需要從同步佇列中取消
if (ws > 0 ) {
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
}
//前驅節點狀態為Condition、propagate
else {
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
這段程式碼主要檢查當前執行緒是否需要被阻塞,具體規則如下:
- 如果當前執行緒的前驅節點狀態為SINNAL,則表明當前執行緒需要被阻塞,呼叫unpark()方法喚醒,直接返回true,當前執行緒阻塞
- 如果當前執行緒的前驅節點狀態為CANCELLED(ws > 0),則表明該執行緒的前驅節點已經等待超時或者被中斷了,則需要從CLH佇列中將該前驅節點刪除掉,直到回溯到前驅節點狀態 <= 0 ,返回false
- 如果前驅節點非SINNAL,非CANCELLED,則通過CAS的方式將其前驅節點設定為SINNAL,返回false
如果 shouldParkAfterFailedAcquire(Node pred, Node node) 方法返回true,則呼叫parkAndCheckInterrupt()方法阻塞當前執行緒:
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
parkAndCheckInterrupt() 方法主要是把當前執行緒掛起,從而阻塞住執行緒的呼叫棧,同時返回當前執行緒的中斷狀態。其內部則是呼叫LockSupport工具類的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;
}
呼叫unparkSuccessor(Node node)喚醒後繼節點:
private void unparkSuccessor(Node node) {
//當前節點狀態
int ws = node.waitStatus;
//當前狀態 < 0 則設定為 0
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
//當前節點的後繼節點
Node s = node.next;
//後繼節點為null或者其狀態 > 0 (超時或者被中斷了)
if (s == null || s.waitStatus > 0) {
s = null;
//從tail節點來找可用節點
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
//喚醒後繼節點
if (s != null)
LockSupport.unpark(s.thread);
}
可能會存在當前執行緒的後繼節點為null,超時、被中斷的情況,如果遇到這種情況了,則需要跳過該節點,但是為何是從tail尾節點開始,而不是從node.next開始呢?原因在於node.next仍然可能會存在null或者取消了,所以採用tail回溯辦法找第一個可用的執行緒。最後呼叫LockSupport的unpark(Thread thread)方法喚醒該執行緒。
LockSupport
從上面我可以看到,當需要阻塞或者喚醒一個執行緒的時候,AQS都是使用LockSupport這個工具類來完成的。
LockSupport是用來建立鎖和其他同步類的基本執行緒阻塞原語
每個使用LockSupport的執行緒都會與一個許可關聯,如果該許可可用,並且可在程序中使用,則呼叫park()將會立即返回,否則可能阻塞。如果許可尚不可用,則可以呼叫 unpark 使其可用。但是注意許可不可重入,也就是說只能呼叫一次park()方法,否則會一直阻塞。
LockSupport定義了一系列以park開頭的方法來阻塞當前執行緒,unpark(Thread thread)方法來喚醒一個被阻塞的執行緒。如下:
park(Object blocker)方法的blocker引數,主要是用來標識當前執行緒在等待的物件,該物件主要用於問題排查和系統監控。
park方法和unpark(Thread thread)都是成對出現的,同時unpark必須要在park執行之後執行,當然並不是說沒有不呼叫unpark執行緒就會一直阻塞,park有一個方法,它帶了時間戳(parkNanos(long nanos):為了執行緒排程禁用當前執行緒,最多等待指定的等待時間,除非許可可用)。
park()方法的原始碼如下:
public static void park() {
UNSAFE.park(false, 0L);
}
unpark(Thread thread)方法原始碼如下:
public static void unpark(Thread thread) {
if (thread != null)
UNSAFE.unpark(thread);
}
從上面可以看出,其內部的實現都是通過UNSAFE(sun.misc.Unsafe UNSAFE)來實現的,其定義如下:
public native void park(boolean var1, long var2);
public native void unpark(Object var1);
兩個都是native本地方法。Unsafe 是一個比較危險的類,主要是用於執行低級別、不安全的方法集合。儘管這個類和所有的方法都是公開的(public),但是這個類的使用仍然受限,你無法在自己的java程式中直接使用該類,因為只有授信的程式碼才能獲得該類的例項。
參考資料
歡迎掃一掃我的公眾號關注 — 及時得到部落格訂閱哦!
–— Java成神之路: 488391811(一起走向Java成神) –—
相關推薦
【死磕Java併發】-----J.U.C之AQS:阻塞和喚醒執行緒
此篇部落格所有原始碼均來自JDK 1.8 線上程獲取同步狀態時如果獲取失敗,則加入CLH同步佇列,通過通過自旋的方式不斷獲取同步狀態,但是在自旋的過程中則需要判斷當前執行緒是否需要阻塞,其主要方法在acquireQueued(): if (sho
【死磕Java併發】—– J.U.C之AQS:同步狀態的獲取與釋放
此篇部落格所有原始碼均來自JDK 1.8在前面提到過,AQS是構建Java同步元件的基礎,我們期
【死磕Java併發】-----J.U.C之AQS:AQS簡介
Java的內建鎖一直都是備受爭議的,在JDK 1.6之前,synchronized這個重量級鎖其效能一直都是較為低下,雖然在1.6後,進行大量的鎖優化策略(【死磕Java併發】—–深入分析synchronized的實現原理),但是與Lock相比synchroni
【死磕Java併發】-----J.U.C之AQS:CLH同步佇列
此篇部落格所有原始碼均來自JDK 1.8 CLH同步佇列是一個FIFO雙向佇列,AQS依賴它來完成同步狀態的管理,當前執行緒如果獲取同步狀態失敗時,AQS則會將當前執行緒已經等待狀態等資訊構造成一個節點(Node)並將其加入到CLH同步佇列,同時會
【死磕Java併發】—–J.U.C之AQS(一篇就夠了)
作者:大明哥 原文地址:http://cmsblogs.com 越是核心的東西越是要反覆看,本文篇幅較長,希望各位細細品讀,來回多讀幾遍理解下。 AQS簡介 java的內建鎖一直都是備受爭議的,在JDK 1.6之前,synchronized這個重量級鎖其效能一直都
J.U.C之AQS:阻塞和喚醒執行緒
此篇部落格所有原始碼均來自JDK 1.8 線上程獲取同步狀態時如果獲取失敗,則加入CLH同步佇列,通過通過自旋的方式不斷獲取同步狀態,但是在自旋的過程中則需要判斷當前執行緒是否需要阻塞,其主要方法在acquireQueued(): if(shouldParkAfter
【死磕Java併發】-----J.U.C之阻塞佇列:ArrayBlockingQueue
ArrayBlockingQueue,一個由陣列實現的有界阻塞佇列。該佇列採用FIFO的原則對元素進行排序新增的。 ArrayBlockingQueue為有界且固定,其大小在構造時由建構函式來決定,確認之後就不能再改變了。ArrayBlockingQueu
【死磕Java併發】—– J.U.C之併發工具類:Semaphore
此篇部落格所有原始碼均來自JDK 1.8訊號量Semaphore是一個控制訪問多個共享資源的計數
【死磕Java併發】-----J.U.C之併發工具類:Exchanger
此篇部落格所有原始碼均來自JDK 1.8 前面三篇部落格分別介紹了CyclicBarrier、CountDownLatch、Semaphore,現在介紹併發工具類中的最後一個Exchange。Exchange是最簡單的也是最複雜的,簡單在於API非常簡
【死磕Java併發】-----J.U.C之Condition
此篇部落格所有原始碼均來自JDK 1.8 在沒有Lock之前,我們使用synchronized來控制同步,配合Object的wait()、notify()系列方法可以實現等待/通知模式。在Java SE5後,Java提供了Lock介面,相對於Synch
【死磕Java併發】-----J.U.C之重入鎖:ReentrantLock
此篇部落格所有原始碼均來自JDK 1.8 ReentrantLock,可重入鎖,是一種遞迴無阻塞的同步機制。它可以等同於synchronized的使用,但是ReentrantLock提供了比synchronized更強大、靈活的鎖機制,可以減少死鎖發生
【死磕Java併發】-----J.U.C之阻塞佇列:DelayQueue
DelayQueue是一個支援延時獲取元素的無界阻塞佇列。裡面的元素全部都是“可延期”的元素,列頭的元素是最先“到期”的元素,如果佇列裡面沒有元素到期,是不能從列頭獲取元素的,哪怕有元素也不行。也就是說只有在延遲期到時才能夠從佇列中取元素。 DelayQu
【死磕Java併發】-----J.U.C之併發工具類:CyclicBarrier
此篇部落格所有原始碼均來自JDK 1.8 CyclicBarrier,一個同步輔助類,在API中是這麼介紹的: 它允許一組執行緒互相等待,直到到達某個公共屏障點 (common barrier point)。在涉及一組固定大小的執行緒的程式中,這些執
J.U.C之AQS:阻塞和喚醒線程
smart -i back ont () 而不是 受限 clh blog 此篇博客所有源碼均來自JDK 1.8 在線程獲取同步狀態時如果獲取失敗,則加入CLH同步隊列,通過通過自旋的方式不斷獲取同步狀態,但是在自旋的過程中則需要判斷當前線程是否需要阻塞,其主要方法在ac
【死磕Java並發】—–J.U.C之AQS(一篇就夠了)
ini tle 循環 針對 可能 width als 如果 boolean [隱藏目錄]1 獨占式1.1 獨占式同步狀態獲取1.2 獨占式獲取響應中斷1.3 獨占式超時獲取1.4 獨占式同步狀態釋放2 共享式2.1 共享式
【死磕Java併發】-----Java記憶體模型之happens-before
在上篇部落格(【死磕Java併發】—–深入分析volatile的實現原理)LZ提到過由於存線上程本地記憶體和主記憶體的原因,再加上重排序,會導致多執行緒環境下存在可見性的問題。那麼我們正確使用同步、鎖的情況下,執行緒A修改了變數a何時對執行緒B可見? 我們無法就所有場景來規
【死磕Java併發】- 深入分析volatile的實現原理
通過前面一章我們瞭解了synchronized是一個重量級的鎖,雖然JVM對它做了很多優化,而下面介紹的volatile則是輕量級的synchronized。如果一個變數使用volatile,則它比使用synchronized的成本更加低,因為它不會引起執行緒上下文的切換和排程。Java語言
【死磕Java併發】-----Java記憶體模型之分析volatile
volatile可見性;對一個volatile的讀,總可以看到對這個變數最終的寫; volatile原子性;volatile對單個讀/寫具有原子性(32位Long、Double),但是複合操作除外,例如i++; JVM底層採用“記憶體屏障”來實現volat
【死磕Java併發】--Java記憶體模型之happens-before
在上篇部落格(【死磕Java併發】—–深入分析volatile的實現原理)LZ提到過由於存線上程本地記憶體和主記憶體的原因,再加上重排序,會導致多執行緒環境下存在可見性的問題。那麼我們正確使用同步、鎖的情況下,執行緒A修改了變數a何時對執行緒B可見?我們無法就所有場景來規定某
【死磕Java併發】-----Java記憶體模型之總結
經過四篇部落格闡述,我相信各位對Java記憶體模型有了最基本認識了,下面LZ就做一個比較簡單的總結。 總結 JMM規定了執行緒的工作記憶體和主記憶體的互動關係,以及執行緒之間的可見性和程式的執行順序。一方面,要為程式設計師提供足夠強的記憶體可見性保證;另