Java中Thread.getState()返回的是JVM线程状态机快照，非OS真实状态；RUNNABLE仅表示可调度，不保证正在CPU执行，故无法准确判断“正在执行”。
Java 中不能靠 Thread.isAlive() 或 Thread.getState() == Thread.State.RUNNABLE 准确判断线程“正在执行”——因为 RUNNABLE 状态包含就绪和真正运行两种情况，且 JVM 无法暴露 OS 级调度细节。
Thread.getState() 返回的枚举值到底代表什么
它反映的是 JVM 线程状态机的快照，不是操作系统线程的真实运行状态。比如：
-
NEW：线程对象已创建，但start()还没调用 -
RUNNABLE：线程在 JVM 中可运行（含等待 CPU 调度、正在执行、或在 OS 层被挂起但未阻塞） -
BLOCKED：在进入 synchronized 块/方法时，等待 monitor 锁 -
WAITING：调用Object.wait()、Thread.join()、LockSupport.park()后无限期等待 -
TIMED_WAITING：带超时的等待，如Thread.sleep(100)、Object.wait(500)、LockSupport.parkNanos() -
TERMINATED：线程已执行完毕（run() 方法返回）或因异常退出
为什么 RUNNABLE ≠ 正在 CPU 上执行
JVM 规范只要求线程处于“可被调度”状态就标记为 RUNNABLE，不区分是否真在跑。常见混淆场景：
- 线程刚调用
start()，还在 OS 线程创建队列中 —— 状态已是 RUNNABLE，但尚未执行任何 Java 字节码 - 线程正执行密集计算，但被 OS 时间片抢占 —— 状态仍是 RUNNABLE，实际已暂停
- 线程在执行 native 方法（如
FileInputStream.read()），底层可能阻塞在系统调用 —— JVM 仍报告 RUNNABLE（除非该 native 方法显式让出状态）
面试常问：如何判断一个线程“当前正在执行 Java 代码”
没有标准 API 能 100% 确定。但可结合多种线索做合理推测：
立即学习“Java免费学习笔记（深入）”；
- 排除法：若状态不是
RUNNABLE，基本可确定没在执行（除极少数 native 阻塞场景） - 堆栈检查：用
Thread.getStackTrace()看是否在用户方法中（注意开销大，仅调试可用） - 线程 dump 分析：用
jstack <pid>查看线程栈顶帧，RUNNABLE 线程若栈顶是java.lang.Thread.run()或你自己的业务方法，大概率正在执行 - 配合 JMX：
ThreadMXBean.getThreadInfo(tid, 1)获取单帧栈信息，比全栈轻量
注意：Thread.getState() 是瞬时快照，多线程环境下结果可能在获取后立即失效；高并发系统中频繁轮询还可能干扰 GC 和调度器。
容易忽略的陷阱：线程状态与中断、守护线程无关
很多人误以为 isInterrupted() 或 isDaemon() 会影响 getState() 结果，其实完全独立：
- 中断状态只影响某些阻塞方法（如
sleep()、wait()）是否抛出InterruptedException，不会改变线程状态本身 - 守护线程（daemon thread）终止时机由 JVM 决定，但其生命周期内状态转换逻辑与普通线程完全一致
-
Thread.State.TERMINATED一旦进入就不会再变，但线程对象仍可存在（未被 GC），此时isAlive()返回 false，getState()永远是 TERMINATED
真正难的是把状态和行为对应起来——比如看到 TIMED_WAITING，得立刻想到可能是 sleep、join、parkNanos 或 await，而不是笼统说“线程睡着了”。
