轉(zhuǎn)載自?面試官問(wèn)：為什么 Java 線程沒(méi)有 Running 狀態(tài)？我懵了

• 什么是 RUNNABLE？

• 與傳統(tǒng)的ready狀態(tài)的區(qū)別

• 與傳統(tǒng)的running狀態(tài)的區(qū)別

• 當(dāng)I/O阻塞時(shí)

• 如何看待RUNNABLE狀態(tài)？

---

Java虛擬機(jī)層面所暴露給我們的狀態(tài)，與操作系統(tǒng)底層的線程狀態(tài)是兩個(gè)不同層面的事。具體而言，這里說(shuō)的 Java 線程狀態(tài)均來(lái)自于 Thread 類(lèi)下的 State 這一內(nèi)部枚舉類(lèi)中所定義的狀態(tài)：

什么是 RUNNABLE？

直接看它的 Javadoc 中的說(shuō)明：

一個(gè)在 JVM 中執(zhí)行的線程處于這一狀態(tài)中。（A thread?executing?in the Java virtual machine is in this state.）

而傳統(tǒng)的進(jìn)（線）程狀態(tài)一般劃分如下：

注：這里的進(jìn)程指早期的單線程進(jìn)程，這里所謂進(jìn)程狀態(tài)實(shí)質(zhì)就是線程狀態(tài)。

那么 runnable 與圖中的 ready 與 running 區(qū)別在哪呢？

與傳統(tǒng)的ready狀態(tài)的區(qū)別

更具體點(diǎn)，javadoc 中是這樣說(shuō)的：

處于 runnable 狀態(tài)下的線程正在 Java 虛擬機(jī)中執(zhí)行，但它可能正在等待來(lái)自于操作系統(tǒng)的其它資源，比如處理器。

A thread in the runnable state is executing in the Java virtual machine but?it may be waiting forother resources from the operating system such as processor.

顯然，runnable 狀態(tài)實(shí)質(zhì)上是包括了 ready 狀態(tài)的。

甚至還可能有包括上圖中的 waiting 狀態(tài)的部分細(xì)分狀態(tài)，在后面我們將會(huì)看到這一點(diǎn)。

與傳統(tǒng)的running狀態(tài)的區(qū)別

有人常覺(jué)得 Java 線程狀態(tài)中還少了個(gè) running 狀態(tài)，這其實(shí)是把兩個(gè)不同層面的狀態(tài)混淆了。對(duì) Java 線程狀態(tài)而言，不存在所謂的running 狀態(tài)，它的 runnable 狀態(tài)包含了 running 狀態(tài)。

我們可能會(huì)問(wèn)，為何 JVM 中沒(méi)有去區(qū)分這兩種狀態(tài)呢？

現(xiàn)在的時(shí)分（time-sharing）多任務(wù)（multi-task）操作系統(tǒng)架構(gòu)通常都是用所謂的“時(shí)間分片（time quantum or time slice）”方式進(jìn)行搶占式（preemptive）輪轉(zhuǎn)調(diào)度（round-robin式）。

更復(fù)雜的可能還會(huì)加入優(yōu)先級(jí)（priority）的機(jī)制。

這個(gè)時(shí)間分片通常是很小的，一個(gè)線程一次最多只能在 cpu 上運(yùn)行比如10-20ms 的時(shí)間（此時(shí)處于 running 狀態(tài)），也即大概只有0.01秒這一量級(jí)，時(shí)間片用后就要被切換下來(lái)放入調(diào)度隊(duì)列的末尾等待再次調(diào)度。（也即回到 ready 狀態(tài)）

注：如果期間進(jìn)行了 I/O 的操作還會(huì)導(dǎo)致提前釋放時(shí)間分片，并進(jìn)入等待隊(duì)列。

又或者是時(shí)間分片沒(méi)有用完就被搶占，這時(shí)也是回到 ready 狀態(tài)。

這一切換的過(guò)程稱(chēng)為線程的上下文切換（context switch），當(dāng)然 cpu 不是簡(jiǎn)單地把線程踢開(kāi)就完了，還需要把被相應(yīng)的執(zhí)行狀態(tài)保存到內(nèi)存中以便后續(xù)的恢復(fù)執(zhí)行。

顯然，10-20ms 對(duì)人而言是很快的，

