這麼理解線程生命週期，是否是很簡單？

時間 2020-03-26

標籤理解線程生命週期是否簡單简体版

原文原文鏈接

| 好看請贊，養成習慣html

你有一個思想，我有一個思想，咱們交換後，一我的就有兩個思想

If you can NOT explain it simply, you do NOT understand it well enough

現陸續將Demo代碼和技術文章整理在一塊兒 Github實踐精選，方便你們閱讀查看，本文一樣收錄在此，以爲不錯，還請Star🌟java

爲何要了解線程的生命週期？

以前寫過 Spring Bean 生命週期三部曲：git

有朋友留言說：「瞭解了它們的生命週期後，使用 Spring Bean 比如看到它們的行動軌跡，如今使用就一點都不慌了」。我和他同樣，瞭解事物的生命週期目的很簡單，惟【不慌】也github

Java 併發系列已經寫了不少，歷來還沒提起過那個它【Java線程生命週期】。有了前序理論圖文的鋪墊，在走進源碼世界以前，談論它的時機剛好到了。由於，編寫併發程序的核心之一就是正確的擺弄線程狀態面試

線程生命週期的幾種狀態

剛接觸線程生命週期時，我老是記不住，也理解不了他們的狀態，能夠說是比較混亂，更別說它們之間是如何進行狀態轉換的了。緣由是我把操做系統通用線程狀態和編程語言封裝後的線程狀態 概念混淆在一塊兒了spring

操做系統通用線程狀態

我的以爲通用線程狀態更符合咱們的思考習慣。其狀態總共有 5 種（以下圖）。對於常常寫併發程序的同窗來講，其嘴裏常常唸的都是操做系統中的這些通用線程狀態，且看編程

除去生【初始狀態】死【終止狀態】，其實只是三種狀態的各類轉換，聽到這句話是否是心情放鬆了不少呢？併發

爲了更好的說明通用線程狀態和 Java 語言中的線程狀態，這裏仍是先對前者進行簡短的說明編程語言

初始狀態

線程已被建立，可是還不被容許分配CPU執行。注意，這個被建立實際上是屬於編程語言層面的，實際在操做系統裏，真正的線程還沒被建立，好比 Java 語言中的 new Thread()。ide

可運行狀態

線程能夠分配CPU執行，這時，操做系統中線程已經被建立成功了

運行狀態

操做系統會爲處在可運行狀態的線程分配CPU時間片，被 CPU 臨幸後，處在可運行狀態的線程就會變爲運行狀態

休眠狀態

若是處在運行狀態的線程調用某個阻塞的API或等待某個事件條件可用，那麼線程就會轉換到休眠狀態，注意：此時線程會釋放CPU使用權，休眠的線程永遠沒有機會得到CPU使用權，只有當等待事件出現後，線程會從休眠狀態轉換到可運行狀態

終止狀態

線程執行完或者出現異常 (被interrupt那種不算的哈，後續會說)就會進入終止狀態，正式走到生命的盡頭，沒有起死回生的機會

接下來就來看看你熟悉又陌生，面試又常常被問到的Java 線程生命週期吧

Java語言線程狀態

在 Thread 的源碼中，定義了一個枚舉類 State，裏面清晰明瞭的寫了Java語言中線程的6種狀態：

NEW
RUNNABLE
BLOCKED
WAITING
TIMED_WAITING
TERMINATED

這裏要作一個小調查了，你有查看過這個類和讀過其註釋說明嗎？（歡迎留言腳印哦）

耳邊響起五環之歌，Java中線程狀態居然比通用線程狀態的 5 種多1種，變成了 6 種。這個看似複雜，其實並非你想的那樣，Java在通用線程狀態的基礎上，有裁剪，也有豐富，總體來講是少一種。再來看個圖，注意顏色區分哦

Java 語言中

將通用線程狀態的可運行狀態和運行狀態合併爲 Runnable，
將休眠狀態細分爲三種 (BLOCKED/WAITING/TIMED_WAITING); 反過來理解這句話，就是這三種狀態在操做系統的眼中都是休眠狀態，一樣不會得到CPU使用權

看上圖右側【Java語言中的線程狀態】，進一步簡潔的說，除去線程生死，咱們只要玩轉 RUNNABLE 和休眠狀態的轉換就能夠了，編寫併發程序也多數是這兩種狀態的轉換。因此咱們須要瞭解，有哪些時機，會觸發這些狀態轉換

遠看看輪廓，近看看細節。咱們將上面Java語言中的圖進行細化，將觸發的節點放到圖中 (這看似複雜的圖，其實三句話就能分解的，因此別慌)，且看：

RUNNABLE與BLOCKED狀態轉換

當且僅有（just only）一種狀況會從 RUNNABLE 狀態進入到 BLOCKED 狀態，就是線程在等待 synchronized 內置隱式鎖；若是等待的線程獲取到了 synchronized 內置隱式鎖，也就會從 BLOCKED 狀態變爲 RUNNABLE 狀態了

注意：
上面提到，以操做系統通用狀態來看，線程調用阻塞式 API，會變爲休眠狀態（釋放CPU使用權），但在JVM層面，Java線程狀態不會發生變化，也就是說Java線程的狀態依舊會保持在 RUNNABLE 狀態。JVM並不關心操做系統調度的狀態。在JVM看來，等待CPU使用權（操做系統裏是處在可執行狀態）與等待I/O（操做系統是處在休眠狀態），都是等待某個資源，因此都納入了RUNNABLE 狀態

