大家好，我是 Oracle首席工程師楊曉峰。 今天想和大家深入聊聊線程，相信大家對于線程這個概念都不陌生，它是Java并發的基礎元素，理解、操縱、診斷線程是Java工程師的必修課，但是你真的掌握線程了嗎？

今天我要問你的問題是，一個線程兩次調用start()方法會出現什么情況？談談線程的生命周期和狀態轉移。

?

典型回答

Java的線程是不允許啟動兩次的，第二次調用必然會拋出IllegalThreadStateException，這是一種運行時異常，多次調用start被認為是編程錯誤。

關于線程生命周期的不同狀態，在Java 5以后，線程狀態被明確定義在其公共內部枚舉類型java.lang.Thread.State中，分別是：

• 新建（NEW），表示線程被創建出來還沒真正啟動的狀態，可以認為它是個Java內部狀態。

• 就緒（RUNNABLE），表示該線程已經在JVM中執行，當然由于執行需要計算資源，它可能是正在運行，也可能還在等待系統分配給它CPU片段，在就緒隊列里面排隊。

• 在其他一些分析中，會額外區分一種狀態RUNNING，但是從Java API的角度，并不能表示出來。

• 阻塞（BLOCKED），這個狀態和我們前面兩講介紹的同步非常相關，阻塞表示線程在等待Monitor lock。比如，線程試圖通過synchronized去獲取某個鎖，但是其他線程已經獨占了，那么當前線程就會處于阻塞狀態。

• 等待（WAITING），表示正在等待其他線程采取某些操作。一個常見的場景是類似生產者消費者模式，發現任務條件尚未滿足，就讓當前消費者線程等待（wait），另外的生產者線程去準備任務數據，然后通過類似notify等動作，通知消費線程可以繼續工作了。Thread.join()也會令線程進入等待狀態。

• 計時等待（TIMED_WAIT），其進入條件和等待狀態類似，但是調用的是存在超時條件的方法，比如wait或join等方法的指定超時版本，如下面示例：

public final native void wait(long timeout) throws InterruptedException;

• 終止（TERMINATED），不管是意外退出還是正常執行結束，線程已經完成使命，終止運行，也有人把這個狀態叫作死亡。

在第二次調用start()方法的時候，線程可能處于終止或者其他（非NEW）狀態，但是不論如何，都是不可以再次啟動的。

?

考點分析

今天的問題可以算是個常見的面試熱身題目，前面的給出的典型回答，算是對基本狀態和簡單流轉的一個介紹，如果覺得還不夠直觀，我在下面分析會對比一個狀態圖進行介紹。總的來說，理解線程對于我們日常開發或者診斷分析，都是不可或缺的基礎。

面試官可能會以此為契機，從各種不同角度考察你對線程的掌握：

• 相對理論一些的面試官可以會問你線程到底是什么以及Java底層實現方式。

• 線程狀態的切換，以及和鎖等并發工具類的互動。

• 線程編程時容易踩的坑與建議等。

可以看出，僅僅是一個線程，就有非常多的內容需要掌握。我們選擇重點內容，開始進入詳細分析。

?

知識擴展

首先，我們來整體看一下線程是什么？

從操作系統的角度，可以簡單認為，線程是系統調度的最小單元，一個進程可以包含多個線程，作為任務的真正運作者，有自己的棧（Stack）、寄存器（Register）、本地存儲（Thread Local）等，但是會和進程內其他線程共享文件描述符、虛擬地址空間等。

在具體實現中，線程還分為內核線程、用戶線程，Java的線程實現其實是與虛擬機相關的。對于我們最熟悉的Sun/Oracle JDK，其線程也經歷了一個演進過程，基本上在Java 1.2之后，JDK已經拋棄了所謂的Green Thread，也就是用戶調度的線程，現在的模型是一對一映射到操作系統內核線程。

如果我們來看Thread的源碼，你會發現其基本操作邏輯大都是以JNI形式調用的本地代碼。

private native void start0(); private native void setPriority0(int newPriority); private native void interrupt0();

這種實現有利有弊，總體上來說，Java語言得益于精細粒度的線程和相關的并發操作，其構建高擴展性的大型應用的能力已經毋庸置疑。但是，其復雜性也提高了并發編程的門檻，近幾年的Go語言等提供了協程（coroutine），大大提高了構建并發應用的效率。于此同時，Java也在Loom項目中，孕育新的類似輕量級用戶線程（Fiber）等機制，也許在不久的將來就可以在新版JDK中使用到它。

下面，我來分析下線程的基本操作。如何創建線程想必你已經非常熟悉了，請看下面的例子：

Runnable task = () -> {System.out.println("Hello World!");}; Thread myThread = new Thread(task); myThread.start(); myThread.join();

我們可以直接擴展Thread類，然后實例化。但在本例中，我選取了另外一種方式，就是實現一個Runnable，將代碼邏放在Runnable中，然后構建Thread并啟動（start），等待結束（join）。

Runnable的好處是，不會受Java不支持類多繼承的限制，重用代碼實現，當我們需要重復執行相應邏輯時優點明顯。而且，也能更好的與現代Java并發庫中的Executor之類框架結合使用，比如將上面start和join的邏輯完全寫成下面的結構：

