线程生命周期：6 种状态与 12 次转换

面试官双手交叉，不紧不慢地抛出这个问题：

候选人 A 脱口而出："有 NEW、RUNNING、BLOCKED、WAITING、TERMINATED 五种"。面试官微微一笑——漏了一个，还多了一个（Java 里没有 RUNNING）。

候选人 B 胸有成竹："六种！NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED"。面试官追问：那状态之间的转换分别由什么 API 触发？候选人沉默了。

再往深挖一层，这是生产排查的基本功：凌晨服务变慢，jstack 抓个线程转储，满屏都是 BLOCKED (on object monitor)——如果你不熟状态机，这屏输出对你就只是一堆英文。

这道题之所以高频，是因为它同时考察了三件事：

• 你是否真正读过 Thread.State 的源码
• 你是否理解每种状态背后的操作系统调度原理
• 你能否把状态转换和具体 API 一一对应，并用 jstack 在生产里验证

发车之前，先问自己三个问题：

• RUNNABLE 到底包不包括"正在等待 CPU 时间片"的线程？
• BLOCKED 和 WAITING 的本质区别是什么？
• Thread.sleep() 和 Object.wait() 分别进入什么状态？释放锁吗？

带着这些问题，我们开始今天的线程之旅。

很多人背过线程状态，但很少有人翻开 JDK 源码看一看。线程的所有状态定义在 java.lang.Thread.State 这个枚举中：

public enum State {
    NEW,            // Thread object created but start() not yet called.
    RUNNABLE,       // Executing in the JVM — may be waiting for OS resources (e.g. CPU).
    BLOCKED,        // Waiting to acquire a monitor lock (synchronized block/method).
    WAITING,        // Waiting indefinitely for another thread's action (wait, park, join).
    TIMED_WAITING,  // Waiting up to a specified time (sleep, wait(ms), parkNanos).
    TERMINATED      // The thread has completed execution.
}

注意两个容易被忽略的细节：

下面这张图是线程生命周期的完整状态机。每一条箭头对应一次状态转换，箭头上标注了触发的 API。建议你放大仔细看——面试时能画出这张图，基本满分。

将 12 次转换整理成表格：

下面用代码验证每个状态：

// 1. NEW
Thread t1 = new Thread(() -> {});
System.out.println(t1.getState()); // NEW

// 2. RUNNABLE
Thread t2 = new Thread(() -> {
    while (true) { Thread.yield(); }
});
t2.start();
System.out.println(t2.getState()); // RUNNABLE

// 3. BLOCKED
Object lock = new Object();
Thread holder = new Thread(() -> {
    synchronized (lock) {
        try { Thread.sleep(999999); } catch (Exception e) {}
    }
});
holder.start();
Thread.sleep(100); // 等 holder 拿到锁
Thread t3 = new Thread(() -> {
    synchronized (lock) {} // 拿不到锁 → BLOCKED
});
t3.start();
Thread.sleep(100);
System.out.println(t3.getState()); // BLOCKED

// 4. WAITING
Thread t4 = new Thread(() -> {
    synchronized (lock) {
        try { lock.wait(); } catch (Exception e) {}
    }
});
// ... start + sleep → WAITING

// 5. TIMED_WAITING
Thread t5 = new Thread(() -> {
    try { Thread.sleep(60000); } catch (Exception e) {}
});
t5.start();
Thread.sleep(100);
System.out.println(t5.getState()); // TIMED_WAITING

// 6. TERMINATED
Thread t6 = new Thread(() -> {});
t6.start();
t6.join();
System.out.println(t6.getState()); // TERMINATED

第 2 站埋了个细节：RUNNABLE 包含"等待 CPU 时间片"。这句话值得单独展开，因为它揭示了 JVM 状态和 OS 状态不是一一对应的。

三个推论，全是面试加分点：

