面试被追着问的Java多线程生命周期：从青铜到王者，我悟了！

原创于 2025-06-30 15:16:43 发布 · 733 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#面试 #java #职场和发展

一开始我觉得这玩意儿不就是那几个状态吗？直到被面试官追问"BLOCKED和WAITING的根本区别是什么？"、"RUNNABLE里藏着哪些性能陷阱？"，才意识到自己之前理解的有多肤浅。

今天咱们不照本宣科，从一个实战派的视角，把多线程生命周期的"里里外外"扒个干净——不仅要知道六个状态的名字，更要明白它们是怎么"生老病死"的，以及在真实项目中如何利用这些状态解决问题。

一、先搞清楚：线程的"身份证"到底有几种状态？

Java线程的生命周期，本质上是Thread.State枚举定义的六个状态（JDK1.5引入）。很多人背过这六个名字：NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED。但真正面试被卡住的，是搞不清状态之间的转换逻辑。

我用一张自己画的"状态流转图"帮你理清关系（见下图，建议保存）。记住：线程的状态转换是单向的，就像人生只能从出生到死亡，不能"逆生长"。

https://img-blog.csdnimg.cn/20230920153000123.png

二、逐个拆解：每个状态的"生存法则"和典型场景

1. NEW（新生儿）：线程的"胎教"阶段

定义：线程对象刚被创建（调用了new Thread()），但还没调用start()方法。
特点：这时候线程只是JVM中的一个对象，操作系统层面根本没分配资源，CPU更不会搭理它。
常见误区：有人觉得"创建线程=启动线程"，结果面试时被问"new Thread后线程处于什么状态？"直接懵。
实战场景：

Thread thread = new Thread(() -> System.out.println("我是NEW状态")); 
// 此时thread.getState() → NEW

2. RUNNABLE（预备役）：线程的"高考冲刺期"

定义：调用start()后，线程进入RUNNABLE状态。但注意！RUNNABLE在JVM中分为两个子状态（JDK1.6之后细分）：

就绪（Ready）：线程已准备好，等待CPU调度（比如刚start()，或被yield()让出CPU）。
运行中（Running）：线程正在CPU上执行run()方法。

转换条件：

就绪 → 运行中：CPU分配时间片。
运行中 → 就绪：时间片耗尽，或被高优先级线程抢占。
运行中 → BLOCKED/WAITING/TIMED_WAITING：主动让出CPU（比如等待锁、调用wait()/sleep()）。

血泪教训：
很多人用Thread.activeCount()查看活跃线程数时，发现数值不对，就是因为把RUNNABLE的两个子状态混为一谈——就绪和运行中的线程都属于RUNNABLE状态，但实际占用CPU的只有运行中的那个。

实战场景：

thread.start(); 
// 此时thread.getState()可能是RUNNABLE（就绪或运行中，取决于CPU调度）

3. BLOCKED（堵车状态）：线程的"停车场等待"

定义：线程因竞争锁失败，被阻塞在synchronized同步块/方法外。
转换条件：

当持有锁的线程释放锁时，JVM会从等待锁的线程中选一个唤醒（进入RUNNABLE就绪状态）。

常见误区：
有人觉得"BLOCKED是因为线程执行时间太长"，其实它是主动/被动等待锁的结果。比如两个线程同时抢同一把锁，没抢到的那个就会进入BLOCKED。

实战场景：

// 线程1：持有锁
new Thread(() -> {
    synchronized (lock) {
        // 执行耗时操作...
    }
}).start();

// 线程2：抢锁失败进入BLOCKED
new Thread(() -> {
    synchronized (lock) { // 这里会阻塞，直到线程1释放锁
        System.out.println("抢到锁了");
    }
}).start();

4. WAITING（干等状态）：线程的"望眼欲穿"

定义：线程因调用wait()、join()或LockSupport.park()，主动放弃CPU并进入等待队列，直到被其他线程唤醒。
转换条件：

被唤醒（notify()/notifyAll()）或被中断（interrupt()）。

和BLOCKED的本质区别：
BLOCKED是"等锁"（被动等待系统分配资源），WAITING是"等事件"（主动等待其他线程通知）。

实战翻车现场：
我之前在做一个消息队列时，用wait()等待消息，但忘记在放入消息时调用notify()，结果线程一直卡在WAITING状态，日志都查不到原因——一定要记得唤醒！

实战场景：

synchronized (obj) {
    obj.wait(); // 进入WAITING状态，释放锁
}
// 被唤醒后重新竞争锁，回到RUNNABLE

5. TIMED_WAITING（限时干等）：线程的"闹钟式等待"

定义：线程因调用sleep(long)、wait(long)、join(long)或LockSupport.parkNanos()，进入带超时的等待状态。
转换条件：

时间到期自动唤醒（回到RUNNABLE）；
提前被唤醒（和WAITING一样）。

为什么需要这个状态？
防止线程无限等待。比如数据库连接池，如果获取连接超时，就可以用TIMED_WAITING避免线程一直卡住。

实战技巧：
调试时如果发现大量TIMED_WAITING线程，要检查是否有合理的超时时间设置——比如Thread.sleep(1000)如果设置成0，会直接进入RUNNABLE（但这种情况很少见）。

实战场景：

// 等待3秒后自动唤醒
Thread.sleep(3000); 
// 或者带超时的wait()
synchronized (obj) {
    obj.wait(3000); 
}

6. TERMINATED（退休状态）：线程的"圆满谢幕"

定义：线程的run()方法执行完毕，或因异常终止。
特点：

状态一旦进入就无法逆转（不能重启已终止的线程）。
JVM会回收线程资源，但操作系统层面的线程可能还没完全销毁（取决于JVM实现）。

注意事项：
很多人用stop()方法强制终止线程（已被废弃），这会导致资源未释放、数据不一致等问题。正确做法是通过标志位控制线程退出（比如volatile boolean running）。

实战场景：

Thread thread = new Thread(() -> {
    try {
        // 执行任务...
    } finally {
        // 清理资源（关闭连接、释放锁等）
    }
});
thread.start();
// 等待任务完成
thread.join(); 
// 此时thread.getState() → TERMINATED