當前位置：首頁 > 编程语言 > java >内容正文

java

Java 线程状态---WAITING（部分转载）

發布時間：2024/7/23 java 33 豆豆

生活随笔收集整理的這篇文章主要介紹了 Java 线程状态---WAITING（部分转载）小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

看到一篇關于寫線程waiting狀態的文章，感覺很生動有趣，轉過來保存下。

總結：

waiting這個狀態，就是等待，明確了等待，就不會搶資源了。

一個線程A在拿到鎖但不滿足執行條件的時候，需要另一個線程B去滿足這個條件，
那么線程A就會釋放鎖并處于waiting的狀態，等線程B執行完再執行。
waiting狀態的好處是：此狀態的線程不再活動，不再參與調度，因此不會浪費 CPU 資源，也不會去競爭鎖了，相比暴力的blocking狀態，要優雅很多。

進入waiting的方法：

調用wait方法，就能讓線程進入waiting狀態，notify/notify能讓線程結束waiting狀態。
join也能讓線程進入waiting狀態，但也算是特殊的wait

還有個Time_waiting的狀態

就是wait方法加了個時間的入參，代表等多久就不等了，避免永遠等下去。

blocking和waiting

blocking狀態，硬說也算waiting的特殊情況
如果waiting狀態的條件是有沒有鎖，那就可以勉強理解為blocking狀態吧。
blocking是線程被動阻塞，waiting是線程主動阻塞，本質上其實是一樣的。

下文這個火車上搶廁所的例子，很形象。

以下是轉載正文（末尾附原文鏈接）：

定義

一個正在無限期等待另一個線程執行一個特別的動作的線程處于這一狀態。

A thread that is waiting indefinitely for another thread to perform a particular action is in this state.

然而這里并沒有詳細說明這個“特別的動作”到底是什么，詳細定義還是看 javadoc（jdk8）：

一個線程進入 WAITING 狀態是因為調用了以下方法：

不帶時限的 Object.wait 方法
不帶時限的 Thread.join 方法
LockSupport.park

然后會等其它線程執行一個特別的動作，比如：

一個調用了某個對象的 Object.wait 方法的線程會等待另一個線程調用此對象的 Object.notify() 或 Object.notifyAll()。
一個調用了 Thread.join 方法的線程會等待指定的線程結束。
?

對應的英文原文如下：

A thread is in the waiting state due to calling one of the following methods:

Object.wait with no timeout
Thread.join with no timeout
LockSupport.park

A thread in the waiting state is waiting for another thread to perform a particular action. For example, a thread that has called Object.wait() on an object is waiting for another thread to call Object.notify() or Object.notifyAll() on that object. A thread that has called Thread.join() is waiting for a specified thread to terminate.

線程間的協作（cooperate）機制

顯然，WAITING 狀態所涉及的不是一個線程的獨角戲，相反，它涉及多個線程，具體地講，這是多個線程間的一種協作機制。談到線程我們經常想到的是線程間的競爭（race），比如去爭奪鎖，但這并不是故事的全部，線程間也會有協作機制。

就好比在公司里你和你的同事們，你們可能存在在晉升時的競爭，但更多時候你們更多是一起合作以完成某些任務。

wait/notify 就是線程間的一種協作機制，那么首先，為什么 wait？什么時候 wait？它為什么要等其它線程執行“特別的動作”？它到底解決了什么問題？

wait 的場景

首先，為什么要 wait 呢？簡單講，是因為條件（condition）不滿足。那么什么是條件呢？為方便理解，我們設想一個場景：

有一節列車車廂，有很多乘客，每個乘客相當于一個線程；里面有個廁所，這是一個公共資源，且一次只允許一個線程進去訪問（畢竟沒人希望在上廁所期間還與他人共享~）。

競爭關系

假如有多個乘客想同時上廁所，那么這里首先存在的是競爭的關系。

如果將廁所視為一個對象，它有一把鎖，想上廁所的乘客線程需要先獲取到鎖，然后才能進入廁所。

Java 在語言級直接提供了同步的機制，也即是 synchronized 關鍵字：

synchronized(expression) {……}

它的機制是這樣的：對表達式（expresssion）求值（值的類型須是引用類型（reference type）），獲取它所代表的對象，然后嘗試獲取這個對象的鎖：

如果能獲取鎖，則進入同步塊執行，執行完后退出同步塊，并歸還對象的鎖（異常退出也會歸還）；
如果不能獲取鎖，則阻塞在這里，直到能夠獲取鎖。

在一個線程還在廁所期間，其它同時想上廁所的線程被阻塞，處在該廁所對象的 entry set 中，處于 BLOCKED 狀態。

完事之后，退出廁所，歸還鎖。

之后，系統再在 entry set 中挑選一個線程，將鎖給到它。

對于以上過程，以下為一個 gif 動圖演示：