• "jstack 里看到 RUNNABLE" ≠ 线程在跑。8 核机器上有 20 个 RUNNABLE 线程，同一时刻只有 8 个真的在 CPU 上，另外 12 个在 OS 运行队列里排队。CPU 密集型服务线程数远超核数时，大部分 RUNNABLE 线程其实都在排队——这是「线程越多吞吐越低」的底层原因。
• RUNNABLE 线程不会被「暂停」：时间片切换对 Java 代码完全透明，你的代码没有任何一行能观察到「我刚被抢占过」——所以 Java 层面不区分 READY/RUNNING，区分了也没用。
• yield() 只是「让一让」：把当前线程从 Running 挪回 Ready 队尾，不保证下次立刻再调度回来，别把它当同步手段用（第 4 站 demo 里用它只是制造一个可观测的 RUNNABLE 样本）。

状态机的第一条边（①）背后是新手最常踩的坑：直接调 run() 不会创建新线程。

Thread t = new Thread(() ->
    System.out.println("线程名: " + Thread.currentThread().getName()));

// 写法 1：直接调 run() —— 普通方法调用，还是 main 线程在跑
t.run();   // 输出：线程名: main，状态永远是 NEW

// 写法 2：调 start() —— JVM 创建 OS 线程，在新线程里执行 run()
Thread t2 = new Thread(t::run);
t2.start(); // 输出：线程名: Thread-1（新线程！）

// 写法 3：对同一线程对象调两次 start()
t2.start(); // IllegalThreadStateException：线程是一次性的

一个 RUNNABLE 线程撞上被别人持有的 synchronized 锁，就进入 BLOCKED，在锁的 EntryList（ObjectMonitor 的阻塞列表）里排队。几个必须讲清楚的细节：

• 排队不等于 FIFO：synchronized 没有公平性保证，持锁线程释放后，JVM 从 EntryList 里挑一个唤醒（实现上不保证先排的先拿到），其他线程继续等。所以 synchronized 下的锁是「非公平」的——想公平，用 ReentrantLock(true)。
• BLOCKED 期间不响应 interrupt：中断只是记下标志位，线程照样排队，直到拿到锁进入临界区后，代码才可能检查标志（第 12 站细讲）。
• 持锁线程在临界区里 wait() 了会怎样：wait 会释放锁，排队的 BLOCKED 线程就能拿锁了——这就是为什么「持锁 + wait」是合法的，否则所有等这个锁的人全饿死。

jstack 里 BLOCKED 线程长这样（第 13 站展开）：

"worker-1" #11 ...
  waiting for monitor entry
  java.lang.Thread.State: BLOCKED (on object monitor)
    at com.example.OrderService.process(OrderService.java:42)
    - waiting to lock <0x000000076bf62208> (a java.lang.Object)

waiting to lock <地址> 就是线索：拿这个地址去全文搜 - locked <同一地址>，就找到了持锁者——谁持有、持有者卡在哪一行，锁竞争的全貌就出来了。

三个 API，同一个状态（WAITING），但语义和用法差别很大：

三个易错点：

• wait() 是实例方法，sleep() 是静态方法：Object.wait() 操作的是「这个对象的监视器」，Thread.sleep() 只是让当前线程睡——所以 wait 必须在 synchronized 块里（要操作 monitor），sleep 在哪都能调。
• park 是「许可制」：unpark 可以在 park 之前调用（许可先存着，后面 park 直接通过）——这比 wait/notify「先 wait 后 notify 才能匹配」灵活得多，AQS 的队列唤醒全靠它。
• wait() 会释放锁，sleep() 不会：这是「持锁线程想让路」时唯一正确的睡法——sleep 着持锁，所有竞争者全 BLOCKED，直接堵死。

WAITING / TIMED_WAITING 的线程有三条醒来的路：被通知（notify / unpark）、超时、被中断（interrupt → InterruptedException）。但「醒来」之后发生什么，是这里最容易被误解的地方：

第③点直接决定了生产代码里一个铁律：wait 必须包在 while 里，不能用 if：