Future future = Executors.newFixedThreadPool(1) .submit(task) .get();

這樣我們就不用操心線程的創建和管理，也能利用Future等機制更好地處理執行結果。線程生命周期通常和業務之間沒有本質聯系，混淆實現需求和業務需求，就會降低開發的效率。

從線程生命周期的狀態開始展開，那么在Java編程中，有哪些因素可能影響線程的狀態呢？主要有：

• 線程自身的方法，除了start，還有多個join方法，等待線程結束；yield是告訴調度器，主動讓出CPU；另外，就是一些已經被標記為過時的resume、stop、suspend之類，據我所知，在JDK最新版本中，destory/stop方法將被直接移除。

• 基類Object提供了一些基礎的wait/notify/notifyAll方法。如果我們持有某個對象的Monitor鎖，調用wait會讓當前線程處于等待狀態，直到其他線程notify或者notifyAll。所以，本質上是提供了Monitor的獲取和釋放的能力，是基本的線程間通信方式。

• 并發類庫中的工具，比如CountDownLatch.await()會讓當前線程進入等待狀態，直到latch被基數為0，這可以看作是線程間通信的Signal。

?

我這里畫了一個狀態和方法之間的對應圖：

Thread和Object的方法，聽起來簡單，但是實際應用中被證明非常晦澀、易錯，這也是為什么Java后來又引入了并發包。總的來說，有了并發包，大多數情況下，我們已經不再需要去調用wait/notify之類的方法了。

前面談了不少理論，下面談談線程API使用，我會側重于平時工作學習中，容易被忽略的一些方面。

先來看看守護線程（Daemon Thread），有的時候應用中需要一個長期駐留的服務程序，但是不希望其影響應用退出，就可以將其設置為守護線程，如果JVM發現只有守護線程存在時，將結束進程，具體可以參考下面代碼段。注意，必須在線程啟動之前設置。

Thread daemonThread = new Thread(); daemonThread.setDaemon(true); daemonThread.start();

再來看看Spurious wakeup。尤其是在多核CPU的系統中，線程等待存在一種可能，就是在沒有任何線程廣播或者發出信號的情況下，線程就被喚醒，如果處理不當就可能出現詭異的并發問題，所以我們在等待條件過程中，建議采用下面模式來書寫。

// 推薦 while ( isCondition()) {waitForAConfition(...); }// 不推薦，可能引入bug if ( isCondition()) {waitForAConfition(...); }

Thread.onSpinWait()，這是Java 9中引入的特性。我在專欄第16講給你留的思考題中，提到“自旋鎖”（spin-wait, busy-waiting），也可以認為其不算是一種鎖，而是一種針對短期等待的性能優化技術。“onSpinWait()”沒有任何行為上的保證，而是對JVM的一個暗示，JVM可能會利用CPU的pause指令進一步提高性能，性能特別敏感的應用可以關注。

再有就是慎用ThreadLocal，這是Java提供的一種保存線程私有信息的機制，因為其在整個線程聲明周期內有效，所以可以方便地在一個線程關聯的不同業務模塊之間傳遞信息，比如事務ID、Cookie等上下文相關信息。

它的實現結構，可以參考源碼，數據存儲于線程相關的ThreadLocalMap，其內部條目是弱引用，如下面片段。

static class ThreadLocalMap {static class Entry extends WeakReference<ThreadLocal<?>> {/** The value associated with this ThreadLocal. */Object value;Entry(ThreadLocal<?> k, Object v) {super(k);value = v;}}// … }

當Key為null時，該條目就變成“廢棄條目”，相關“value”的回收，往往依賴于幾個關鍵點，即set、remove、rehash。

下面是set的示例，我進行了精簡和注釋：

private void set(ThreadLocal<?> key, Object value) {Entry[] tab = table;int len = tab.length;int i = key.threadLocalHashCode & (len-1);for (Entry e = tab[i];; …) {//…if (k == null) {// 替換廢棄條目replaceStaleEntry(key, value, i);return;}}tab[i] = new Entry(key, value);int sz = ++size;// ?掃描并清理發現的廢棄條目，并檢查容量是否超限if (!cleanSomeSlots(i, sz) && sz >= threshold)rehash();// 清理廢棄條目，如果仍然超限，則擴容（加倍） }

具體的清理邏輯是實現在cleanSomeSlots和expungeStaleEntry之中，如果你有興趣可以自行閱讀。

?

結合專欄第4講的介紹引用類型，我們會發現一個特別的地方，通常弱引用都會和引用隊列配合清理機制使用，但是ThreadLocal是個例外，它并沒有這么做。

這意味著，廢棄項目的回收依賴于顯式地觸發，否則就要等待線程結束，進而回收相應ThreadLocalMap！這就是很多OOM的來源，所以通常都會建議，應用一定要自己負責remove，并且不要和線程池配合，因為worker線程往往是不會退出的。

?

今天，我介紹了線程基礎，分析了生命周期中的狀態和各種方法之間的對應關系，這也有助于我們更好地理解synchronized和鎖的影響，并介紹了一些需要注意的操作，希望對你有所幫助。

總結

以上是生活随笔為你收集整理的Java经典面试题：一个线程两次调用start()方法会出现什么情况？的全部內容，希望文章能夠幫你解決所遇到的問題。

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