在Java里线程的生命周期如何变化_Java线程状态流转说明

NEW 状态仅存在于 new Thread() 后、start() 前，不可调度、不可中断；RUNNABLE 包含就绪、运行及部分I/O等待；WAITING 为无限期等待，TIMED_WAITING 含超时；BLOCKED 仅由 synchronized 锁竞争引发。

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 是带超时的等待，时间一到自动返回。两者都常见于同步工具类内部，但触发路径差异明显：

HyperWrite

AI写作助手帮助你创作内容更自信

下载

• 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 方法时，发现锁被别的线程持有）。

立即学习“Java免费学习笔记（深入）”；

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