—— 摘自《Java併發編程實戰》

RUNNABLE與WAITING狀態轉換

調用不帶時間參數的等待API，就會從RUNNABLE狀態進入到WAITING狀態；當被喚醒就會從WAITING進入RUNNABLE狀態

RUNNABLE與 TIMED-WAITING 狀態轉換

調用帶時間參數的等待API，天然就從 RUNNABLE 狀態進入 TIMED-WAITING 狀態；當被喚醒或超時時間到就會從TIMED_WAITING進入RUNNABLE狀態

看圖中的轉換 API 挺多的，其實不用擔憂，後續分析源碼章節，天然就會記住的，如今有個印象以及知道狀態轉換的節點就行了

相信到這裏，你看Java線程生命週期的眼神就沒那麼迷惑了，重點就是RUNNABLE與休眠狀態的切換，接下來咱們看一看，如何查看線程中的狀態，以及具體的代碼觸發點

如何查看線程處在什麼狀態

程序中調用 `getState()` 方法

Thread 類中一樣存在 getState() 方法用於查看當前線程狀態，該方法就是返回上面提到的枚舉類 State

NEW

就是上面提到，編程語言中特有的，經過繼承 Thread 或實現 Runnable 接口定義線程後，這時的狀態都是 NEW

Thread thread = new Thread(() -> {});
System.out.println(thread.getState());

RUNNABLE

調用了 start() 方法以後，線程就處在 RUNNABLE 狀態了

Thread thread = new Thread(() -> {});
thread.start();
//Thread.sleep(1000);
System.out.println(thread.getState());

BLOCKED

等待 synchronized 內置鎖，就會處在 BLOCKED 狀態

public class ThreadStateTest {

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(new DemoThreadB());
        Thread t2 = new Thread(new DemoThreadB());

        t1.start();
        t2.start();

        Thread.sleep(1000);

        System.out.println((t2.getState()));
        System.exit(0);
    }
}

class DemoThreadB implements Runnable {
    @Override
    public void run() {
        commonResource();
    }

    public static synchronized void commonResource() {
        while(true) {
            
        }
    }
}

WAITING

調用線程的 join() 等方法，從 RUNNABLE 變爲 WAITING 狀態

public static void main(String[] args) throws InterruptedException {
        Thread main = Thread.currentThread();

        Thread thread2 = new Thread(() -> {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
                e.printStackTrace();
            }
            System.out.println(main.getState());
        });
        thread2.start();
        thread2.join();
    }

TIMED-WAITING

調用了 sleep(long) 等方法，線程從 RUNNABLE 變爲 TIMED-WAITING 狀態

public static void main(String[] args) throws InterruptedException {
        Thread thread3 = new Thread(() -> {
            try {
                Thread.sleep(3000);
            } catch (InterruptedException e) {
        // 爲何要調用interrupt方法？
                Thread.currentThread().interrupt();
                e.printStackTrace();
            }
        });
        thread3.start();

        Thread.sleep(1000);
        System.out.println(thread3.getState());
    }

TERMINATED

線程執行完天然就到了 TERMINATED 狀態了

Thread thread = new Thread(() -> {});
thread.start();
Thread.sleep(1000);
System.out.println(thread.getState());

以上是程序中查看線程，本身寫寫測試看看狀態還好，現實中的程序怎麼可能容許你加這麼多無用代碼，因此，翠花，上酸菜（jstack）

jstack 命令查看

相信你據說過這玩意，jstack 命令就比較強大了，不只能查看線程當前狀態，還能看調用棧，鎖等線程棧信息

你們能夠隨意寫一些程序，這裏我用了上面 WAITING 狀態的代碼, 修改睡眠時間 Thread.sleep(100000)，而後在終端按照下圖標示依次執行下圖命令

更多功能還請你們自行查看，後續會單獨寫文章來教你們如何使用jstack查看線程棧信息

Arthas

這個利器，無須多言吧，線上找茬監控沒毛病，但願你能夠靈活使用這個工具，攻克疑難雜症

查看線程棧詳細信息，很是方便：https://alibaba.github.io/art...

相信你已經和Arthas確認了眼神

關於線程生命週期狀態總體就算說完了，編寫併發程序時多問一問本身：

調用某個API會將你的線程置爲甚麼狀態？

多問本身幾回，天然就記住上面的圖了

靈魂追問

爲何調用 Thread.sleep, catch異常後，調用了Thread.currentThread().interrupt();

進入 BLOCKED只有一種狀況，就是等待 synchronized 監視器鎖，那調用 JUC 中的 Lock.lock() 方法，若是某個線程等待這個鎖，這個線程狀態是什麼呢？爲何？

public class ThreadStateTest {

    public static void main(String[] args) throws InterruptedException {
        TestLock testLock = new TestLock();

        Thread thread2 = new Thread(() -> {
            testLock.myTestLock();
        }, "thread2");

        Thread thread1 = new Thread(() -> {
                testLock.myTestLock();
            }, "thread1");

        thread1.start();
        Thread.sleep(1000);

        thread2.start();
        Thread.sleep(1000);

        System.out.println("****" + (thread2.getState()));

        Thread.sleep(20000);
    }
}

@Slf4j
class TestLock{
    private final Lock lock = new ReentrantLock();

    public void myTestLock(){
        lock.lock();
        try{
            Thread.sleep(10000);
            log.info("testLock status");
        } catch (InterruptedException e) {
            log.error(e.getMessage());
        } finally {
            lock.unlock();
        }
    }
}