不計(jì)切換開(kāi)銷(xiāo)（每次在1ms 以?xún)?nèi)），相當(dāng)于1秒內(nèi)有50-100次切換。事實(shí)上時(shí)間片經(jīng)常沒(méi)用完，線程就因?yàn)楦鞣N原因被中斷，實(shí)際發(fā)生的切換次數(shù)還會(huì)更多。

也這正是單核 *CPU 上實(shí)現(xiàn)所謂的“并發(fā)*（concurrent）”的基本原理，但其實(shí)是快速切換所帶來(lái)的假象，這有點(diǎn)類(lèi)似一個(gè)手腳非常快的雜耍演員可以讓好多個(gè)球同時(shí)在空中運(yùn)轉(zhuǎn)那般。

時(shí)間分片也是可配置的，如果不追求在多個(gè)線程間很快的響應(yīng)，也可以把這個(gè)時(shí)間配置得大一點(diǎn)，以減少切換帶來(lái)的開(kāi)銷(xiāo)。

如果是多核CPU，才有可能實(shí)現(xiàn)真正意義上的并發(fā)，這種情況通常也叫并行（pararell），不過(guò)你可能也會(huì)看到這兩詞會(huì)被混著用，這里就不去糾結(jié)它們的區(qū)別了。

通常，Java的線程狀態(tài)是服務(wù)于監(jiān)控的，如果線程切換得是如此之快，那么區(qū)分 ready 與 running 就沒(méi)什么太大意義了。

當(dāng)你看到監(jiān)控上顯示是 running 時(shí)，對(duì)應(yīng)的線程可能早就被切換下去了，甚至又再次地切換了上來(lái)，也許你只能看到 ready 與 running 兩個(gè)狀態(tài)在快速地閃爍。

當(dāng)然，對(duì)于精確的性能評(píng)估而言，獲得準(zhǔn)確的 running 時(shí)間是有必要的。

現(xiàn)今主流的 JVM 實(shí)現(xiàn)都把 Java 線程一一映射到操作系統(tǒng)底層的線程上，把調(diào)度委托給了操作系統(tǒng)，我們?cè)谔摂M機(jī)層面看到的狀態(tài)實(shí)質(zhì)是對(duì)底層狀態(tài)的映射及包裝。JVM 本身沒(méi)有做什么實(shí)質(zhì)的調(diào)度，把底層的 ready 及 running 狀態(tài)映射上來(lái)也沒(méi)多大意義，因此，統(tǒng)一成為runnable 狀態(tài)是不錯(cuò)的選擇。

我們將看到，Java 線程狀態(tài)的改變通常只與自身顯式引入的機(jī)制有關(guān)。

當(dāng)I/O阻塞時(shí)

我們知道傳統(tǒng)的I/O都是阻塞式（blocked）的，原因是I/O操作比起cpu來(lái)實(shí)在是太慢了，可能差到好幾個(gè)數(shù)量級(jí)都說(shuō)不定。如果讓 cpu 去等I/O 的操作，很可能時(shí)間片都用完了，I/O 操作還沒(méi)完成呢，不管怎樣，它會(huì)導(dǎo)致 cpu 的利用率極低。

所以，解決辦法就是：一旦線程中執(zhí)行到 I/O 有關(guān)的代碼，相應(yīng)線程立馬被切走，然后調(diào)度 ready 隊(duì)列中另一個(gè)線程來(lái)運(yùn)行。

這時(shí)執(zhí)行了 I/O 的線程就不再運(yùn)行，即所謂的被阻塞了。它也不會(huì)被放到調(diào)度隊(duì)列中去，因?yàn)楹芸赡茉俅握{(diào)度到它時(shí)，I/O 可能仍沒(méi)有完成。

線程會(huì)被放到所謂的等待隊(duì)列中，處于上圖中的 waiting 狀態(tài)：

當(dāng)然了，我們所謂阻塞只是指這段時(shí)間 cpu 暫時(shí)不會(huì)理它了，但另一個(gè)部件比如硬盤(pán)則在努力地為它服務(wù)。cpu 與硬盤(pán)間是并發(fā)的。如果把線程視作為一個(gè) job，這一 job 由 cpu 與硬盤(pán)交替協(xié)作完成，當(dāng)在 cpu 上是 waiting 時(shí)，在硬盤(pán)上卻處于 running，只是我們?cè)诓僮飨到y(tǒng)層面討論線程狀態(tài)時(shí)通常是圍繞著 cpu 這一中心去述說(shuō)的。

