RUNNABLE状态表示线程可被OS调度，未必正在消耗CPU；它涵盖READY（等待时间片）和RUNNING（实际执行）两种OS态，因JVM无法实时跟踪内核级切换而统一抽象，区别于主动让权的BLOCKED或WAITING。
Java 的 RUNNABLE 状态不是“正在运行”的字面意思，而是一个逻辑上的“可被调度”状态——它既不保证线程此刻占着 CPU，也不表示它一定在排队等 CPU，而是把这两种操作系统层面的现实统一抽象为一个状态。看穿这一点，关键在于理解 JVM 不掌控 CPU 调度权，只负责向 OS 提交执行意愿。
为什么 JVM 不区分 READY 和 RUNNING？
JVM 运行在操作系统之上，线程最终由 OS 内核调度。JVM 无法实时获知某个 Java 线程是刚被分配到 CPU（RUNNING），还是刚被时间片切出、排在就绪队列里（READY）。因为：
- 现代 OS 使用毫秒级时间分片（如 10–20ms），线程在 READY ↔ RUNNING 之间高频切换，JVM 插入检查点的成本高、意义小；
- 上下文切换由内核完成，JVM 只能通过 native 层回调感知“开始执行”或“暂停执行”，但无法持续跟踪中间态；
- 将二者合并为 RUNNABLE，简化了 Java 程序员对线程生命周期的认知负担——你只需关心“它能不能跑”，不用管“它此刻在不在跑”。
RUNNABLE 在代码中对应哪些真实场景？
一个线程处于 RUNNABLE，并不意味着它一定在消耗 CPU。它可能正卡在以下任一环节：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 刚调用 start()，已加入 JVM 线程调度池，但 OS 尚未给它分配时间片（对应 OS 的 READY）；
- 正在执行计算密集型循环，CPU 时间片内活跃运行（对应 OS 的 RUNNING）；
- 发起系统调用（如 System.nanoTime() 或部分文件 I/O 的非阻塞路径），短暂等待内核返回，但尚未让出线程状态（仍属 RUNNABLE，而非 WAITING/BLOCKED）；
- 因优先级或调度策略暂时被 OS 挂起，但未进入睡眠或锁等待队列。
怎么验证一个 RUNNABLE 线程实际没在跑 CPU？
不能单靠 Thread.getState() == RUNNABLE 判断 CPU 占用。更有效的方式是结合系统级观测：
立即学习“Java免费学习笔记（深入）”；
- 用 jstack <pid> 查看线程栈：若显示 java.lang.Thread.State: RUNNABLE，但堆栈停在 Unsafe.park、Object.wait 或 I/O native 方法入口，说明它可能正陷在内核等待中；
- 用 top -H -p <pid>（Linux）或 jstat -gc <pid> 配合 CPU 使用率观察：若线程状态是 RUNNABLE，但对应 LWP 的 CPU% 长期为 0，大概率处于 READY；
- 用 async-profiler 采样：它能区分线程是运行在用户态、内核态，还是真正 idle，比单纯查 getState 更贴近真实执行流。
和 BLOCKED / WAITING 的本质区别在哪？
RUNNABLE 是“有资格竞争 CPU”，而 BLOCKED 和 WAITING 是“主动放弃 CPU 并挂起”：
- BLOCKED：在等 synchronized 锁，线程已退出 CPU，进入 JVM 内部的锁等待队列，不参与 OS 调度；
- WAITING / TIMED_WAITING：调用了 wait()、join()、park() 等，明确让出执行权并注册唤醒条件，OS 不会调度它，直到被显式唤醒；
- RUNNABLE：没有让出权，只是“还没轮到”或“刚轮到”，始终在 OS 的可运行队列中候命。
