waiting线程在内核中真实不消耗cpu：其/proc/[tid]/stat第3列为s（可中断睡眠），utime/stime不增长，perf采样无记录，且不计入调度器runqueue的nr_running。
WAITING 状态的线程在操作系统内核调度器中确实不消耗 CPU 算力——这不是 Java 层面的“看起来没干活”，而是内核调度器真实将其从运行队列移除、不分配任何时间片、不参与上下文切换的物理事实。要原生验证这一点，必须绕过 JVM 抽象层，直接观察内核视角下的线程状态与 CPU 时间归属。
看 /proc/[pid]/stat 中的调度器状态码
Linux 内核为每个线程（LWP）在 /proc/[tid]/stat 中记录其底层调度状态。WAITING 对应 Java 的 Object.wait() 或 Thread.join() 等调用，最终会触发内核的 futex_wait 或休眠系统调用，使线程进入 S（interruptible sleep） 状态。
验证步骤：
- 写一个 Java 程序：主线程启动后，新建一个线程并立即调用
wait()（在 synchronized 块中），使其长期处于 WAITING； - 用
jps -l和jstack [pid]确认该线程状态为java.lang.Thread.State: WAITING (on object monitor)； - 查出该线程对应的操作系统线程 ID（nid=0x...）→ 转为十进制 → 在
/proc/[pid]/task/下找到对应 tid 目录； - 读取
/proc/[pid]/task/[tid]/stat，第3列（state 字段）应为 S（非 R/RD 表示正在运行，非 D 表示不可中断）； - 第14列（utime）和第15列（stime）是该线程在用户态与内核态消耗的时钟周期数，持续观察数秒，它们完全不增长。
用 perf record 观察实际 CPU 时间归属
perf 是 Linux 内核原生性能分析工具，可精确采样 CPU 时间被哪些线程占用。WAITING 线程不会出现在采样堆栈中，因其未获得任何 CPU 时间片。
操作方法：
本文档主要讲述的是Android 操作系统的介绍；Android是基于Linux内核的操作系统，是Google公司在2007年11月5日公布的手机操作系统，早期由Google开发，后由开放手持设备联盟（Open Handset Alliance）开发。它采用了软件堆层（software stack，又名以软件叠层）的架构，主要分为三部分。底层Linux内核只提供基本功能；其他的应用软件则由各公司自行开发，部分程序以Java编写。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
- 启动 Java 进程并确保一个线程稳定处于 WAITING；
- 执行：
perf record -e cycles:u -g -p [pid] -- sleep 5（仅采集用户态周期，-g 记录调用栈）； - 执行
perf report --no-children； - 结果中只会出现运行中的线程（如 main、GC 线程、应用工作线程），WAITING 线程的 TID 不会出现在任何采样样本里；
- 对比：若将该线程改成
while(true) {}，它会高频出现在 top callee 列表中，utime/stime 飞速上涨。
检查调度器运行队列长度（runqueue）
Linux 调度器维护 per-CPU 的运行队列（rq->nr_running）。WAITING 线程不在其中，因此不会增加队列负载，也不会触发 CFS 调度决策。
验证方式（需 root）：
- 用
crash工具或 eBPF（如bpftrace）读取内核 struct rq； - 或更轻量：运行
cat /proc/sched_debug | grep "nr_running"，观察各 CPU 的nr_running值； - 启动 10 个 WAITING 线程前后，该数值保持不变；
- 但若启动 10 个
while(true) Thread.onSpinWait()线程，nr_running会立刻+10，且load显著上升。
对比 wait() 与 busy-wait 的 /proc/[tid]/stat 差异
同一程序中并行启动两种线程，直接比对原始字段：
-
WAITING 线程：stat 第3列为
S，第14/15列（utime/stime）静止，第45列（delayacct_blkio_ticks）也几乎为 0； -
busy-wait 线程（如空 while 循环）：stat 第3列为
R，第14列 utime 每秒增长约 10⁹（即接近 1 秒 CPU 时间），第44列（schedstat）显示大量 runtime_ns 和 vruntime_ns 变化。
这种差异不是 JVM “假装等待”，而是内核明确区分了「放弃 CPU」与「霸占 CPU」的两种物理行为。
