linux中r状态表示进程在可运行队列中等待调度，并非正在cpu执行；s态分可中断（s）与不可中断（d），后者常因硬件故障导致；ps无法捕捉真实运行瞬间，需用pidstat、perf等工具追踪实际cpu占用。
Linux中R状态不等于“正在CPU上执行”
进程显示为R（running）只是表示它处于**可运行队列中等待被调度**，未必正在占用CPU。内核调度器决定哪个R进程真正上CPU执行，其余的就排队等。尤其在多核系统中，ps或top看到大量R进程，可能只是负载高、调度竞争激烈，而非每个都在满频运行。
常见误判场景：
- 单核机器上看到20个
R进程 → 实际只有1个在跑，其余19个在runqueue里堵着 -
top中%CPU总和远低于100%，但STAT列一堆R→ 说明进程频繁进出可运行态（如短时计算+快速阻塞），不是持续霸占CPU - 用
perf record -e sched:sched_switch能观察到R进程实际被切换上/下CPU的频率，比单纯看ps更准
S睡眠态分两种：可中断 vs 不可中断
S（sleeping）是Linux中最常见的非运行态，但背后机制差异极大：
-
S（大写）= 可中断睡眠（TASK_INTERRUPTIBLE）：进程在等I/O、信号或显式调用wait_event_interruptible()；收到信号会唤醒并处理，比如read()从磁盘读数据时被Ctrl+C打断 -
D（大写）= 不可中断睡眠（TASK_UNINTERRUPTIBLE）：通常卡在底层驱动或硬件交互中（如等待坏块磁盘响应、NFS服务器失联），连SIGKILL都杀不掉，只能等设备恢复或内核超时
判断方法：
$ ps aux | awk '$8 ~ /^[SD]$/ {print $0}'
若大量进程卡在D态，基本可定位为存储或外设故障，不是应用层问题。
为什么ps看不到真正的“running on CPU”进程？
ps快照采样的是进程的**内核态任务结构体（task_struct）中的state字段**，而该字段在进程真正被调度器选中并进入__switch_to上下文切换前，仍是R。换句话说：ps永远抓不到“正在执行”的瞬间，只抓到“刚被唤醒”或“刚被抢占”的状态。
要逼近真实CPU占用，得用动态追踪工具：
-
pidstat -u 1：按秒输出每个进程实际CPU使用率（基于调度统计，非状态快照） -
perf top -p $(pgrep your_proc)：直接看该进程在CPU上执行时的函数热点 -
/proc/[pid]/stack：对R或S进程读取其内核栈，确认它到底在等什么（比如停在ext4_file_read_iter就是磁盘I/O，停在futex_wait_queue_me就是锁竞争）
sleep命令和进程S态没有直接关系
Shell里的sleep 5启动的进程确实会进S态，但它只是用户空间调用nanosleep()后由内核置为TASK_INTERRUPTIBLE——这和你程序里fread()卡住、accept()没连接、pthread_mutex_lock()抢不到锁导致的S本质相同，都是自愿让出CPU。
关键区别在于唤醒源：
-
sleep：靠定时器到期唤醒 - I/O类
S：靠设备中断或数据就绪唤醒 - 锁/信号量类
S：靠其他线程释放资源后显式唤醒
所以别看到S就以为是“休眠”，得结合/proc/[pid]/stack或strace -p [pid]看它最后一条系统调用是什么。
