Linux进程状态详解_running与sleep说明【指导】_网络技术

Linux进程状态详解_running与sleep说明【指导】

发布时间 - 2025-12-30 00:00:00 点击率：次

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。

关键区别在于唤醒源：