先说个真实场景。有一回我接到同事转来的一个“疑难杂症”：某台测试服务器 CPU 空闲、内存也够，但 load average 一路飙到 20 多，服务死活起不来新进程。我上去敲了几条命令，top里一大片进程的 STAT 列都写着D，还有几个Z躺在那不动。那一刻就明白了——进程状态这东西，平时不起眼，真出问题的时候就是破案的关键线索。
这篇文章我打算把 Linux 进程的六种常见状态彻底讲明白：R、S、D、T、t、Z，外加一个你很难见到的X状态。内容会覆盖每个状态到底是什么、状态之间怎么切换、内核里靠什么字段记录，以及实际运维中最容易遇到的D状态卡死和僵尸进程问题应该怎么排查。不管你是刚入门 Linux 的新手，还是写过一段时间 C/C++ 或者做过服务部署的开发者，这篇文章的实操部分都能直接用上。
1. 先认全六种状态：一图一表看懂 STAT 列
1.1 R 和 S：日常打交道最多的两种状态
先说R，全称 Running 或 Runnable，内核里的宏是TASK_RUNNING。很多人以为 R 状态就是“正在 CPU 上执行”，其实不完全对。R 状态包含了两类进程：一类真正占着 CPU 核心在执行指令，另一类虽然准备好了，但还在 CPU 的运行队列里排队等调度。所以当你看到进程是 R，不代表它一定正在跑，也可能是“万事俱备，只欠 CPU”。
再说S，全称 Sleeping，内核宏是TASK_INTERRUPTIBLE，翻译过来叫“可中断睡眠”。进程执行到某些需要等待的操作时会主动睡过去，比如等待磁盘数据、等待网络包、等待定时器到期。S 状态的关键点是“可中断”——如果进程在睡眠中收到信号，内核会把它唤醒，先处理信号，再决定后续动作。
我常用生活里的场景来理解这俩的区别：R 状态是排队等 CPU 这个收银台付款，S 状态是已经在候车厅坐着，但随时能听到广播。只要广播喊到你（信号来了），你就得站起来。
1.2 D、T/t、Z：容易出问题也容易搞混的状态
D状态，内核宏是TASK_UNINTERRUPTIBLE，不可中断睡眠。单看名字就知道，这种状态连信号都叫不醒它。最常见的地方是：进程在内核态做同步磁盘 IO、访问网络文件系统（比如 NFS）或者触发内存页回写的时候。为什么不能中断？因为内核正在做一件不能半途而废的事，如果被打断，磁盘数据可能写一半，文件系统就损坏了。D 状态也是运维事故里的大主角，后面我会专门展开。
T状态，全称 Stopped，内核宏是TASK_STOPPED。进程收到SIGSTOP、SIGTSTP、SIGTTIN或SIGTTOU信号后进入暂停状态，这个时候进程不执行任何代码，但还留在内存里。SIGTRAP一类信号除外，SIGSTOP是不能被忽略和捕获的。你可以用kill -STOP <pid>手动把人家的进程暂停，再用kill -CONT <pid>恢复。
t状态是 Tracing Stop，也就是被跟踪暂停。最常见的是你用 gdb 调试程序时，断点命中、单步执行的那一瞬间，进程就处于 t 状态。也有另一种场景：进程被ptrace系统调用挂住。从表现上看 t 和 T 都是“暂停”，但来源完全不同：T 是收到停止信号，t 是调试器介入。
Z状态就是大名鼎鼎的僵尸（Zombie）。进程已经退出，不再执行任何代码、不再占用内存，但它的 task_struct 还留在内核里，等待父进程来“收尸”。如果父进程一直不调用wait()或waitpid()，这个僵尸就会一直挂在进程表里。
1.3 为什么说“六种状态”？
在工具里你能看到的组合主要是 R、S、D、T、t、Z，但我个人习惯把X（EXIT_DEAD）也提一嘴，它是进程退出后被回收前的瞬间状态，因为存在时间极短，用ps基本捕捉不到，所以很多人不知道。那套经典的组图里还有一个说法：T 和 t 因为都属于“暂停”，有时会被合并计算，所以在不同资料里你会看到“五种”“六种”“七种”的差异，但只要理解底层含义，这些口径都不是问题。
另外，ps的 STAT 列里还经常出现一堆附加符号，它们和状态字母拼在一起形成Ss、R+、Sl这样的写法：
| 附加符号 | 含义 |
|---|---|
< | 高优先级进程，可以通过nice调整 |
N | 低优先级进程 |
s | 会话首进程，通常是 shell 本身 |
l | 多线程进程 |
+ | 位于前台进程组 |
L | 有页面被锁定在内存中，常见于实时进程 |
这些附加符号不会单独出现，它们只是给主状态补充细节，读 STAT 列的时候可以先看第一个字母，再看后面的辅助符号。
2. 状态背后的内核机制：进程怎么从 R 变成 Z
2.1 task_struct 和 state 字段
要理解进程状态，绕不开进程控制块这个概念。在 Linux 内核里，每个进程和线程都对应一个task_struct结构体，它就像进程的“户籍档案”，里面记录了进程的 PID、PPID、打开的文件描述符、内存地址空间、寄存器状态，以及当前状态state字段。
进程状态本质上就是一个整数变量：
TASK_RUNNING= 0，对应 RTASK_INTERRUPTIBLE= 1，对应 STASK_UNINTERRUPTIBLE= 2，对应 DTASK_STOPPED= 4，对应 TTASK_TRACED= 8，对应 tEXIT_ZOMBIE= 16，对应 ZEXIT_DEAD= 32，对应 X
调度器通过维护运行队列、等待队列等数据结构，配合这些状态值完成进程调度。你每次敲ps或top，系统读取的就是这些字段然后映射成字母，并不是现跑的检查。
Linux 的线程不是独立的另一种实体，它和进程共用task_struct，只是多个线程共享同一个内存地址空间。这也是为什么ps -eLf能看到每个线程状态的原因。
2.2 生命周期与状态流转：一个进程从出生到死亡的全过程
把一个进程从创建到销毁的一生拉直了看，状态流转其实非常清晰：
- 创建：父进程调用
fork()或clone()，内核创建一个新的task_struct，把新进程放入运行队列。此时新进程是 R 状态（Runnable）。 - 运行：调度器选中它，给它分配 CPU 时间片，进程真正执行用户态代码。
- 睡眠：进程执行到
read()、sleep()、等待条件变量等场景时，主动调用调度器让出 CPU，进入 S 状态。如果这个等待过程不能被信号打断，就会进入 D 状态。 - 唤醒：等待条件满足或者收到信号后，进程被放回运行队列，回到 R 状态，等待下一次被调度。
- 暂停：收到停止信号进入 T 状态；调试器 attach 后命中断点进入 t 状态；无论是 T 还是 t，都可以通过
SIGCONT或继续调试操作恢复成 R。 - 退出：进程调用
exit()或从 main 函数 return 后，内核释放大部分资源，但保留task_struct，状态变成 Z，等待父进程wait()。父进程调用wait()后，内核回收最后的残留，进程状态变成 X，然后彻底从系统消失。
这里有一个很典型的坑：僵尸进程不是退出时立刻产生的。如果父进程在子进程退出后的瞬间就调用了wait()，僵尸状态存在时间极短，你根本看不到 Z。只有父进程“不负责”，一直不调用 wait，僵尸才会一直存在。
2.3 孤儿进程和状态切换的隐藏细节
稍等，还有一个概念容易和僵尸混在一起：孤儿进程。当父进程先退出，子进程会被 1 号进程（现在大多是 systemd）收养。收养之后，1 号进程会负责在子进程退出时调用 wait，所以孤儿进程通常不会变僵尸。真正的僵尸往往是父进程还活着，但是忘了收尸。
还有一个隐藏细节：进程从 S 或 D 状态被唤醒后，并不保证立刻拿到 CPU，它只是被放回运行队列变成 R，能不能跑还要看调度器的脸色。所以 R 状态的进程数量往往比 CPU 核心数还多，这很健康。只有 R 状态数量长时间大幅高于核心数，并且负载持续走高，才说明 CPU 不够用了。
状态切换的另一个冷知识：进程在用户态执行时发生系统调用，如果这个系统调用需要等待 IO，进程会从正在运行切换到睡眠状态，这个切换动作本身会记录在/proc/<pid>/status里的上下文切换计数中。后面我会专门讲怎么看这个数。
3. 实操：3 分钟学会精准查看进程状态
3.1 ps 命令的正确用法：别只记住 ps aux
查看进程状态最常用的命令是ps，但我发现很多人只会敲ps aux，看到一堆输出却不知道哪个字段才是状态。ps aux的第八列才是 STAT，这个字段在输出比较宽的时候容易看串行。
ps aux | head -5 # USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND # root 1 0.0 0.2 168000 13332 ? Ss 10:02 0:05 /usr/lib/systemd/systemd # root 2 0.0 0.0 0 0 ? S 10:02 0:00 [kthreadd]自定义列的查看方式更精准：
ps -eo pid,ppid,stat,comm,args --sort=-pid | head -20这条命令指定了要展示 PID、PPID、STAT、命令名和完整参数，排序后看起来非常清爽。
如果你只想知道一个进程当前处于什么状态，还可以单独看：
ps -o pid,stat,comm -p 12345 # PID STAT COMMAND # 12345 S myapp3.2 top 和 htop 的状态汇总解读
top命令第一屏顶部会统计所有任务的状态数量：
Tasks: 203 total, 1 running, 202 sleeping, 0 stopped, 0 zombie这一行信息量很大。注意里面的 running 数量，我在排查问题时会重点看这个值和平均负载是否匹配。如果 running 长期在 1 左右，但 load average 是 10，那多出来的一大半基本就是 D 状态进程贡献的。
top的进程列表里，STAT 列缩写和ps略有不同，但含义一致。htop则用颜色区分状态，R 是绿色、S 是白色、D 是红色，视觉上更直观。个人建议：日常用htop快速瞄一眼，写脚本和精确排查时还是用ps，因为ps的输出更适合管道处理。
3.3 /proc 文件系统：进内核内部看状态
/proc是 Linux 暴露给用户态的一个“内核窗口”，每个进程在/proc/<pid>/下都有专属目录。查看进程状态最直接的文件是/proc/<pid>/status：
cat /proc/1/status # Name: systemd # State: S (sleeping) # Tgid: 1 # Pid: 1 # PPid: 0 # ...这个文件除了 State 字段，还藏着两个非常实用的指标：voluntary_ctxt_switches和nonvoluntary_ctxt_switches。前者是进程主动让出 CPU 的次数，后者是被抢占或强制阻塞的次数。如果一个进程的 nonvoluntary_ctxt_switches 增长非常快，往往说明它频繁被高优先级进程打断，或者频繁在不可中断的状态里进进出出。
如果要看进程当前正在等什么内核资源，可以查看/proc/<pid>/wchan或/proc/<pid>/stack：
cat /proc/12345/wchan # pipe_read看到pipe_read就说明进程正阻塞在管道读取上，这些信息配合状态使用，能快速定位瓶颈。
3.4 一条命令抓住所有异常状态进程
实际排查问题的时候，我不会一个个进程去翻，一般直接过滤：
# 找出所有 D 状态进程 ps -eo pid,ppid,stat,comm,args | awk '$3 ~ /^D/ {print}' # 找出所有僵尸进程 ps -eo pid,ppid,stat,comm,args | awk '$3 ~ /^Z/ {print}' # 实时刷新 D 状态进程数量 watch -n 1 'ps -eo stat | grep -c "^D"'watch搭配管道是看瞬时状态变化的利器。有一次我排查一个偶发的 IO 卡顿，就是靠watch -n 1盯 D 状态数量，发现每隔几十秒就出现一批 D 进程持续两三秒，顺藤摸瓜定位到了定时任务触发的全量备份脚本。
4. 两大棘手状态深度排查：D 状态和僵尸进程
4.1 D 状态排查：不可中断睡眠到底在等什么
先说最让人头疼的 D 状态。它的典型现象是：CPU 不忙、内存不紧张，但 load average 很高，top 里一大片 D，服务卡死。
最常见的原因大致有这几种：
第一个是本地磁盘 IO 排队过长。机械硬盘在高并发随机读写下响应很慢，内核线程在等待 IO 完成时可能进入 D。这种情况下 iowait 会很高，iostat -x 1能看到磁盘 util 接近 100%。
第二个是网络文件系统问题。NFS 挂载的目录如果服务端不可达，客户端的进程在等待 NFS IO 完成时会非常容易进入 D，而且持续时间可能很长。我在生产环境踩过的坑就是内网 NFS 服务端重启，客户端几十个进程瞬间全部变 D，整个服务不可用。
第三个是 swap 频繁使用。内存不足导致换页时，进程可能卡在等待内存页换入，也可以表现为 D。
第四个比较少见但会致命：内核驱动或文件系统 bug。这种需要通过 /proc 的内核栈信息来定位。
排查步骤建议如下：
- 先确认是不是 IO 问题：
top看 wa 列，iostat -x 1看设备 util。 - 对每个 D 状态进程，查看它的内核栈：
cat /proc/<pid>/stack，注意需要 root 权限。 - 查看当前系统调用：
cat /proc/<pid>/syscall。 - 看
wchan知道它卡在哪个内核函数。
处理上有一条红线：不要盲目 kill -9。D 状态进程根本不响应普通信号，kill -9 大概率杀不掉，而且如果它阻塞在关键 IO 半路，强行动作可能导致数据不一致，引发更严重的问题。正确的做法是找到 D 的根因：
- 如果是本地磁盘，优化 IO 压力，降低并发，等它自己消化完。
- 如果是 NFS，检查网络连通性、恢复服务端，必要时可以尝试重新挂载。现代内核的 NFS 支持
hard,intr挂载参数，但不同内核版本对信号响应能力不一样，需要结合实际情况评估。 - 如果是内核态问题，把
/proc/<pid>/stack和dmesg的输出保存下来，找内核相关的原因。
4.2 僵尸进程：为什么退出后一直赖着不走
僵尸进程是另一个高频问题。它本身不占 CPU、不占内存，唯一的消耗是进程表项。但它的存在暴露了父进程的代码问题：子进程退出后，父进程没有调用 wait 或 waitpid 来回收。
最直观的排查命令：
ps -eo pid,ppid,stat,comm | grep defunct # 12346 12345 Z [myapp] <defunct>第三列是 Z，COMMAND 里带<defunct>。这时候要看 PPID，也就是 12345，去确认父进程是谁。
处理思路有优先级：
- 先判断僵尸是不是持续产生。如果只是一两个且不再增加，风险不大，等父进程重启时自然清理。
- 如果父进程是长期运行的服务，并且僵尸持续增加，最终 PID 可能会耗尽，新进程 fork 不出来，这种必须处理。
- 能重启父进程就直接重启，重启后 1 号进程会继承这些僵尸并统一回收。
- 不能重启的情况下，尝试给父进程发送
SIGCHLD：kill -SIGCHLD <ppid>，如果父进程正确监听了 SIGCHLD 并且 wait，可能会被触发清理。注意前提是父进程的信号处理逻辑写得对。 - 不要试图 kill 僵尸本身，它已经死了，任何信号都无效。
更根本的解决方案在代码层。编写负责派生子进程的程序时，应正确设置 SIGCHLD 信号处理函数，或者循环调用 waitpid。甚至简单粗暴一点，把 SIGCHLD 置为 SIG_IGN，内核会自动回收子进程残留：
#include <signal.h> int main() { // 忽略 SIGCHLD，让内核自动回收子进程 signal(SIGCHLD, SIG_IGN); // 后续正常 fork 即可 return 0; }这个做法在 Linux 下有效，历史上有一些系统对 SIG_IGN 行为略有差异，但现在主流内核都没问题。
4.3 容易被忽视的 T 状态排查
T 状态一般不会引发故障，但如果某个服务进程突然变成 T，服务就“假死”了。常见的触发原因：
- 在终端里按了
Ctrl+Z，把前台进程组挂起。用jobs查看，用fg或bg恢复。 - 有人对进程执行了
kill -STOP。这种可以用kill -CONT恢复。 - 调试器 attach 导致进程停在断点。用 gdb 执行 continue 或者 detach。
排查 T 状态时，ps看 STAT 是否带t或者T，然后对照父进程和 TTY 判断诱发原因。如果完全找不到原因，strace -p <pid>也能看到进程是否被 ptrace 挂住。
5. 状态排查实用速查表与我的避坑经验
5.1 常用排查命令组合
工具记住一套就够用，关键在于组合起来用。我把常用的命令贴在这里，方便直接抄作业：
# 1. 总览系统整体负载和 CPU/IO 状态 top htop # 2. 查看所有进程状态分布 ps -eo stat | sort | uniq -c | sort -rn # 3. 精确查找 D 和 Z 状态 ps -eo pid,ppid,stat,wchan:32,comm --sort=pid | awk '$3 ~ /^D|^Z/ {print}' # 4. 看单个进程详细信息 cat /proc/<pid>/status cat /proc/<pid>/wchan cat /proc/<pid>/stack # 5. 持续监控状态数量 watch -n 1 'ps -eo stat | sort | uniq -c' # 6. 磁盘 IO 瓶颈确认 iostat -x 1 # 7. 动态追踪单个进程系统调用 strace -p <pid>5.2 六种状态速查表
| 状态 | STAT 列 | 内核宏 | 触发场景 | 处理建议 |
|---|---|---|---|---|
| R | R | TASK_RUNNING | 正在运行或等待 CPU 调度 | 数量多且负载高说明 CPU 紧张 |
| S | S | TASK_INTERRUPTIBLE | 等待 IO、定时器，可被信号唤醒 | 正常状态，无需处理 |
| D | D | TASK_UNINTERRUPTIBLE | 不可中断 IO、NFS、swap 等 | 定位 IO 瓶颈，不要盲目 kill |
| T | T | TASK_STOPPED | 收到 STOP 系列信号 | 使用 CONT 恢复或确认是否故意停止 |
| t | t | TASK_TRACED | 被调试器 ptrace 挂住 | gdb continue/detach 恢复 |
| Z | Z | EXIT_ZOMBIE | 进程已退出但父进程未 wait | 修复父进程或重启父进程 |
5.3 几条我个人比较受用的实践原则
第一点，永远先区分“CPU 忙”和“系统忙”。load average 是 R + D 状态进程数量的近似体现，CPU 使用率再低，只要 D 状态进程扎堆，系统照样“忙到瘫痪”。所以排查负载问题时，一定要先看状态分布，而不是盯着 CPU%。
第二点，给进程做健康检查时不要只看“进程还在不在”，要看状态是否健康。我写过不少监控脚本，判断条件不是简单的process_exists，而是ps -o stat= -p $pid是否落在允许集合内。比如 MySQL 的 mysqld 如果长时间处于 D 状态，即使进程还在，业务其实已经停了。
第三点，写服务端程序时，进程回收逻辑一定要提前想清楚。很多线上僵尸进程的根源，就是程序员只 fork 不 wait，以为操作系统会自动处理。在多进程模型里，SIGCHLD 的处理和 waitpid 的调用不是可选项，是必选项。
第四点，/proc/<pid>/status里的上下文切换计数值得重视。voluntary_ctxt_switches 增长快说明进程经常主动让出 CPU，常见于 IO 密集；nonvoluntary_ctxt_switches 增长快说明时间片经常被强占，常见于 CPU 密集或优先级过低。这些数据配合状态流转，比单纯看某个时刻的状态更能反映进程的行为模式。
最后再分享一个小技巧。当你怀疑某个进程状态在频繁跳变，但用ps只能看到某一瞬间的快照时，可以用一小段 shell 把它盯住：
while true; do ps -o pid,stat,comm -p <pid>; sleep 0.5; done或者直接连续抓取多次状态，统计各种状态出现的频率。这个办法看着土，但在定位偶发性能抖动和调度异常时特别管用——状态本身就是一个动态过程，多抓几个时间点，往往比盯着一个瞬间的截图更容易看出门道。
