




NEW 状态仅存在于 new Thread() 后、start() 前,不可调度、不可中断;RUNNABLE 包含就绪、运行及部分I/O等待;WAITING 为无限期等待,TIMED_WAITING 含超时;BLOCKED 仅由 synchronized 锁竞争引发。
刚用 new Thread(runnable) 创建出来的线程对象,还没调用 start(),它就处于 NEW 状态。这个状态非常短暂,且不可被调度执行。一旦调用 start(),JVM 就会为其分配资源并尝试进入就绪队列——此时状态立刻变为 RUNNABLE(注意不是 “RUNNING”)。
NEW 线程无法通过 Thread.getState() 被外部观察到正在运行,甚至不能被中断(interrupt() 无效)start() 会抛出 IllegalThreadStateException,这是唯一能明确感知该线程已离开 NEW 的信号getState() == NEW 来判断线程是否“还没开始”,因为从 new 到 start 的间隙极短,且无内存屏障保证可见性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
Thread.getState() 的 JVM TI 支持增强,但底层仍是 OS 调度视角和 JVM 抽象层的混合映射,别把它当精确的运行时快照用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,但不会真正休眠 —— 这在自旋退避逻辑里有时被误用TIMED_WAITING (parking),大概率是 java.util.concurrent 类(如 LinkedBlockingQueue)在用 LockSupport.parkNanos 实现超时等待,属正常行为BLOCKED 是唯一与 synchronized 关键字强绑定的状态。它表示线程已准备好运行,但正等待获取某个对象的 monitor 锁(即进入 synchronized(obj) { ... } 或调用 synchronized 方法时,发现锁被别的线程持有)。

ReentrantLock.lock() 不会导致 BLOCKED,而是让线程进入 WAITING 或 TIMED_WAITING(取决于是否用 tryLock(long, TimeUnit))BLOCKED,这就是死锁链的起点BLOCKED on ,基本可判定发生锁竞争或死锁;但要注意,BLOCKED 时间极短(纳秒级)时,dump 可能抓不到,需结合 jstack -l 和 Unsafe.park 堆栈综合判断RUNNABLE ↔ TIMED_WAITING 切换频繁,BLOCKED 可能一闪而过,而 WAITING 一旦卡住往往意味着业务逻辑或资源泄漏。看状态不如看堆栈,查问题先看 jstack 输出里最顶上的 native 方法和锁地址。