Java?多線(xiàn)程并發(fā)LockSupport
概覽
這部分內(nèi)容來(lái)自于這個(gè)類(lèi)的注釋?zhuān)?jiǎn)單翻譯了下。
LockSupport
類(lèi)是用于創(chuàng)建鎖和其他同步類(lèi)的基本線(xiàn)程阻塞原語(yǔ)。
它的實(shí)現(xiàn)思想是給每個(gè)使用它的線(xiàn)程頒發(fā)一個(gè)許可,當(dāng)許可是可用狀態(tài)時(shí)(線(xiàn)程有許可),調(diào)用 park 方法會(huì)消耗一個(gè)許可,方法立即返回(與信號(hào)量的作用類(lèi)似),線(xiàn)程可以繼續(xù)執(zhí)行 park 方法后面的邏輯;如果調(diào)用 park 方法前,許可處于不可用狀態(tài)(線(xiàn)程沒(méi)有許可),park 方法不會(huì)立即返回,從而導(dǎo)致線(xiàn)程阻塞。而此時(shí),可以通過(guò)調(diào)用 unpark 方法使許可恢復(fù)到可用狀態(tài)(但與信號(hào)量不同,許可不會(huì)累積。最多有一個(gè))。
方法 park 和 unpark 提供了阻塞和解除阻塞線(xiàn)程的有效方法,這些線(xiàn)程不會(huì)遇到 Thread.suspend
和 Thread.resume
存在的問(wèn)題(因suspend 容易導(dǎo)致死鎖,這倆個(gè)方法因?yàn)檫@個(gè)原因已經(jīng)被棄用 ),因?yàn)?park 和 unpark 調(diào)用的線(xiàn)程,不存在鎖競(jìng)爭(zhēng)。
而如果調(diào)用 park 方法的線(xiàn)程被中斷,park 方法將會(huì)立即 return ,并且有設(shè)置超時(shí)版本的 park 方法。park 方法也可以在任何其他時(shí)間沒(méi)有原因的 return,因此通常必須在返回時(shí)重新檢查條件的循環(huán)中調(diào)用。從這個(gè)意義上說(shuō),park 是對(duì)“繁忙等待”的優(yōu)化,它不會(huì)浪費(fèi)太多時(shí)間旋轉(zhuǎn),但必須與 unpark 配對(duì)才能有效。
park 方法有對(duì)應(yīng)帶有 blocker 對(duì)象參數(shù)的重載方法, blocker 對(duì)象在線(xiàn)程被阻塞時(shí)被記錄,以允許監(jiān)視和診斷工具識(shí)別線(xiàn)程被阻塞的原因。 (此類(lèi)工具可以使用 getBlocker(Thread) 方法訪(fǎng)問(wèn)阻止程序。)強(qiáng)烈建議使用這些表單而不是沒(méi)有此參數(shù)的原始表單。 在鎖實(shí)現(xiàn)中作為阻塞器提供的正常參數(shù)是 this。
本質(zhì)上 LockSupport 實(shí)現(xiàn)了一種自旋,構(gòu)造類(lèi)似于:
while (!canProceed()) { ... LockSupport.park(this); }
其中 `canProceed 或在調(diào)用之前的任何其他操作都不會(huì)導(dǎo)致鎖定或阻塞。 因?yàn)槊總€(gè)線(xiàn)程只有一個(gè)許可,所以任何對(duì) park 的中間使用都可能會(huì)干擾其預(yù)期效果。
示例用法。 這是一個(gè)先進(jìn)先出不可重入鎖類(lèi)的草圖:
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()); ? } }
源碼分析
整個(gè) LockSupport 類(lèi)的代碼量還算少,去掉注釋僅有 100 行,所有的屬性和方法都是靜態(tài)的,并且備注明確說(shuō)明了 LockSupport 無(wú)法實(shí)例化:
public class LockSupport { ? ?private LockSupport() {} // 無(wú)法實(shí)例化 ? ?// ... }
LockSupport 中包含了幾個(gè)私有的內(nèi)部靜態(tài)屬性:
public class LockSupport { // 通過(guò)內(nèi)部 API 實(shí)現(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 與原子類(lèi)中有介紹,是 JDK 中提供的一些非阻塞線(xiàn)程安全的實(shí)現(xiàn)能力的類(lèi),它的大多數(shù)方法都是 native 方法。
靜態(tài)方法
LockSupport 基本上就是個(gè)靜態(tài)工具類(lè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) }
從方法名就可以看出,主要分為三個(gè):
- 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)部進(jìn)行 public static void setCurrentBlocker(Object blocker) { ? ?U.putReferenceOpaque(Thread.currentThread(), PARKBLOCKER, blocker); }
setCurrentBlocker
的作用是,設(shè)置當(dāng)前線(xiàn)程調(diào)用 getBlocker
返回的對(duì)象。 在 JDK 14 后暴露這個(gè)方法的用途,是用來(lái)配合park()
的無(wú)參數(shù)版本設(shè)置 Blocker ,它可以實(shí)現(xiàn) park(blocker)
的效果:
setCurrentBlocker(b); park(); setCurrentBlocker(null);
而私有靜態(tài)方法 setBlocker
是在 park 的有參數(shù)方法中封裝使用的。
對(duì)于 blocker
的保存,本質(zhì)是通過(guò) Unsafe
的 putReferenceOpaque
方法保存和 getReferenceOpaque
方法讀取的。
@IntrinsicCandidate public final void putReferenceOpaque(Object o, long offset, Object x) { ? ?putReferenceVolatile(o, offset, x); } // 使用 volatile 存儲(chǔ)語(yǔ)義將引用值存儲(chǔ)到給定的 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 變量中獲取引用值,具有可變加載語(yǔ)義。 否則等同于 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
。(這里不詳細(xì)展開(kāi)了。。我也沒(méi)搞明白這個(gè)方法,和匯編指令相關(guān))
需要注意的是,最終的都是將對(duì)象設(shè)置為了 volatile
。充分說(shuō)明 LockSupport
也是一套非阻塞同步方案。
而上面提到的 putReference(Object, long, Object)
的作用是:將引用值存儲(chǔ)到給定的 Java 變量中。
@IntrinsicCandidate public native void putReference(Object o, long offset, Object x);
除非存儲(chǔ)的引用 x
為 null 或與字段類(lèi)型匹配,否則結(jié)果是未定義的。 如果引用 o
不為空,則更新該對(duì)象的卡片標(biāo)記或其他存儲(chǔ)屏障(如果 VM 需要它們)。
unpark
public static void unpark(Thread thread) { if (thread != null) U.unpark(thread); }
解除調(diào)用 park 的線(xiàn)程的阻塞狀態(tài),或者如果調(diào)用 park 的線(xiàn)程沒(méi)有阻塞,則會(huì)導(dǎo)致后續(xù)調(diào)用 park 不會(huì)造成阻塞。
注意:這個(gè)操作是不安全的,調(diào)用者必須確保線(xiàn)程沒(méi)有被銷(xiāo)毀。
這是什么意思呢?通過(guò)下面這個(gè)例子可以感受到先調(diào)用 unpark 后,指定參數(shù)中的線(xiàn)程參數(shù)對(duì)象調(diào)用 park 不會(huì)造成阻塞:
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 開(kāi)始執(zhí)行 1s 后執(zhí)行,thread1 調(diào)用了 LockSupport.park()
,并沒(méi)有造成自身阻塞。
Unsafe 的 unpark 方法
LockSupport.unpark(thread)
內(nèi)部實(shí)際只調(diào)用了 Unsafe#unpark(thread);
:
public native void unpark(Object thread); 復(fù)制代碼
又是一個(gè) native 方法。在 JDK 中發(fā)現(xiàn) Parker::unpark
的定義在 os_posix.cpp
和 on_windows.cpp
中:
可以看出這個(gè) native 方法,應(yīng)該在不同的平臺(tái)會(huì)有不同的實(shí)現(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ù)的分組
沒(méi)有 blocker
參數(shù)的一組本質(zhì)上的邏輯是:
U.park(boolean, long); 復(fù)制代碼
這一點(diǎn)可以從三個(gè)方法中看出:
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); }
這三個(gè)方法的區(qū)別是:
park
方法的作用是:除非許可處于可用狀態(tài),否者關(guān)閉當(dāng)前線(xiàn)程的線(xiàn)程調(diào)度的意圖。如果許可可用,則許可被使用掉,并立即返回。否則當(dāng)前線(xiàn)程因?yàn)榫€(xiàn)程調(diào)度的意圖被關(guān)閉而導(dǎo)致阻塞。
直到發(fā)生以下三種情況之一:
其他線(xiàn)程以當(dāng)前線(xiàn)程為目標(biāo)調(diào)用 unpark
其他線(xiàn)程中斷當(dāng)前線(xiàn)程
調(diào)用虛假地 return(即 no reason)
這個(gè)方法不會(huì)報(bào)告是哪一種原因?qū)е碌?return。調(diào)用者應(yīng)該重新檢查導(dǎo)致線(xiàn)程第一次停止的條件。 例如,調(diào)用者還可以確定線(xiàn)程在返回時(shí)的中斷狀態(tài)。
parkNanos
禁用當(dāng)前線(xiàn)程的線(xiàn)程調(diào)度意圖,直到指定的等待時(shí)間,除非許可可用。如果參數(shù) nanos
為 0 或?yàn)樨?fù)數(shù),這個(gè)方法將不會(huì)做任何事情。
parkUntil
禁用當(dāng)前線(xiàn)程的線(xiàn)程調(diào)度意圖,直到指定的最后期限,除非許可可用。參數(shù) deadline
是截止日期——從 Epoch 開(kāi)始等待的絕對(duì)時(shí)間,以毫秒為單位。
需要 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ù),它們和對(duì)應(yīng)的不帶參數(shù)的方法意義是一樣的,多了一個(gè)設(shè)置對(duì)象的操作。而這個(gè)對(duì)象 blocker
是負(fù)責(zé)此線(xiàn)程 parking 的同步對(duì)象 。
這組重載方法有共同的邏輯:
- 獲取當(dāng)前線(xiàn)程對(duì)象。
- 將
blocker
對(duì)象的引用值存儲(chǔ)到線(xiàn)程對(duì)象中。 - 調(diào)用 Unsafe 對(duì)象的
park(boolean, long)
方法。 - 將當(dāng)前線(xiàn)程對(duì)象存儲(chǔ)的引用值設(shè)置為 null 。
讓我困惑的是,這個(gè)存儲(chǔ)引用值操作有什么作用。但是聯(lián)想到線(xiàn)程操作和對(duì)象,驚奇的發(fā)現(xiàn)我們常用的 API Object.wait()
和 Object.notify()
,好像和這個(gè)場(chǎng)景很像,都用到了一個(gè) Object
,也都造成了線(xiàn)程阻塞喚醒。
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(); ? } }
這是一個(gè)簡(jiǎn)單的 Demo ,創(chuàng)建了兩個(gè)線(xiàn)程 thread1
和 thread2
。
線(xiàn)程 2 從主線(xiàn)程先執(zhí)行,持有了 obj
對(duì)象的鎖,在它的執(zhí)行邏輯中:
- 先啟動(dòng)線(xiàn)程 1
- 線(xiàn)程 2 睡眠 3 秒
- 三秒后打印 start,obj 對(duì)象調(diào)用 wait ,使當(dāng)前線(xiàn)程讓出對(duì)象的鎖,并進(jìn)入阻塞狀態(tài)。
此時(shí),線(xiàn)程 1 可以獲取到 obj 對(duì)象的鎖了,它的執(zhí)行邏輯:
- 線(xiàn)程 1 開(kāi)始打印 start
- 睡眠 1 秒
- obj 對(duì)象調(diào)用 notify ,線(xiàn)程 2 開(kāi)始嘗試獲取 obj 的鎖。
- 打印 end ,執(zhí)行結(jié)束,讓出 obj 的鎖
最后,線(xiàn)程 2 重新獲取到了 obj 的鎖,繼續(xù)執(zhí)行打印 end 。
從打印日志中,驗(yàn)證打印順序:
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實(shí)現(xiàn)同步時(shí),必須先調(diào)用wait,后調(diào)用notify,如果先調(diào)用notify,再調(diào)用wait,會(huì)導(dǎo)致線(xiàn)程一直阻塞。
而如果使用 park / unpark 實(shí)現(xiàn)一個(gè)阻塞喚醒效果:
? ?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()
方法中,先啟動(dòng)了線(xiàn)程 2,線(xiàn)程 2 打印完 start 后就啟動(dòng)了線(xiàn)程 1 。而此時(shí)線(xiàn)程 2 繼續(xù)執(zhí)行:
- 調(diào)用 park 進(jìn)入阻塞狀態(tài)
在線(xiàn)程 2 執(zhí)行上面兩個(gè)邏輯的同時(shí),線(xiàn)程 1 也在同時(shí)執(zhí)行:
- 線(xiàn)程 1 啟動(dòng)后先打印 start
- 線(xiàn)程 1 睡眠 3 秒
- 檢查線(xiàn)程 2 調(diào)用
park(Object)
方法設(shè)置的 Blocker 信息 - 調(diào)用
LockSupport.unpark(thread2)
解除線(xiàn)程 2 的阻塞 - 線(xiàn)程 1 打印 end 執(zhí)行結(jié)束
線(xiàn)程 2 在被線(xiàn)程 1 喚醒后,繼續(xù)執(zhí)行打印信息:
- 打印當(dāng)前線(xiàn)程的 Blocker 信息,為 null
- 打印 end 執(zhí)行結(jié)束
打印日志:
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 也不會(huì)導(dǎo)致阻塞,更加靈活。
可以發(fā)現(xiàn),blocker
在線(xiàn)程恢復(fù)后變成了 null ,個(gè)人理解它的作用就是用來(lái)做阻塞標(biāo)記的,可以用來(lái)在線(xiàn)程阻塞狀態(tài)下,將一個(gè)對(duì)象設(shè)置上,然后在其他線(xiàn)程中讀取這個(gè)對(duì)象。blocker
與線(xiàn)程的單次阻塞狀態(tài)綁定,可以用于對(duì)線(xiàn)程狀態(tài)的排查和線(xiàn)程狀態(tài)的監(jiān)控。
區(qū)別
從 wait/notify 和 park/unpark 兩種阻塞線(xiàn)程和喚起線(xiàn)程的方式,能夠感受出兩者的不同之處:
- wait/notify 需要配合 synchronized 進(jìn)行;park/unpark 雖然設(shè)置了 blocker 但全程沒(méi)有鎖。
- wait/notify 需要保證 wait 在前,notify 在后,否則會(huì)阻塞線(xiàn)程;park/unpark 對(duì)調(diào)用順序沒(méi)有限制。不會(huì)造成阻塞。
- wait/notify 方法在 Object 中定義,用于對(duì)象鎖的資源讓出;park/unpark 來(lái)自于
LockSupport
,是靜態(tài)方法,用于對(duì)線(xiàn)程本身進(jìn)行掛起喚醒。并可以通過(guò)blocker
綁定線(xiàn)程阻塞狀態(tài)下的一些信息。
個(gè)人感覺(jué) park/unpark 更像是 掛起/恢復(fù),而 Thread.suspend
和 Thread.resume
都已廢棄,是很好的替代方案。
suspend
,掛起線(xiàn)程,但是不會(huì)釋放類(lèi)似鎖這樣的資源。resume
,恢復(fù)線(xiàn)程,如果之前沒(méi)有使用suspend暫停線(xiàn)程,則不起作用。Thread.stop()
由于其固有的風(fēng)險(xiǎn)而被逐步淘汰。當(dāng)你停止一個(gè)線(xiàn)程時(shí),它會(huì)解鎖它鎖定的所有監(jiān)視器。如果以前受這些監(jiān)視器保護(hù)的任何對(duì)象處于不一致?tīng)顟B(tài),其他線(xiàn)程可能會(huì)看到這些對(duì)象處于不一致?tīng)顟B(tài)。 作用在受損物體上的線(xiàn)可能會(huì)有意或無(wú)意地行為不規(guī)律。與其他不受控制的異常不同,ThreadDeath 會(huì)靜默地殺死線(xiàn)程,不會(huì)向用戶(hù)發(fā)出程序可能已損壞的警告。損壞發(fā)生后,損壞可能會(huì)在無(wú)法預(yù)料的時(shí)刻出現(xiàn)。此外,在多線(xiàn)程環(huán)境中使用 DBMS – JDBC 時(shí),終止線(xiàn)程會(huì)產(chǎn)生問(wèn)題。Thread.suspend()
已被棄用,因?yàn)樗举|(zhì)上容易死鎖。因此,Thread.resume()
也必須被棄用。當(dāng)目標(biāo)線(xiàn)程被掛起時(shí),它會(huì)在監(jiān)視器上鎖定一個(gè)保護(hù)關(guān)鍵系統(tǒng)資源的鎖,并且在目標(biāo)線(xiàn)程恢復(fù)之前沒(méi)有其他線(xiàn)程可以訪(fǎng)問(wèn)它。如果將重新啟動(dòng)目標(biāo)線(xiàn)程的線(xiàn)程在調(diào)用 resume() 之前嘗試鎖定此監(jiān)視器,則會(huì)發(fā)生死鎖。
到此這篇關(guān)于Java 多線(xiàn)程并發(fā)LockSupport的文章就介紹到這了,更多相關(guān)Java LockSupport內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
- Java?多線(xiàn)程并發(fā)編程提高數(shù)據(jù)處理效率的詳細(xì)過(guò)程
- 理解Java多線(xiàn)程之并發(fā)編程
- Java并發(fā)編程多線(xiàn)程間的同步控制和通信詳解
- Java多線(xiàn)程并發(fā)FutureTask使用詳解
- Java?多線(xiàn)程并發(fā)?ReentrantReadWriteLock詳情
- Java?多線(xiàn)程并發(fā)ReentrantLock
- Java 多線(xiàn)程并發(fā)AbstractQueuedSynchronizer詳情
- Java多線(xiàn)程并發(fā)synchronized?關(guān)鍵字
- Java多線(xiàn)程編程中的并發(fā)安全問(wèn)題及解決方法
相關(guān)文章
javaweb如何實(shí)現(xiàn)請(qǐng)求和響應(yīng)
這篇文章主要為大家詳細(xì)介紹了javaweb如何實(shí)現(xiàn)請(qǐng)求和響應(yīng),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2016-10-10解決swaggerUI頁(yè)面沒(méi)有顯示Controller方法的坑
這篇文章主要介紹了解決swaggerUI頁(yè)面沒(méi)有顯示Controller方法的坑,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2021-06-06Spring中DAO被循環(huán)調(diào)用的時(shí)候數(shù)據(jù)不實(shí)時(shí)更新的解決方法
這篇文章主要介紹了Spring中DAO被循環(huán)調(diào)用的時(shí)候數(shù)據(jù)不實(shí)時(shí)更新的解決方法,需要的朋友可以參考下2014-08-08SpringBoot實(shí)現(xiàn)文件下載的四種方式
本文主要介紹了SpringBoot實(shí)現(xiàn)文件下載的四種方式,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2023-11-11淺談Java中GuavaCache返回Null的注意事項(xiàng)
Guava在實(shí)際的Java后端項(xiàng)目中應(yīng)用的場(chǎng)景還是比較多的,比如限流,緩存,容器操作之類(lèi)的,本文主要介紹了GuavaCache返回Null的注意事項(xiàng),感興趣的可以了解一下2021-10-10Java的Junit測(cè)試框架中的其他注解說(shuō)明
這篇文章主要介紹了Java的Junit測(cè)試框架中的其他注解說(shuō)明,JUnit是一個(gè)開(kāi)源的java單元測(cè)試框架,它是XUnit測(cè)試體系架架構(gòu)的一種體現(xiàn),2023-10-10
是Java語(yǔ)言事實(shí)上的標(biāo)準(zhǔn)單元測(cè)試庫(kù),需要的朋友可以參考下SpringCloud Hystrix-Dashboard儀表盤(pán)的實(shí)現(xiàn)
這篇文章主要介紹了SpringCloud Hystrix-Dashboard儀表盤(pán)的實(shí)現(xiàn),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2019-08-08Java調(diào)用dll文件的實(shí)現(xiàn)解析
這篇文章主要介紹了Java調(diào)用dll文件的實(shí)現(xiàn)解析,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-02-02關(guān)于ZooKeeper的會(huì)話(huà)機(jī)制Session解讀
這篇文章主要介紹了關(guān)于ZooKeeper的會(huì)話(huà)機(jī)制Session解讀,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-02-02