當然，這就是我們所熟悉的鎖的競爭過程。以下為演示的代碼：

@Test public void testBlockedState() throws Exception {class Toilet { // 廁所類public void pee() { // 尿尿方法try {Thread.sleep(21000);// 研究表明，動物無論大小尿尿時間都在21秒左右} catch (InterruptedException e) {Thread.currentThread().interrupt();}}} Toilet toilet = new Toilet();Thread passenger1 = new Thread(new Runnable() {public void run() {synchronized (toilet) {toilet.pee();}} });Thread passenger2 = new Thread(new Runnable() {public void run() {synchronized (toilet) {toilet.pee();}} });passenger1.start();// 確保乘客1先啟動 Thread.sleep(100);passenger2.start();// 確保已經執行了 run 方法 Thread.sleep(100);// 在乘客1在廁所期間，乘客2處于 BLOCKED 狀態 assertThat(passenger2.getState()).isEqualTo(Thread.State.BLOCKED);

}

條件

現在，假設有個女乘客，她搶到了鎖，進去之后褲子脫了一半，發現馬桶的墊圈紙沒了，于是拒絕尿。

或許是因為她比較講究衛生，怕直接坐上去會弄臟她白花花的屁股~

現在，條件出現了：有紙沒紙，這就是某種條件。

那么，現在條件不滿足，這位女線程改怎么辦呢？如果只是在里面干等，顯然是不行的。

這不就是人民群眾所深惡痛絕的“占著茅坑不拉尿”嗎？

一方面，外面 entry set 中可能好多群眾還嗷嗷待尿呢（其中可能有很多大老爺線程，他們才不在乎有沒有馬桶墊圈紙~）
另一方面，假定外面同時有“乘務員線程”，準備進去增加墊圈紙，可你在里面霸占著不出來，別人也沒法進去，也就沒法加紙。

所以，當條件不滿足時，需要出來，要把鎖還回去，以使得諸如“乘務員線程”的能進去增加紙張。

等待是必要的嗎？

那么出來之后是否一定需要等待呢？當然也未必。

這里所謂“等待”，指的是使線程處于不再活動的狀態，即是從調度隊列中剔除。

如果不等待，只是簡單歸還鎖，用一個反復的循環來判斷條件是否滿足，那么還是可以再次回到調度隊列，然后期待在下一次被調度到的時候，可能條件已經發生變化：

比如某個“乘務員線程”已經在之前被調度并增加了里面的墊圈紙。自然，也可能再次調度到的時候，條件依舊是不滿足的。

現在讓我們考慮一種比較極端的情況：廁所外一大堆的“女乘客線程”想進去方便，同時還有一個焦急的“乘務員線程”想進去增加廁紙。

如果線程都不等待，而廁所又是一個公共資源，無法并發訪問。調度器每次挑一個線程進去，挑中“乘務員線程”的幾率反而降低了，entry set 中很可能越聚越多無法完成方便的“女乘客線程”，“乘務員線程”被選中執行的幾率越發下降。

當然，同步機制會防止產生所謂的“饑餓（starvation）”現象，“乘務員線程”最終還是有機會執行的，只是系統運行的效率下降了。

所以，這會干擾正常工作的線程，擠占了資源，反而影響了自身條件的滿足。另外，“乘務員線程”可能這段時間根本沒有啟動，此時，不愿等待的“女乘客線程”不過是徒勞地進進出出，占用了 CPU 資源卻沒有辦成正事。

效果上還是在這種沒有進展的進進出出中等待，這種情形類似于所謂的忙等待（busy waiting）。

協作關系

綜上，等待還是有必要的，我們需要一種更高效的機制，也即是 wait/notify 的協作機制。

當條件不滿足時，應該調用 wait()方法，這時線程釋放鎖，并進入所謂的 wait set 中，具體的講，是進入這個廁所對象的 wait set 中：

這時，線程不再活動，不再參與調度，因此不會浪費 CPU 資源，也不會去競爭鎖了，這時的線程狀態即是 WAITING。

現在的問題是：她們什么時候才能再次活動呢？顯然，最佳的時機是當條件滿足的時候。

之后，“乘務員線程”進去增加廁紙，當然，此時，它也不能只是簡單加完廁紙就完了，它還要執行一個特別的動作，也即是“通知（notify）”在這個對象上等待的女乘客線程：

大概就是向她們喊一聲：“有紙啦！趕緊去尿吧！”顯然，如果只是“女乘客線程”方面一廂情愿地等待，她們將沒有機會再執行。

所謂“通知”，也即是把她們從 wait set 中釋放出來，重新進入到調度隊列（ready queue）中。

如果是 notify，則選取所通知對象的 wait set 中的一個線程釋放；
如果是 notifyAll，則釋放所通知對象的 wait set 上的全部線程。

整個過程如下圖所示：

對于上述過程，我們也給出以下 gif 動圖演示：

注意：哪怕只通知了一個等待的線程，被通知線程也不能立即恢復執行，因為她當初中斷的地方是在同步塊內，而此刻她已經不持有鎖，所以她需要再次嘗試去獲取鎖（很可能面臨其它線程的競爭），成功后才能在當初調用 wait 方法之后的地方恢復執行。（這也即是所謂的 “reenter after calling Object.wait”，在上一個篇章中也曾詳細的討論了這一過程。）

如果能獲取鎖，線程就從 WAITING 狀態變成 RUNNABLE 狀態；
否則，從 wait set 出來，又進入 entry set，線程就從 WAITING 狀態又變成 BLOCKED 狀態。

綜上，這是一個協作機制，“女乘客線程”和“乘務員線程”間存在一個協作關系。顯然，這種協作關系的存在，“女乘客線程”可以避免在條件不滿足時的盲目嘗試，也為“乘務員線程”的順利執行騰出了資源；同時，在條件滿足時，又能及時得到通知。協作關系的存在使得彼此都能受益。

生產者與消費者問題

不難發現，以上實質上也就是經典的“生產者與消費者”的問題：

乘務員線程生產廁紙，女乘客線程消費廁紙。當廁紙沒有時（條件不滿足），女乘客線程等待，乘務員線程添加廁紙（使條件滿足），并通知女乘客線程（解除她們的等待狀態）。接下來，女乘客線程能否進一步執行則取決于鎖的獲取情況。

代碼的演示：

在以下代碼中，演示了上述的 wait/notify 的過程：

@Test public void testWaitingState() throws Exception { class Toilet { // 廁所類int paperCount = 0; // 紙張public void pee() { // 尿尿方法try {Thread.sleep(21000);// 研究表明，動物無論大小尿尿時間都在21秒左右} catch (InterruptedException e) {Thread.currentThread().interrupt();}} }Toilet toilet = new Toilet();// 兩乘客線程 Thread[] passengers = new Thread[2]; for (int i = 0; i < passengers.length; i++) {passengers[i] = new Thread(new Runnable() {public void run() {synchronized (toilet) {while (toilet.paperCount < 1) {try {toilet.wait(); // 條件不滿足，等待} catch (InterruptedException e) {Thread.currentThread().interrupt();}}toilet.paperCount--; // 使用一張紙toilet.pee();}}}); }// 乘務員線程 Thread steward = new Thread(new Runnable() {public void run() {synchronized (toilet) {toilet.paperCount += 10;// 增加十張紙toilet.notifyAll();// 通知所有在此對象上等待的線程}} });passengers[0].start(); passengers[1].start();// 確保已經執行了 run 方法 Thread.sleep(100);// 沒有紙，兩線程均進入等待狀態 assertThat(passengers[0].getState()).isEqualTo(Thread.State.WAITING); assertThat(passengers[1].getState()).isEqualTo(Thread.State.WAITING);// 乘務員線程啟動，救星來了 steward.start();// 確保已經增加紙張并已通知 Thread.sleep(100);// 其中之一會得到鎖，并執行 pee，但無法確定是哪個，所以用 "或 ||" // 注：因為 pee 方法中實際調用是 sleep，所以很快就從 RUNNABLE 轉入 TIMED_WAITING(sleep 時對應的狀態) assertTrue(Thread.State.TIMED_WAITING.equals(passengers[0].getState())|| Thread.State.TIMED_WAITING.equals(passengers[1].getState()));// 其中之一則被阻塞，但無法確定是哪個，所以用 "或 ||" assertTrue(Thread.State.BLOCKED.equals(passengers[0].getState()) || Thread.State.BLOCKED.equals(passengers[1].getState()));

}

join 的場景及其它

從定義中可知，除了 wait/notify 外，調用 join 方法也會讓線程處于 WAITING 狀態。

join 的機制中并沒有顯式的 wait/notify 的調用，但可以視作是一種特殊的，隱式的 wait/notify 機制。

假如有 a，b 兩個線程，在 a 線程中執行 b.join()，相當于讓 a 去等待 b，此時 a 停止執行，等 b 執行完了，系統內部會隱式地通知 a，使 a 解除等待狀態，恢復執行。

換言之，a 等待的條件是 “b 執行完畢”，b 完成后，系統會自動通知 a。

關于 LockSupport.park 的情況則由讀者自行分析。

與傳統 waiting 狀態的關系

Thread.State.WAITING 狀態與傳統的 waiting 狀態類似：

本文后面部分轉載自：https://my.oschina.net/goldenshaw/blog/802620

如有侵權，請告知刪除

總結

以上是生活随笔為你收集整理的Java 线程状态---WAITING（部分转载）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：通过终端，查看sqlite3的存储文件
下一篇： JAVA table word,实战 |