而當(dāng) I/O 完成時(shí)，則用一種叫中斷（interrupt）的機(jī)制來(lái)通知 cpu：

也即所謂的“中斷驅(qū)動(dòng)（interrupt-driven）”，現(xiàn)代操作系統(tǒng)基本都采用這一機(jī)制。

某種意義上，這也是控制反轉(zhuǎn)（IoC）機(jī)制的一種體現(xiàn)，cpu不用反復(fù)去詢(xún)問(wèn)硬盤(pán)，這也是所謂的“好萊塢原則”—Don’t call us, we will call you.好萊塢的經(jīng)紀(jì)人經(jīng)常對(duì)演員們說(shuō)：“別打電話給我，（有戲時(shí)）我們會(huì)打電話給你。”

在這里，硬盤(pán)與 cpu 的互動(dòng)機(jī)制也是類(lèi)似，硬盤(pán)對(duì) cpu 說(shuō)：”別老來(lái)問(wèn)我 IO 做完了沒(méi)有，完了我自然會(huì)通知你的“

當(dāng)然了，cpu 還是要不斷地檢查中斷，就好比演員們也要時(shí)刻注意接聽(tīng)電話，不過(guò)這總好過(guò)不斷主動(dòng)去詢(xún)問(wèn)，畢竟絕大多數(shù)的詢(xún)問(wèn)都將是徒勞的。

cpu 會(huì)收到一個(gè)比如說(shuō)來(lái)自硬盤(pán)的中斷信號(hào)，并進(jìn)入中斷處理例程，手頭正在執(zhí)行的線程因此被打斷，回到 ready 隊(duì)列。而先前因 I/O 而waiting 的線程隨著 I/O 的完成也再次回到 ready 隊(duì)列，這時(shí) cpu 可能會(huì)選擇它來(lái)執(zhí)行。

另一方面，所謂的時(shí)間分片輪轉(zhuǎn)本質(zhì)上也是由一個(gè)定時(shí)器定時(shí)中斷來(lái)驅(qū)動(dòng)的，可以使線程從 running 回到 ready 狀態(tài)：

比如設(shè)置一個(gè)10ms 的倒計(jì)時(shí)，時(shí)間一到就發(fā)一個(gè)中斷，好像大限已到一樣，然后重置倒計(jì)時(shí)，如此循環(huán)。

與 cpu 正打得火熱的線程可能不情愿聽(tīng)到這一中斷信號(hào)，因?yàn)樗馕吨@一次與 cpu 纏綿的時(shí)間又要到頭了……奴為出來(lái)難，何日君再來(lái)？

現(xiàn)在我們?cè)倏匆幌?Java 中定義的線程狀態(tài)，嘿，它也有 BLOCKED（阻塞），也有 WAITING（等待），甚至它還更細(xì)，還有TIMED_WAITING：

現(xiàn)在問(wèn)題來(lái)了，進(jìn)行阻塞式 I/O 操作時(shí)，Java 的線程狀態(tài)究竟是什么？是 BLOCKED？還是 WAITING？

可能你已經(jīng)猜到，既然放到 RUNNABLE 這一主題下討論，其實(shí)狀態(tài)還是 RUNNABLE。我們也可以通過(guò)一些測(cè)試來(lái)驗(yàn)證這一點(diǎn)：

