Java线程状态如何流转？

Java线程的六种状态（NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED）并非教科书式的理想化流转，而是深度耦合JVM抽象与操作系统调度的动态过程：NEW仅瞬时存在于new之后start之前，不可中断且难以观测；RUNNABLE实为“可运行态”而非“正在运行”，涵盖就绪、执行甚至部分I/O等待，极易被误读为CPU高负载；WAITING与TIMED_WAITING的本质区别在于是否依赖外部唤醒或超时自动恢复，常见于并发工具底层；而BLOCKED严格限定于synchronized锁竞争，与Lock机制无关——理解这些微妙差异，远比死记状态图更能帮你精准定位线程挂起、假死或资源争用等真实生产问题。

NEW 状态只在 new Thread() 之后、start() 之前存在

刚用 new Thread(runnable) 创建出来的线程对象，还没调用 start()，它就处于 NEW 状态。这个状态非常短暂，且不可被调度执行。一旦调用 start()，JVM 就会为其分配资源并尝试进入就绪队列——此时状态立刻变为 RUNNABLE（注意不是 “RUNNING”）。

• NEW 线程无法通过 Thread.getState() 被外部观察到正在运行，甚至不能被中断（interrupt() 无效）
• 重复调用 start() 会抛出 IllegalThreadStateException，这是唯一能明确感知该线程已离开 NEW 的信号
• 不要依赖 getState() == NEW 来判断线程是否“还没开始”，因为从 new 到 start 的间隙极短，且无内存屏障保证可见性

RUNNABLE 并不等于“正在 CPU 上执行”

RUNNABLE 是 Java 线程状态中覆盖范围最广的一个：它包含操作系统层面的 “ready”（就绪）、“running”（运行中），也包括 I/O 阻塞但未进入 WAITING 或 BLOCKED 的情况（比如调用 FileInputStream.read() 时内核态等待磁盘数据，JVM 仍认为它是 RUNNABLE）。

• 线程池中的空闲工作线程，只要没被 park 或 wait，就始终是 RUNNABLE（在 ThreadPoolExecutor 的 runWorker 循环里阻塞在 getTask()，但该方法内部用的是 LockSupport.parkNanos，所以实际状态是 WAITING —— 这是个常见误解点）
• Thread.getState() 返回 RUNNABLE 时，不能推断出 CPU 使用率高；同样，CPU 占用低也不代表状态不是 RUNNABLE
• Java 10+ 引入了 Thread.getState() 的 JVM TI 支持增强，但底层仍是 OS 调度视角和 JVM 抽象层的混合映射，别把它当精确的运行时快照用

WAITING 和 TIMED_WAITING 的触发方式完全不同

WAITING 是无限期等待，必须靠其他线程显式唤醒；TIMED_WAITING 是带超时的等待，时间一到自动返回。两者都常见于同步工具类内部，但触发路径差异明显：

• WAITING：由 Object.wait()（无参）、Thread.join()（无参）、LockSupport.park() 触发
• TIMED_WAITING：由 Object.wait(timeout)、Thread.sleep(millis)、Thread.join(timeout)、LockSupport.parkNanos(ns)、Condition.awaitNanos() 触发
• 特别注意：Thread.sleep(0) 是合法的，它会让出当前时间片，状态为 TIMED_WAITING，但不会真正休眠 —— 这在自旋退避逻辑里有时被误用
• JVM 线程 dump 中看到大量 TIMED_WAITING (parking)，大概率是 java.util.concurrent 类（如 LinkedBlockingQueue）在用 LockSupport.parkNanos 实现超时等待，属正常行为

BLOCKED 只发生在进入 synchronized 同步块/方法时竞争 monitor 锁

BLOCKED 是唯一与 synchronized 关键字强绑定的状态。它表示线程已准备好运行，但正等待获取某个对象的 monitor 锁（即进入 synchronized(obj) { ... } 或调用 synchronized 方法时，发现锁被别的线程持有）。

• ReentrantLock.lock() 不会导致 BLOCKED，而是让线程进入 WAITING 或 TIMED_WAITING（取决于是否用 tryLock(long, TimeUnit)）
• 一个线程可以在持有某对象锁的同时，因等待另一个对象锁而变成 BLOCKED，这就是死锁链的起点
• 线程 dump 中若出现多个线程相互 BLOCKED on ，基本可判定发生锁竞争或死锁；但要注意，BLOCKED 时间极短（纳秒级）时，dump 可能抓不到，需结合 jstack -l 和 Unsafe.park 堆栈综合判断

线程状态流转不是状态机图上画的那么干净利落，真实场景中 RUNNABLE ↔ TIMED_WAITING 切换频繁，BLOCKED 可能一闪而过，而 WAITING 一旦卡住往往意味着业务逻辑或资源泄漏。看状态不如看堆栈，查问题先看 jstack 输出里最顶上的 native 方法和锁地址。

好了，本文到此结束，带大家了解了《Java线程状态如何流转？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！