synchronized (lock) {
    // ❌ if：醒来直接往下走，但条件可能早被别人消费掉了
    if (deque.isEmpty()) notEmpty.await();
    T v = deque.removeFirst();   // 可能 remove 一个空队列 → 出错的不是报错，是数据错乱

    // ✅ while：醒来后重新判断，不满足继续等
    while (deque.isEmpty()) notEmpty.await();
    T v = deque.removeFirst();   // 此刻队列一定非空
}

第 8、9 站分别讲了 wait 家族和 sleep 家族，这一站把它们放在同一张表里对撞——这是面试被追问频率第二高的问题：

一句话选型：需要「等某个条件成立」→ wait 家族；只是「过一会儿再来」→ sleep。生产里最常见的错误是拿 sleep 当 wait 用（轮询代替协作，延迟高还浪费 CPU），以及拿 wait 当 sleep 用（忘了 notify，线程永久 WAITING）——两种错误 jstack 里都看得见，一个是 TIMED_WAITING (sleeping)，一个是 WAITING (on object monitor) 停了好几天。

Thread.interrupt(t) 对处于不同状态的线程，行为完全不同——这是「中断」机制最常被答歪的地方：

两个 API 读标志，语义不一样，别混：

Thread.currentThread().isInterrupted();  // 只读不清：看标志还在不在
Thread.interrupted();                   // 读且清：一次性消费（静态方法，只能查当前线程）

// 长循环线程的优雅退出惯例：定期检查标志
while (!Thread.isInterrupted()) {
    processOneTask();   // 单步之间检查，退出延迟 = 单步耗时
}

线程进 TERMINATED 只有两条路：run() 正常返回，或 run() 里抛出未捕获的异常。第二条路比表面看起来更危险：

• 未捕获异常 = 线程猝死：异常冲出 run() 后，JVM 不会杀死整个进程，只是让这一个线程死亡，并把异常交给 UncaughtExceptionHandler（默认打印到 stderr）。业务后果：你以为是常驻的工作线程，其实早就死了，任务积压却毫无告警——「线程池里线程越来越少」的排查第一步就是看 UncaughtExceptionHandler 日志。
• 线程对象不可复活：TERMINATED 后 start() 直接抛 IllegalThreadStateException。需要「再来一次」就 new 新线程（或更好的：线程池复用）。
• 怎么知道它跑了没有 / 跑得对不对：t.join() 等它结束（自己进 TIMED_WAITING/WAITING）；t.isAlive() 查是否还在跑；有返回值的任务用 FutureTask/线程池 submit，future.get() 能拿到结果或异常（呼应「线程创建」篇的 execute vs submit 异常处理）。

ThreadFactory factory = r -> {
    Thread t = new Thread(r, "worker-" + seq.getAndIncrement());
    t.setUncaughtExceptionHandler((th, ex) -> {
        log.error("工作线程 {} 意外死亡", th.getName(), ex);
        metrics.inc("thread.death");   // 告警：常驻线程死亡 = 事故
    });
    return t;
};

面试官的终极杀招："给你一个线程转储，你能分析出什么问题？"掌握 jstack 输出格式，是你从"背八股"进阶到"真会用"的标志。

先看一段真实的 jstack 输出（节选）：

$ jstack 12345
Full thread dump OpenJDK 64-Bit Server VM (17.0.2+8):

"worker-1" #11 prio=5 os_prio=0 tid=0x00007f3a1c0e8800 nid=0x2a03
  waiting for monitor entry [0x00007f3a08ffe000]
  java.lang.Thread.State: BLOCKED (on object monitor)
    at com.example.OrderService.process(OrderService.java:42)
    - waiting to lock <0x000000076bf62208> (a java.lang.Object)
    at com.example.Worker.run(Worker.java:18)

"worker-2" #12 prio=5 os_prio=0 tid=0x00007f3a1c0ea000 nid=0x2a04
  in Object.wait() [0x00007f3a08efe000]
  java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x000000076bf62208> (a java.lang.Object)
    at java.lang.Object.wait(Object.java:328)
    at com.example.Consumer.consume(Consumer.java:35)

