Java线程六种状态对应JVM对执行权和调度权的具体判断：NEW（新建）、RUNNABLE（就绪或运行中）、BLOCKED（等待synchronized锁）、WAITING（无限期等待唤醒）、TIMED_WAITING（带超时等待）、TERMINATED（终止），状态迁移受JVM严格限制，不可逆且不可越级。
Java线程的六种状态到底对应什么行为
Java线程不是“运行中”或“没运行”这么简单，NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED 这六种状态，每一种都对应 JVM 对线程执行权和调度权的具体判断。
比如 RUNNABLE 并不等于“正在 CPU 上跑”，它包含“就绪”和“运行中”两种子状态——JVM 不区分，但你排查 CPU 占用高时得意识到：一个线程标为 RUNNABLE，可能正疯狂轮询，也可能刚被 OS 调度出去、还没轮到它。
常见误解是把 BLOCKED 和 WAITING 混为一谈。前者只发生在进入 synchronized 块/方法时抢不到锁；后者是主动调用 Object.wait()、Thread.join()、LockSupport.park() 等让出执行权的结果。
怎么准确查看某个线程当前处于哪种状态
别依赖 IDE 的线程视图或 jstack 输出里模糊的 “in Object.wait()” 这类描述——它们不直接显示 State 枚举值。最可靠的方式是代码中调用 Thread.getState()：
立即学习“Java免费学习笔记（深入）”；
Thread t = new Thread(() -> {
System.out.println(Thread.currentThread().getState()); // NEW → RUNNABLE
synchronized (this) {
System.out.println(Thread.currentThread().getState()); // RUNNABLE（持有锁）
}
});
t.start();
注意：getState() 返回的是快照，多线程下瞬时状态可能已变。生产环境排查时，更推荐用 jstack <pid>，它输出里明确标注 java.lang.Thread.State: BLOCKED 或 WAITING (on object monitor)。
-
BLOCKED一定伴随 “waiting to lock <0x...>” 提示，说明卡在 synchronized 入口 -
WAITING后面若写 “(parking)” 是用了LockSupport.park()；写 “(on object monitor)” 是Object.wait() -
TIMED_WAITING通常来自Thread.sleep(1000)、Object.wait(1000)、LockSupport.parkNanos()
状态流转中哪些转换根本不会发生
JVM 规定了严格的状态迁移路径，有些看似合理的跳转实际不可能出现。例如：
-
NEW→TERMINATED：不可能。没 start 过的线程不能终止，调thread.stop()（已废弃）也不行 -
RUNNABLE→NEW：不可能。线程启动后无法重置回初始态 -
BLOCKED→WAITING：不可能。BLOCKED 是锁竞争失败，WAITING 是主动放弃，二者触发机制正交 -
TERMINATED→ 任意其他状态：不可能。线程死亡后对象仍存在，但状态永远冻结为 TERMINATED
这些限制不是设计缺陷，而是为了保证线程生命周期可预测。如果你在线程 dump 里看到异常状态组合，大概率是 jstack 抓取时发生了竞态，或者用了非标准线程实现（如某些协程库伪装成 Thread）。
为什么 wait() 后是 WAITING，而 sleep() 后是 TIMED_WAITING
关键区别在于是否依赖“外部唤醒”。Object.wait() 必须配对 notify() 或 notifyAll() 才能返回，JVM 认为它“无限期等待信号”，归入 WAITING；而 Thread.sleep(5000) 自带超时，时间一到自动恢复，所以是 TIMED_WAITING。
这个区分直接影响监控逻辑：Prometheus 的 thread_state_count 指标会分别统计两类等待数。如果发现 WAITING 线程持续增长，优先查是否有 wait() 没配 notify()；如果是 TIMED_WAITING 异常多，再看是不是定时任务堆积或超时设置过长。
顺带一提：LockSupport.park() 默认进 WAITING，但 parkNanos(1000) 进 TIMED_WAITING——和 sleep 逻辑一致，只是底层机制不同。
状态本身不消耗资源，但长期停留在 WAITING 或 BLOCKED 往往暴露了锁设计或协作逻辑的问题。真正难定位的，是那些反复在 RUNNABLE 和 WAITING 之间快速切换的线程——它们可能正陷在自旋+阻塞混合的等待策略里，得结合堆栈和 GC 日志一起看。
