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。它可能正卡在以下任一环节：
- 刚调用 start()，已加入 JVM 线程调度池，但 OS 尚未给它分配时间片（对应 OS 的 READY）；
- 正在执行计算密集型循环，CPU 时间片内活跃运行（对应 OS 的 RUNNING）；
- 发起系统调用（如 System.nanoTime() 或部分文件 I/O 的非阻塞路径），短暂等待内核返回，但尚未让出线程状态（仍属 RUNNABLE，而非 WAITING/BLOCKED）；
- 因优先级或调度策略暂时被 OS 挂起，但未进入睡眠或锁等待队列。
怎么验证一个 RUNNABLE 线程实际没在跑 CPU？
不能单靠 Thread.getState() == RUNNABLE 判断 CPU 占用。更有效的方式是结合系统级观测：
- 用 jstack
查看线程栈：若显示 java.lang.Thread.State: RUNNABLE，但堆栈停在 Unsafe.park、Object.wait 或 I/O native 方法入口，说明它可能正陷在内核等待中； - 用 top -H -p
（Linux）或 jstat -gc 配合 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 的可运行队列中候命。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
