Java?多線程并發(fā)LockSupport
概覽
這部分內(nèi)容來自于這個類的注釋，簡單翻譯了下。
LockSupport 類是用于創(chuàng)建鎖和其他同步類的基本線程阻塞原語。
它的實現(xiàn)思想是給每個使用它的線程頒發(fā)一個許可，當許可是可用狀態(tài)時（線程有許可），調(diào)用 park 方法會消耗一個許可，方法立即返回（與信號量的作用類似），線程可以繼續(xù)執(zhí)行 park 方法后面的邏輯；如果調(diào)用 park 方法前，許可處于不可用狀態(tài)（線程沒有許可），park 方法不會立即返回，從而導致線程阻塞。而此時，可以通過調(diào)用 unpark 方法使許可恢復到可用狀態(tài)（但與信號量不同，許可不會累積。最多有一個）。
方法 park 和 unpark 提供了阻塞和解除阻塞線程的有效方法，這些線程不會遇到 Thread.suspend 和 Thread.resume 存在的問題（因suspend 容易導致死鎖，這倆個方法因為這個原因已經(jīng)被棄用 ），因為 park 和 unpark 調(diào)用的線程，不存在鎖競爭。
而如果調(diào)用 park 方法的線程被中斷，park 方法將會立即 return ，并且有設置超時版本的 park 方法。park 方法也可以在任何其他時間沒有原因的 return，因此通常必須在返回時重新檢查條件的循環(huán)中調(diào)用。從這個意義上說，park 是對“繁忙等待”的優(yōu)化，它不會浪費太多時間旋轉(zhuǎn)，但必須與 unpark 配對才能有效。
park 方法有對應帶有 blocker 對象參數(shù)的重載方法， blocker 對象在線程被阻塞時被記錄，以允許監(jiān)視和診斷工具識別線程被阻塞的原因。 （此類工具可以使用 getBlocker(Thread) 方法訪問阻止程序。）強烈建議使用這些表單而不是沒有此參數(shù)的原始表單。 在鎖實現(xiàn)中作為阻塞器提供的正常參數(shù)是 this。
本質(zhì)上 LockSupport 實現(xiàn)了一種自旋，構造類似于：
while (!canProceed()) { ... LockSupport.park(this); }其中 `canProceed 或在調(diào)用之前的任何其他操作都不會導致鎖定或阻塞。 因為每個線程只有一個許可，所以任何對 park 的中間使用都可能會干擾其預期效果。
示例用法。 這是一個先進先出不可重入鎖類的草圖：
class FIFOMutex {
? private final AtomicBoolean locked = new AtomicBoolean(false);
? private final Queue<Thread> waiters
? ? = new ConcurrentLinkedQueue<Thread>();
? public void lock() {
? ? boolean wasInterrupted = false;
? ? Thread current = Thread.currentThread();
? ? waiters.add(current);
? ? // Block while not first in queue or cannot acquire lock
? ? while (waiters.peek() != current ||
? ? ? ? ? ?!locked.compareAndSet(false, true)) {
? ? ? LockSupport.park(this);
? ? ? if (Thread.interrupted()) // ignore interrupts while waiting
? ? ? ? wasInterrupted = true;
? ? }
? ? waiters.remove();
? ? if (wasInterrupted) ? ? ? ? ?// reassert interrupt status on exit
? ? ? current.interrupt();
? }
? public void unlock() {
? ? locked.set(false);
? ? LockSupport.unpark(waiters.peek());
? }
}源碼分析
整個 LockSupport 類的代碼量還算少，去掉注釋僅有 100 行，所有的屬性和方法都是靜態(tài)的，并且備注明確說明了 LockSupport 無法實例化：
public class LockSupport {
? ?private LockSupport() {} // 無法實例化
? ?// ...
}LockSupport 中包含了幾個私有的內(nèi)部靜態(tài)屬性：
public class LockSupport {
// 通過內(nèi)部 API 實現(xiàn) Hotspot
? ?private static final Unsafe U = Unsafe.getUnsafe();
? ?private static final long PARKBLOCKER= U.objectFieldOffset(Thread.class, "parkBlocker");
? ?private static final long TID = U.objectFieldOffset(Thread.class, "tid");
// ...
}從這些內(nèi)部私有的靜態(tài)屬性可以看出，最重要的就是 U 了，LockSupport 中的方法，本質(zhì)上也是調(diào)用U 提供的能力。U 在 CAS 與原子類中有介紹，是 JDK 中提供的一些非阻塞線程安全的實現(xiàn)能力的類，它的大多數(shù)方法都是 native 方法。
靜態(tài)方法
LockSupport 基本上就是個靜態(tài)工具類，它的主要能力，集中在它的靜態(tài)方法中。
public class LockSupport {
public static void unpark(Thread thread)
public static void park(Object blocker)
public static void parkNanos(Object blocker, long nanos)
public static void parkUntil(Object blocker, long deadline)
public static Object getBlocker(Thread t)
? ?public static void setCurrentBlocker(Object blocker)
? ?private static void setBlocker(Thread t, Object arg)
public static void park()
public static void parkNanos(long nanos)
public static void parkUntil(long deadline)
? ?static final long getThreadId(Thread thread)
}從方法名就可以看出，主要分為三個：
- unpark
- park
- getBlocker
Blocker
public static Object getBlocker(Thread t) {
? ?if (t == null)
? ? ? ?throw new NullPointerException();
? ?return U.getReferenceOpaque(t, PARKBLOCKER);
}
private static void setBlocker(Thread t, Object arg) {
? ?U.putReferenceOpaque(t, PARKBLOCKER, arg);
}
// 在 JDK 14 之前是不存在該方法的， setBlocker 只能從內(nèi)部進行
public static void setCurrentBlocker(Object blocker) {
? ?U.putReferenceOpaque(Thread.currentThread(), PARKBLOCKER, blocker);
}setCurrentBlocker 的作用是，設置當前線程調(diào)用 getBlocker 返回的對象。 在 JDK 14 后暴露這個方法的用途，是用來配合park() 的無參數(shù)版本設置 Blocker ，它可以實現(xiàn) park(blocker) 的效果：
setCurrentBlocker(b); park(); setCurrentBlocker(null);
而私有靜態(tài)方法 setBlocker 是在 park 的有參數(shù)方法中封裝使用的。
對于 blocker 的保存，本質(zhì)是通過 Unsafe 的 putReferenceOpaque 方法保存和 getReferenceOpaque 方法讀取的。
@IntrinsicCandidate
public final void putReferenceOpaque(Object o, long offset, Object x) {
? ?putReferenceVolatile(o, offset, x);
}
// 使用 volatile 存儲語義將引用值存儲到給定的 Java 變量中。 否則等同于 putReference(Object, long, Object)
@IntrinsicCandidate
public native void putReferenceVolatile(Object o, long offset, Object x);
@IntrinsicCandidate
public final Object getReferenceOpaque(Object o, long offset) {
? ?return getReferenceVolatile(o, offset);
}
// 從給定的 Java 變量中獲取引用值，具有可變加載語義。 否則等同于 getReference(Object, long)
@IntrinsicCandidate
public native Object getReferenceVolatile(Object o, long offset);在 src/hotspot/share/opto/library_call.cpp 中發(fā)現(xiàn)了 Java 到 native 方法的映射：
case vmIntrinsics::_putReferenceVolatile: return inline_unsafe_access( is_store, T_OBJECT, ? Volatile, false);
native 最終調(diào)用到是老朋友 inline_unsafe_access 。（這里不詳細展開了。。我也沒搞明白這個方法，和匯編指令相關）
需要注意的是，最終的都是將對象設置為了 volatile 。充分說明 LockSupport 也是一套非阻塞同步方案。
而上面提到的 putReference(Object, long, Object)的作用是：將引用值存儲到給定的 Java 變量中。
@IntrinsicCandidate public native void putReference(Object o, long offset, Object x);
除非存儲的引用 x 為 null 或與字段類型匹配，否則結果是未定義的。 如果引用 o 不為空，則更新該對象的卡片標記或其他存儲屏障（如果 VM 需要它們）。
unpark
public static void unpark(Thread thread) {
if (thread != null)
U.unpark(thread);
}解除調(diào)用 park 的線程的阻塞狀態(tài)，或者如果調(diào)用 park 的線程沒有阻塞，則會導致后續(xù)調(diào)用 park 不會造成阻塞。
注意：這個操作是不安全的，調(diào)用者必須確保線程沒有被銷毀。
這是什么意思呢？通過下面這個例子可以感受到先調(diào)用 unpark 后，指定參數(shù)中的線程參數(shù)對象調(diào)用 park 不會造成阻塞：
class LockSupportDemo {
? ?fun check() {
? ? ? ?val thread1 = Thread {
? ? ? ? ? ?Thread.sleep(1000)
? ? ? ? ? ?println("thread1 start + ${Date(System.currentTimeMillis())}")
? ? ? ? ? ?LockSupport.park()
? ? ? ? ? ?println("thread1 end + ${Date(System.currentTimeMillis())}")
? ? ? }
?
? ? ? ?val thread2 = Thread {
? ? ? ? ? ?println("thread2 start + ${Date(System.currentTimeMillis())}")
? ? ? ? ? ?LockSupport.unpark(thread1)
? ? ? ? ? ?println("thread2 end + ${Date(System.currentTimeMillis())}")
? ? ? }
? ? ? ?thread1.start()
? ? ? ?thread2.start()
? }
}打印日志：
thread2 start + Fri Jun 03 02:19:34 CST 2022
thread2 end + Fri Jun 03 02:19:34 CST 2022
thread1 start + Fri Jun 03 02:19:35 CST 2022
thread1 end + Fri Jun 03 02:19:35 CST 2022
thread2 優(yōu)先執(zhí)行，thread1 在 thread2 開始執(zhí)行 1s 后執(zhí)行，thread1 調(diào)用了 LockSupport.park() ，并沒有造成自身阻塞。
Unsafe 的 unpark 方法
LockSupport.unpark(thread) 內(nèi)部實際只調(diào)用了 Unsafe#unpark(thread);：
public native void unpark(Object thread); 復制代碼
又是一個 native 方法。在 JDK 中發(fā)現(xiàn) Parker::unpark 的定義在 os_posix.cpp 和 on_windows.cpp 中：
可以看出這個 native 方法，應該在不同的平臺會有不同的實現(xiàn)。
park
park 方法有兩組重載方法：
// 不帶 blocker public static void park() public static void parkNanos(long nanos) public static void parkUntil(long deadline) // 需要 blocker 參數(shù) public static void park(Object blocker) public static void parkNanos(Object blocker, long nanos) public static void parkUntil(Object blocker, long deadline)
不帶 blocker 參數(shù)的分組
沒有 blocker 參數(shù)的一組本質(zhì)上的邏輯是：
U.park(boolean, long); 復制代碼
這一點可以從三個方法中看出：
public static void park() {
U.park(false, 0L);
}
public static void parkNanos(long nanos) {
? ?if (nanos > 0)
? ? ? ?U.park(false, nanos);
}
public static void parkUntil(long deadline) {
? ?U.park(true, deadline);
}這三個方法的區(qū)別是：
park
方法的作用是：除非許可處于可用狀態(tài)，否者關閉當前線程的線程調(diào)度的意圖。如果許可可用，則許可被使用掉，并立即返回。否則當前線程因為線程調(diào)度的意圖被關閉而導致阻塞。
直到發(fā)生以下三種情況之一：
其他線程以當前線程為目標調(diào)用 unpark
其他線程中斷當前線程
調(diào)用虛假地 return（即 no reason）
這個方法不會報告是哪一種原因?qū)е碌?return。調(diào)用者應該重新檢查導致線程第一次停止的條件。 例如，調(diào)用者還可以確定線程在返回時的中斷狀態(tài)。
parkNanos
禁用當前線程的線程調(diào)度意圖，直到指定的等待時間，除非許可可用。如果參數(shù) nanos 為 0 或為負數(shù)，這個方法將不會做任何事情。
parkUntil
禁用當前線程的線程調(diào)度意圖，直到指定的最后期限，除非許可可用。參數(shù) deadline 是截止日期——從 Epoch 開始等待的絕對時間，以毫秒為單位。
需要 blocker 參數(shù)的分組
public static void park(Object blocker) {
? ?Thread t = Thread.currentThread();
? ?setBlocker(t, blocker);
? ?U.park(false, 0L);
? ?setBlocker(t, null);
}
public static void parkNanos(Object blocker, long nanos) {
? ?if (nanos > 0) {
? ? ? ?Thread t = Thread.currentThread();
? ? ? ?setBlocker(t, blocker);
? ? ? ?U.park(false, nanos);
? ? ? ?setBlocker(t, null);
? }
}
public static void parkUntil(Object blocker, long deadline) {
? ?Thread t = Thread.currentThread();
? ?setBlocker(t, blocker);
? ?U.park(true, deadline);
? ?setBlocker(t, null);
}帶有 blocker 參數(shù)的這組函數(shù)，它們和對應的不帶參數(shù)的方法意義是一樣的，多了一個設置對象的操作。而這個對象 blocker 是負責此線程 parking 的同步對象 。
這組重載方法有共同的邏輯：
- 獲取當前線程對象。
- 將
blocker對象的引用值存儲到線程對象中。 - 調(diào)用 Unsafe 對象的
park(boolean, long)方法。 - 將當前線程對象存儲的引用值設置為 null 。
讓我困惑的是，這個存儲引用值操作有什么作用。但是聯(lián)想到線程操作和對象，驚奇的發(fā)現(xiàn)我們常用的 API Object.wait() 和 Object.notify() ，好像和這個場景很像，都用到了一個 Object ，也都造成了線程阻塞喚醒。
park/unpark 和 Object 的 wait/notify
public class LockSupportJava {
? ?Object obj = new Object();?
? ?public static void main(String[] args) {
? ? ? ?LockSupportJava lock = new LockSupportJava();
? ? ? ?lock.waitAndNotify();
? }
? ?void waitAndNotify() {
? ? ? ?Thread thread1 = new Thread(() -> {
? ? ? ? ? ?synchronized(obj) {
? ? ? ? ? ? ? ?try {
? ? ? ? ? ? ? ? System.out.println("thread1 start + " + new Date(System.currentTimeMillis()));
? ? ? ? ? ? ? ? ? ?Thread.sleep(1000);
? ? ? ? ? ? ? ? ? ?obj.notify();
? ? ? ? ? ? ? System.out.println("thread1 end + " + new Date(System.currentTimeMillis()));
? ? ? ? ? ? ? } catch (InterruptedException e) {
? ? ? ? ? ? ? ? ? ?e.printStackTrace();
? ? ? ? ? ? ? }
? ? ? ? ? }
? ? ? });?
? ? ? ?Thread thread2 = new Thread(() -> {
? ? ? ? ? ?synchronized(obj) {
? ? ? ? ? ? ? ?try {
? ? ? ? ? ? ? ? ? ?thread1.start();
? ? ? ? ? ? ? ? ? ?Thread.sleep(3000);
? ? ? ? ? ? ? ? ? ?System.out.println("thread2 start + " + new Date(System.currentTimeMillis()));
? ? ? ? ? ? ? ? ? ?obj.wait();
? ? ? ? ? ? ? ? ? ?System.out.println("thread2 end + " + new Date(System.currentTimeMillis()));
? ? ? ? ? ? ? } catch (InterruptedException e) {
? ? ? ? ? ? ? ? ? ?e.printStackTrace();
? ? ? ? ? ? ? }
? ? ? ? ? }
? ? ? });
? ? ? ?thread2.start();
? }
}這是一個簡單的 Demo ，創(chuàng)建了兩個線程 thread1 和 thread2 。
線程 2 從主線程先執(zhí)行，持有了 obj對象的鎖，在它的執(zhí)行邏輯中：
- 先啟動線程 1
- 線程 2 睡眠 3 秒
- 三秒后打印 start，obj 對象調(diào)用 wait ，使當前線程讓出對象的鎖，并進入阻塞狀態(tài)。
此時，線程 1 可以獲取到 obj 對象的鎖了，它的執(zhí)行邏輯：
- 線程 1 開始打印 start
- 睡眠 1 秒
- obj 對象調(diào)用 notify ，線程 2 開始嘗試獲取 obj 的鎖。
- 打印 end ，執(zhí)行結束，讓出 obj 的鎖
最后，線程 2 重新獲取到了 obj 的鎖，繼續(xù)執(zhí)行打印 end 。
從打印日志中，驗證打印順序：
thread2 start + Fri Jun 03 04:02:17 CST 2022
thread1 start + Fri Jun 03 04:02:17 CST 2022
thread1 end + Fri Jun 03 04:02:18 CST 2022
thread2 end + Fri Jun 03 04:02:18 CST 2022
注意：使用wait/notify實現(xiàn)同步時，必須先調(diào)用wait，后調(diào)用notify，如果先調(diào)用notify，再調(diào)用wait，會導致線程一直阻塞。
而如果使用 park / unpark 實現(xiàn)一個阻塞喚醒效果：
? ?Thread thread;
? ?void parkAndUnpark() {
? ? ? ?Thread thread2 = new Thread(() -> {
? ? ? ? ? ?System.out.println("thread2 start + " + new Date(System.currentTimeMillis()));
? ? ? ? ? ?thread.start();
? ? ? ? ? ?LockSupport.park(obj);
? ? ? ? ? ?System.out.println("Blocker info " + LockSupport.getBlocker(Thread.currentThread()));
? ? ? ? ? ?System.out.println("thread2 end + " + new Date(System.currentTimeMillis()));
? ? ? });
? ? ? ?// 喚起 thread2
? ? ? ?Thread thread1 = new Thread(() -> {
? ? ? ? ? ?try {
? ? ? ? ? ? ? ?System.out.println("thread1 start + " + new Date(System.currentTimeMillis()));
? ? ? ? ? ? ? ?Thread.sleep(3000);
? ? ? ? ? ? ? ?System.out.println("Blocker info " + LockSupport.getBlocker(thread2));
? ? ? ? ? ? ? ?LockSupport.unpark(thread2);
? ? ? ? ? ? ? ?System.out.println("thread1 end + " + new Date(System.currentTimeMillis()));
? ? ? ? ? } catch (InterruptedException e) {
? ? ? ? ? ? ? ?e.printStackTrace();
? ? ? ? ? }
? ? ? });
? ? ? ?thread = thread1;
? ? ? ?thread2.start();
? }parkAndUnpark() 方法中，先啟動了線程 2，線程 2 打印完 start 后就啟動了線程 1 。而此時線程 2 繼續(xù)執(zhí)行：
- 調(diào)用 park 進入阻塞狀態(tài)
在線程 2 執(zhí)行上面兩個邏輯的同時，線程 1 也在同時執(zhí)行：
- 線程 1 啟動后先打印 start
- 線程 1 睡眠 3 秒
- 檢查線程 2 調(diào)用
park(Object)方法設置的 Blocker 信息 - 調(diào)用
LockSupport.unpark(thread2)解除線程 2 的阻塞 - 線程 1 打印 end 執(zhí)行結束
線程 2 在被線程 1 喚醒后，繼續(xù)執(zhí)行打印信息：
- 打印當前線程的 Blocker 信息，為 null
- 打印 end 執(zhí)行結束
打印日志：
thread2 start + Fri Jun 03 04:24:32 CST 2022
thread1 start + Fri Jun 03 04:24:32 CST 2022
Blocker info java.lang.Object@7a3acdd9
thread1 end + Fri Jun 03 04:24:35 CST 2022
Blocker info null
thread2 end + Fri Jun 03 04:24:35 CST 2022
注意：先調(diào)用 unpark 后調(diào)用 park 也不會導致阻塞，更加靈活。
可以發(fā)現(xiàn)，blocker 在線程恢復后變成了 null ，個人理解它的作用就是用來做阻塞標記的，可以用來在線程阻塞狀態(tài)下，將一個對象設置上，然后在其他線程中讀取這個對象。blocker 與線程的單次阻塞狀態(tài)綁定，可以用于對線程狀態(tài)的排查和線程狀態(tài)的監(jiān)控。
區(qū)別
從 wait/notify 和 park/unpark 兩種阻塞線程和喚起線程的方式，能夠感受出兩者的不同之處：
- wait/notify 需要配合 synchronized 進行；park/unpark 雖然設置了 blocker 但全程沒有鎖。
- wait/notify 需要保證 wait 在前，notify 在后，否則會阻塞線程；park/unpark 對調(diào)用順序沒有限制。不會造成阻塞。
- wait/notify 方法在 Object 中定義，用于對象鎖的資源讓出；park/unpark 來自于
LockSupport，是靜態(tài)方法，用于對線程本身進行掛起喚醒。并可以通過blocker綁定線程阻塞狀態(tài)下的一些信息。
個人感覺 park/unpark 更像是 掛起/恢復，而 Thread.suspend 和 Thread.resume 都已廢棄，是很好的替代方案。
suspend，掛起線程，但是不會釋放類似鎖這樣的資源。resume，恢復線程，如果之前沒有使用suspend暫停線程，則不起作用。Thread.stop()由于其固有的風險而被逐步淘汰。當你停止一個線程時，它會解鎖它鎖定的所有監(jiān)視器。如果以前受這些監(jiān)視器保護的任何對象處于不一致狀態(tài)，其他線程可能會看到這些對象處于不一致狀態(tài)。 作用在受損物體上的線可能會有意或無意地行為不規(guī)律。與其他不受控制的異常不同，ThreadDeath 會靜默地殺死線程，不會向用戶發(fā)出程序可能已損壞的警告。損壞發(fā)生后，損壞可能會在無法預料的時刻出現(xiàn)。此外，在多線程環(huán)境中使用 DBMS – JDBC 時，終止線程會產(chǎn)生問題。Thread.suspend()已被棄用，因為它本質(zhì)上容易死鎖。因此，Thread.resume()也必須被棄用。當目標線程被掛起時，它會在監(jiān)視器上鎖定一個保護關鍵系統(tǒng)資源的鎖，并且在目標線程恢復之前沒有其他線程可以訪問它。如果將重新啟動目標線程的線程在調(diào)用 resume() 之前嘗試鎖定此監(jiān)視器，則會發(fā)生死鎖。
到此這篇關于Java 多線程并發(fā)LockSupport的文章就介紹到這了,更多相關Java LockSupport內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
這篇文章主要為大家詳細介紹了javaweb如何實現(xiàn)請求和響應,具有一定的參考價值，感興趣的小伙伴們可以參考一下2016-10-10
大家好，本篇文章主要講的是Java中值類型和引用類型詳解，感興趣的同學趕快來看一看吧，對你有幫助的話記得收藏一下，方便下次瀏覽2022-01-01
解決swaggerUI頁面沒有顯示Controller方法的坑
這篇文章主要介紹了解決swaggerUI頁面沒有顯示Controller方法的坑，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2021-06-06
Spring中DAO被循環(huán)調(diào)用的時候數(shù)據(jù)不實時更新的解決方法
這篇文章主要介紹了Spring中DAO被循環(huán)調(diào)用的時候數(shù)據(jù)不實時更新的解決方法,需要的朋友可以參考下2014-08-08
本文主要介紹了SpringBoot實現(xiàn)文件下載的四種方式,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2023-11-11
Guava在實際的Java后端項目中應用的場景還是比較多的，比如限流，緩存，容器操作之類的，本文主要介紹了GuavaCache返回Null的注意事項，感興趣的可以了解一下2021-10-10
這篇文章主要介紹了Java的Junit測試框架中的其他注解說明,JUnit是一個開源的java單元測試框架,它是XUnit測試體系架架構的一種體現(xiàn),2023-10-10
是Java語言事實上的標準單元測試庫,需要的朋友可以參考下
SpringCloud Hystrix-Dashboard儀表盤的實現(xiàn)
這篇文章主要介紹了SpringCloud Hystrix-Dashboard儀表盤的實現(xiàn)，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2019-08-08
這篇文章主要介紹了Java調(diào)用dll文件的實現(xiàn)解析，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-02-02
這篇文章主要介紹了關于ZooKeeper的會話機制Session解讀，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2023-02-02