"timer-1" #13 prio=5 os_prio=0 tid=0x00007f3a1c0ec000 nid=0x2a05
  sleeping [0x00007f3a08dfe000]
  java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at com.example.Scheduler.poll(Scheduler.java:22)

"main" #1 prio=5 os_prio=0 tid=0x00007f3a1c010800 nid=0x2901
  runnable [0x00007f3a23ffe000]
  java.lang.Thread.State: RUNNABLE
    at com.example.App.main(App.java:15)

逐行解读的关键字段：

先读「状态分布」，再读「具体线程」——这是老手和新手的第一区别：

• 大量 WAITING 通常正常：线程池的空闲工作线程 park 在取任务、消费者 wait 在空队列、RPC 线程等 IO——WAITING 是「礼貌地等」，本身不是病。
• 大量 BLOCKED = 锁竞争热点：几十个线程 waiting to lock 同一个地址，而持锁线程栈顶还卡在某行慢代码（比如锁内调 RPC）——这就是要修的问题：锁粒度太大或锁内干了重活。
• RUNNABLE 但 CPU 打满：找 nid 对应 top -Hp 的高耗线程，看它是不是在忙等循环（没 sleep 的 while）或 GC（VM 线程）。
• WAITING 停在同一条 wait() 好几天：被唤醒的 notify 漏发了，或者条件永远不成立——配合 while 条件排查。

确认「某个线程到底卡在哪」的排查三板斧：

# 第一步：导出线程转储（-l 带锁信息）
jstack -l <pid> > thread_dump.txt

# 第二步：统计状态分布，先看大局
grep -o "Thread.State: [A-Z_]*" thread_dump.txt | sort | uniq -c

# 第三步：有 BLOCKED 的话，按锁地址找持有者
grep -A 5 "BLOCKED" thread_dump.txt
grep "0x000000076bf62208" thread_dump.txt
# → 找到 "locked <0x...>" 的线程 = 持锁者，看它的栈顶在干什么

# 如果 jstack 末尾出现 "Found one Java-level deadlock"：
# → 确认死锁，按输出的循环依赖链修代码（通常是加锁顺序不一致）

把 14 站的排查经验压成一张「症状速查表」，下次 oncall 直接对号入座：

把今天的核心知识压缩成一张速查表：

高频面试追问 & 标准答案：

A: 六个维度——sleep 是 Thread 静态方法、wait 是 Object 实例方法；sleep 不释放锁、wait 释放锁；wait 必须在 synchronized 内调用否则 IllegalMonitorStateException、sleep 随处可调；wait 靠 notify/notifyAll/超时/中断恢复、sleep 靠超时/中断；wait 是线程协作（等条件）、sleep 是自我延时；底层 wait 进 monitor 的 WaitSet、sleep 由 JVM 调度挂起。

A: BLOCKED 是被动等 synchronized 锁，JVM 自动排队，不响应中断；WAITING 是主动调 wait/park/join 等信号，可被 notify/unpark/interrupt 唤醒。关键推论：ReentrantLock.lock() 拿不到锁产生的是 WAITING（底层 park），不是 BLOCKED——所以 jstack 里一片 WAITING 不一定是问题，一片 BLOCKED 才是锁竞争热点。

A: wait() 立即抛出 InterruptedException，同时清除中断标志（异常已送达，标志不必再留）。线程从 WAITING 恢复，要重新竞争锁（拿不到就 BLOCKED）。如果业务代码不 catch 让它冲出 run()，线程就进 TERMINATED——这就是状态机里 WAITING → TERMINATED 那条边。

A: 调用 Thread.interrupt()。如果目标线程处于 sleep / wait / join（TIMED_WAITING 或 WAITING），会立即抛出 InterruptedException 并清除中断标志。如果目标线程正在 RUNNABLE 状态运行，只设置中断标志位，需要目标线程自己检查 Thread.interrupted() 并退出。所以「可中断」是线程作者的契约：长循环要检查标志，可中断点要让异常正常传播。