Java中notify是順序喚醒還是隨機(jī)喚醒的
前言:
做 Java 開發(fā)的小伙伴,對(duì) wait 方法和 notify 方法應(yīng)該都比較熟悉,這兩個(gè)方法在線程通訊中使用的頻率非常高,但對(duì)于 notify 方法的喚醒順序,有很多小伙伴的理解都是錯(cuò)誤的,有很多人會(huì)認(rèn)為 notify 是隨機(jī)喚醒的,但它真的是隨機(jī)喚醒的嗎?
帶著這個(gè)疑問,我們嘗試休眠 100 個(gè)線程,再喚醒 100 個(gè)線程,并把線程休眠和喚醒的順序保持到兩個(gè)集合中,最后再打印一下這兩個(gè)集合,看一下它們的執(zhí)行順序,如果它們的順序是一致的,那說明 notify 是順序喚醒的,否則則是隨機(jī)喚醒的,
notify 測試代碼如下:
import java.util.ArrayList;
import java.util.List;
public class NotifyExample {
// 保存休眠線程的順序
private static List<String> waitList = new ArrayList<>();
// 保存喚醒線程的順序
private static List<String> notifyList = new ArrayList<>();
public static void main(String[] args) throws InterruptedException {
final Object lock = new Object();
// 休眠 100 個(gè)線程
for (int i = 0; i < 100; i++) {
String threadName = Integer.toString(i); // 定義線程名
new Thread(() -> {
// 獲取當(dāng)前執(zhí)行線程的線程名
String currThreadName = Thread.currentThread().getName();
synchronized (lock) {
waitList.add(currThreadName); // 存入等待 list
try {
lock.wait(); // 休眠線程
} catch (InterruptedException e) {
e.printStackTrace();
}
notifyList.add(currThreadName); // 存儲(chǔ)喚醒 list
}
}, threadName).start();
}
Thread.sleep(1000);
// 喚醒 100 個(gè)線程
for (int i = 0; i < 100; i++) {
synchronized (lock) {
lock.notify(); // 喚醒線程
}
}
// 打印 2 個(gè)線程列表
System.out.println("等待線程順序:" + waitList);
System.out.println("喚醒線程順序:" + waitList);
}
}以上程序的執(zhí)行結(jié)果如下圖所示:

從上述打印的結(jié)果我們可以看出,使用 notify 并不是隨機(jī)喚醒的,而是順序喚醒的,雖然以上代碼能證明這個(gè)結(jié)論,但為了更清楚的解釋這個(gè)問題,我們查看了 notify 的實(shí)現(xiàn)源碼,
它的源碼內(nèi)容如下:

簡單翻譯一下上面的重點(diǎn)內(nèi)容,notify 選擇喚醒的線程是任意的,但具體的實(shí)現(xiàn)還要依賴于 JVM。也就是說 notify 的喚醒規(guī)則,最終取決于 JVM 廠商,不同的廠商的實(shí)現(xiàn)可能是不同的,比如阿里的 JVM 和 Oracle 的 JVM,關(guān)于 notify 的喚醒規(guī)則可能是不一樣的。
那作為一個(gè)普通的程序員我們要研究的就是官方的 JVM 也就是 HotSpot 虛擬機(jī),它的 notify 實(shí)現(xiàn)源碼在 ObjectMonitor.cpp 中,
具體源碼如下:

DequeueWaiter 方法實(shí)現(xiàn)的源碼如下:

從上述源碼可以看出,在進(jìn)行喚醒時(shí),每次會(huì)從 _WaitSet 等待集合中獲取第一個(gè)元素進(jìn)行出隊(duì)操作,這也說明了 notify 是順序喚醒的。
總結(jié):
notify 喚醒線程的規(guī)則是隨機(jī)喚醒還是順序喚醒取決于 JVM 的具體實(shí)現(xiàn),作為主流的 HotSpot 虛擬機(jī)中的 notify 的喚醒規(guī)則是順序的,也就是 notify 會(huì)按照線程的休眠順序,依次喚醒線程。
到此這篇關(guān)于Java中notify是順序喚醒還是隨機(jī)喚醒的的文章就介紹到這了,更多相關(guān)Java notify喚醒規(guī)則內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
MyBatisPlus3.4.3版自動(dòng)生成代碼的使用過程
這篇文章主要介紹了MyBatisPlus3.4.3版自動(dòng)生成代碼的使用,本文通過實(shí)例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2023-04-04
Mybatis?Mapper中多參數(shù)方法不使用@param注解報(bào)錯(cuò)的解決
這篇文章主要介紹了Mybatis?Mapper中多參數(shù)方法不使用@param注解報(bào)錯(cuò)的解決方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教。2022-01-01
Spring Boot3.x自動(dòng)配置不生效的排查與解決方法(IDEA 文件夾命名導(dǎo)致的問題)
在SpringBoot多模塊項(xiàng)目中,自動(dòng)配置類未生效的問題通常源于文件路徑錯(cuò)誤,通過檢查和修正AutoConfiguration.imports文件的實(shí)際路徑,可以解決自動(dòng)配置不生效的問題,感興趣的朋友跟隨小編一起看看吧2024-11-11
springboot對(duì)接微信支付的完整流程(附前后端代碼)
最近在做支付平臺(tái)的項(xiàng)目,承接公司業(yè)務(wù)系統(tǒng)與第三方支付平臺(tái)的對(duì)接任務(wù),主要涉及微信支付、支付寶支付以及理房通支付等第三方平臺(tái),這篇文章主要給大家介紹了關(guān)于springboot對(duì)接微信支付的完整流程,需要的朋友可以參考下2021-08-08
spring boot配合前端實(shí)現(xiàn)跨域請(qǐng)求訪問
本篇文章主要介紹了spring boot配合前端實(shí)現(xiàn)跨域請(qǐng)求訪問,小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2017-04-04
java解析xml的4種方式的優(yōu)缺點(diǎn)對(duì)比及實(shí)現(xiàn)詳解
這篇文章主要介紹了java解析xml的4種方式的優(yōu)缺點(diǎn)對(duì)比及實(shí)現(xiàn)詳解,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2019-07-07