@Test public?void?testInBlockedIOState()?throws?InterruptedException?{Scanner?in?=?new?Scanner(System.in);//?創(chuàng)建一個(gè)名為“輸入輸出”的線程tThread?t?=?new?Thread(new?Runnable()?{@Overridepublic?void?run()?{try?{//?命令行中的阻塞讀String?input?=?in.nextLine();System.out.println(input);}?catch?(Exception?e)?{e.printStackTrace();}?finally?{IOUtils.closeQuietly(in);}}},?"輸入輸出");?//?線程的名字//?啟動(dòng)t.start();//?確保run已經(jīng)得到執(zhí)行Thread.sleep(100);//?狀態(tài)為RUNNABLEassertThat(t.getState()).isEqualTo(Thread.State.RUNNABLE); }

在最后的語(yǔ)句上加一斷點(diǎn)，監(jiān)控上也反映了這一點(diǎn)：

網(wǎng)絡(luò)阻塞時(shí)同理，比如socket.accept，我們說(shuō)這是一個(gè)“阻塞式(blocked)”式方法，但線程狀態(tài)還是 RUNNABLE。

@Test public?void?testBlockedSocketState()?throws?Exception?{Thread?serverThread?=?new?Thread(new?Runnable()?{@Overridepublic?void?run()?{ServerSocket?serverSocket?=?null;try?{serverSocket?=?new?ServerSocket(10086);while?(true)?{//?阻塞的accept方法Socket?socket?=?serverSocket.accept();//?TODO}}?catch?(IOException?e)?{e.printStackTrace();}?finally?{try?{serverSocket.close();}?catch?(IOException?e)?{e.printStackTrace();}}}},?"socket線程");?//?線程的名字serverThread.start();//?確保run已經(jīng)得到執(zhí)行Thread.sleep(500);//?狀態(tài)為RUNNABLEassertThat(serverThread.getState()).isEqualTo(Thread.State.RUNNABLE);}

監(jiān)控顯示：

當(dāng)然，Java 很早就引入了所謂 nio（新的IO）包，至于用 nio 時(shí)線程狀態(tài)究竟是怎樣的，這里就不再一一具體去分析了。

至少我們看到了，進(jìn)行傳統(tǒng)上的 IO 操作時(shí)，口語(yǔ)上我們也會(huì)說(shuō)“阻塞”，但這個(gè)“阻塞”與線程的 BLOCKED 狀態(tài)是兩碼事！

如何看待RUNNABLE狀態(tài)？

首先還是前面說(shuō)的，注意分清兩個(gè)層面：

虛擬機(jī)是騎在你操作系統(tǒng)上面的，身下的操作系統(tǒng)是作為某種資源為滿(mǎn)足虛擬機(jī)的需求而存在的：

當(dāng)進(jìn)行阻塞式的 IO 操作時(shí)，或許底層的操作系統(tǒng)線程確實(shí)處在阻塞狀態(tài)，但我們關(guān)心的是 JVM 的線程狀態(tài)。

JVM 并不關(guān)心底層的實(shí)現(xiàn)細(xì)節(jié)，什么時(shí)間分片也好，什么 IO 時(shí)就要切換也好，它并不關(guān)心。

前面說(shuō)到，“處于 runnable 狀態(tài)下的線程正在* Java 虛擬機(jī)中執(zhí)行，但它可能正在等待*來(lái)自于操作系統(tǒng)的其它資源，比如處理器。”

JVM 把那些都視作資源，cpu 也好，硬盤(pán)，網(wǎng)卡也罷，有東西在為線程服務(wù)，它就認(rèn)為線程在“執(zhí)行”。

你用嘴，用手，還是用什么鳥(niǎo)東西來(lái)滿(mǎn)足它的需求，它并不關(guān)心~

處于 IO 阻塞，只是說(shuō) cpu 不執(zhí)行線程了，但網(wǎng)卡可能還在監(jiān)聽(tīng)呀，雖然可能暫時(shí)沒(méi)有收到數(shù)據(jù)：

就好比前臺(tái)或保安坐在他們的位置上，可能沒(méi)有接待什么人，但你能說(shuō)他們沒(méi)在工作嗎？

所以 JVM 認(rèn)為線程還在執(zhí)行。而操作系統(tǒng)的線程狀態(tài)是圍繞著 cpu 這一核心去述說(shuō)的，這與 JVM 的側(cè)重點(diǎn)是有所不同的。

前面我們也強(qiáng)調(diào)了“Java 線程狀態(tài)的改變通常只與自身顯式引入的機(jī)制有關(guān)”，如果 JVM 中的線程狀態(tài)發(fā)生改變了，通常是自身機(jī)制引發(fā)的。

比如 synchronize 機(jī)制有可能讓線程進(jìn)入BLOCKED 狀態(tài)，sleep，wait等方法則可能讓其進(jìn)入 WATING 之類(lèi)的狀態(tài)。

它與傳統(tǒng)的線程狀態(tài)的對(duì)應(yīng)可以如下來(lái)看：

RUNNABLE 狀態(tài)對(duì)應(yīng)了傳統(tǒng)的 ready， running 以及部分的 waiting 狀態(tài)。

總結(jié)

以上是生活随笔為你收集整理的面试官问：为什么 Java 线程没有 Running 状态？我懵了的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。