东予薏米不管你是刚装上双系统的小白，还是在公司服务器上被领导一句“看下这个进程咋回事”问懵过的准运维，Linux 的进程管理都是绕不过去的一道坎。说句实话，我见过太多人把 ps 和 top 背得滚瓜烂熟，但真要他解释“进程到底是怎么被创建出来的”，或者“为什么 ps -ef 看不到某个后台任务”，一下就卡壳了。这篇我不打算搞成 man page 翻译，就按我实际排查问题时的思路，把进程的“查看”和“创建”这两件事彻底聊透，顺便把那些文档里不写、但实战里特别容易踩的坑一并倒出来。
这篇内容适合刚接触 Linux 的朋友，也适合那些已经会用几条命令、但想系统补一下底层逻辑的同学。我会尽量用大白话讲清楚原理，再配上可以直接抄作业的命令和代码。跟着操作一遍，你再看到进程相关的报错或者诡异现象，至少心里不慌。
1. 先搞懂进程到底是什么：从“程序”到“进程”的关键一步
1.1 程序是菜谱，进程是做饭的过程
很多人一开始会把“程序”和“进程”搞混，我习惯用一个做饭的类比：程序就是躺在硬盘上的菜谱文件，它不占内存、不消耗 CPU，就是一个静态的文本；而进程是你按照菜谱实际开火做饭的整个过程——你需要占着灶台（CPU）、占着案板（内存）、还要时不时看看锅（系统调用）。
当你执行 ./myapp 或者 python test.py 时，操作系统干的事不是简简单单把文件里的指令丢给 CPU，而是先做一系列准备动作：读取程序文件、分配内存空间、建立内核里的数据结构、把入口地址准备好，最后才让 CPU 跳进去执行。这个由内核创建并管理的“运行时实体”，就是进程。
那内核凭什么认识这么多进程？靠的是进程控制块（Process Control Block，PCB）。Linux 里具体实现叫 task_struct，你可以把它理解成每个进程在系统里的“户口本”或者“档案袋”。里面装着 PID（进程号）、PPID（父进程号）、状态、打开的文件、内存布局、信号处理设置等一系列信息。内核就是靠这张档案来调度、管理和回收进程的。所以你在用户态看到的 ps 输出，本质上就是内核把这一堆档案整理之后展示给你看。
1.2 进程状态机：不只是“死”和“活”这么简单
进程跑起来之后，不会永远待在“运行”状态。我在排查问题的时候，最常盯着看的除了 CPU 占用，还有进程的 state。Linux 里进程状态用单个字母表示，每个字母背后都是一整套调度器的逻辑。
R（Running/Runnable）：进程正在运行，或者在运行队列里随时可以运行。注意，top里看到R不代表它一定占着 CPU，可能是排队等着调度。S（Sleeping，可中断睡眠）：进程在等待某个事件，比如等你输入、等磁盘 IO 返回。这是最常见的一种正常状态，我管它叫“眯一会儿”。D（D state，不可中断睡眠）：进程在做磁盘 IO 等不可被打断的操作。如果系统里大量进程卡在D，那大概率是磁盘或网络存储出了问题，这时候连kill -9都未必好使。T（Stopped）：进程被暂停了，通常是收到SIGSTOP或者Ctrl+Z。可以通过fg/bg 恢复。Z（Zombie，僵尸）：进程已经退出，但父进程还没收尸，也就是没调用wait/waitpid去读取它的退出状态。这个状态是新手最容易恐慌的，其实没那么可怕，后面我会专门讲。
这几个状态对应了我在排查“进程假死”“进程卡住”时的基本判断方向。比如你发现某个任务半天没反应，先别急着 kill，先看一眼它是不是 D 状态在等 IO，还是 S 状态在等锁。
1.3 进程树：所有进程都有爹
Linux 里的进程不是凭空蹦出来的，它是被另一个进程“复制”出来的。系统启动时，内核会手动创建第一个进程，叫 init（现在大多数发行版是 systemd），PID 为 1。之后所有进程，都是 PID 1 直接或间接 fork（复制）出来的。
这就是为什么你可以用 pstree 看到一棵层级分明的进程树：
bash复制systemd─┬─NetworkManager─┬─dhclient
│ └─2*[wpa_supplicant]
├─sshd───sshd───bash───vim
├─nginx───2*[nginx]
└─postgres───postgres
父子关系在实际排查里非常关键。比如你 kill 了一个服务的主进程，但它的子进程可能还活着变成孤儿进程，最终被 PID 1 收养。尤其是用 Supervisor 或者 systemd 管理服务的时候，理解“父进程退出，子进程被收养”这套机制，能解释很多“我明明停了服务，端口怎么还开着”的诡异现场。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 查看进程的两把刷子：ps 命令与动态视图
2.1 ps 的三个常用姿势：-ef、aux、-eo 到底啥区别
ps 是 process status 的缩写，也是绝大多数人查看进程的第一道门。但网上资料一搜，一会儿 ps -ef，一会儿 ps aux，一会儿又是 ps -aux，新手直接懵圈。我先把这三者的区别讲清楚。
ps -ef 是 System V 风格，输出是标准格式。ps aux 是 BSD 风格，用 u 显示用户和 CPU/MEM 占比，a 显示所有终端进程，x 显示没有终端控制的进程。ps -aux 其实是个历史误解——在 Linux 上它会被解析成 ps -a -u -x，结果恰好能跑，但严格说不是标准用法。所以我的建议是：想快速看全量进程，用 ps -ef；想带上资源占用看，用 ps aux。
再看输出内容。拿 ps aux 举例：
bash复制USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 178752 13504 ? Ss Feb10 0:15 /usr/lib/systemd/systemd
ubuntu 4321 3.2 1.5 364512 125600 ? Sl 09:30 0:42 python3 train.py
VSZ：虚拟内存大小，进程“假装”占了多少内存。RSS：实际物理内存大小，这个更接近真实占用。STAT：前面说的状态字母，后面可能还有附加字符。比如Ss表示它是 session leader 且在睡眠，Sl表示它是多线程进程且在睡眠。TIME：进程累计消耗的 CPU 时间，不是启动到现在的时间。
我平时用得最多的其实是自定义格式，ps 支持 -eo 按需指定字段，方便一眼看到关键信息：
bash复制ps -eo pid,ppid,user,stat,etime,%cpu,%mem,cmd --sort=-%cpu
--sort=-%cpu 按 CPU 占用降序排，etime 显示启动后经过的时间。这条命令在排障时基本是标配。如果你觉得输出列太宽，也可以把 cmd 换成 comm，后者只显示命令名不显示参数。这一点尤其适合在服务器上快速定位“到底是哪个 python 脚本吃满了 CPU”。
2.2 top 与 htop：从静态快照到实时监控
ps 适合“看一眼当前快照”，但如果你想持续观察进程状态变化，就要靠 top。top 本身是个交互式工具，运行后默认每 3 秒刷新一次，按 P 按 CPU 排序，按 M 按内存排序，按 k 可以输入 PID 杀进程，按 r 是可以改优先级（renice），按 q 退出。这几个快捷键我闭着眼都能按出来，实战中几乎天天用。
top 上半部分的 load average 是三个数字，分别代表过去 1 分钟、5 分钟、15 分钟的平均负载。很多新手以为负载高就是 CPU 高，其实不准确。负载是处于 R 状态和 D 状态的进程数的平均和。也就是说，如果进程大量阻塞在磁盘 IO（D 状态），负载也会飙升，但 CPU 可能很空闲。判断思路要分开，别一看到负载高就去加 CPU。
htop 是 top 的增强版，界面更友好，支持鼠标操作，还可以用 F5 切换成进程树模式，直观看到父子关系。不过默认发行版里未必自带，需要 apt install htop 或 yum install htop。我在自己笔记本上喜欢用 htop，但在生产服务器上反而更常用原生 top，因为最小化安装的服务器上未必允许你随便装包。
2.3 按名字找进程：pgrep 与 pidof 的高效技巧
有时候你不想看一大堆进程，只想快速找到某个程序对应的 PID。手写 ps -ef | grep nginx 当然可以，但更干净的方式是用 pgrep：
bash复制pgrep -a nginx
-a 会同时打印进程名和完整命令行。如果你在脚本里需要判断一个服务是否在运行，可以这样：
bash复制if pgrep -x nginx > /dev/null; then
echo "nginx is running"
fi
-x 表示精确匹配进程名，避免把 nginx 和 nginx-worker 混淆。pidof 作用类似，但直接输出一行 PID，适合赋值给变量：
bash复制pidof nginx
另外还有个日常排障组合：一条命令把端口和进程对应起来。比如 8080 端口被占，用 lsof -i:8080 或 ss -lntp | grep 8080，能直接看到 PID 和进程名。这个方法在“端口冲突”这种经典问题上非常救命，后面的常见问题部分我再展开讲。
3. 创建进程的几种姿势：前台、后台与守护进程
3.1 最朴素的创建：直接在命令行跑起来
在 Shell 里输入 ./app 回车，其实相当于做了一个“在前台创建进程”的操作。Shell 会调用系统的 fork 和 exec 系列函数，先把自己复制一份，再用新程序替换这个副本的映像，从而把新进程跑起来。前台进程最大的特点是：它占着当前终端，期间你没法在同一终端继续输入别的命令。
前台跑一个耗时任务时，我常用的急救招数是 Ctrl+Z，它会把进程发送 SIGTSTP 信号挂起，然后回到 Shell。这时候用 jobs 可以看到挂起的任务，用 bg 把它放到后台继续跑，用 fg 把它拉回前台。这套组合在处理“跑了一半才发现忘了加 nohup”的场景时特别好用，不需要重跑。
举个实际场景。你直接跑了个 python manage.py runserver，这时想临时执行别的命令，但不能开新终端，怎么办？
bash复制# 按 Ctrl+Z 挂起当前任务
^Z
[1]+ Stopped python manage.py runserver
# 放到后台继续跑
bg 1
# 再想看它状态，用 jobs
jobs -l
这种方式创建的和执行命令时直接 & 符号创建的进程，本质上都是从当前 Shell 这个父进程派生出来的子进程，它们的父进程都还是你的 Shell。
3.2 让进程真正“脱离”：后台、nohup、setsid 与 disown
很多人在关闭终端后发现自己的程序也挂了，于是开始用 nohup 和 &。但你真的理解它在解决什么问题吗？
& 只是把进程放到后台，但它的父进程仍然是当前 Shell。一旦关闭终端，Shell 退出时会向它的子进程发送 SIGHUP 信号，默认动作就是终止进程。nohup 的作用就是让子进程忽略 SIGHUP 信号，所以即使终端关掉，它也能继续跑：
bash复制nohup python train.py > train.log 2>&1 &
注意 > train.log 2>&1 这步很重要。不重定向的话，进程往终端的输出可能因为终端关闭而报错。标准错误和标准输出都指向同一个日志文件，后续排查靠它。
setsid 则是更彻底的一种方式，它会让新进程开一个全新的会话（session），完全脱离控制终端，相当于从“无爹”状态开始。用 setsid 启动的进程不依赖任何终端，也不怕 SIGHUP。比如：
bash复制setsid python server.py > server.log 2>&1
disown 则是“事后补救”。如果某个任务已经在前台跑起来了（或者后台跑了还没脱离），你可以用 disown 把任务从 Shell 的任务表中移除，之后即使关掉终端，Shell 也不再把它当子进程管理，理论上不会因为 Shell 退出而被 SIGHUP。但要注意，如果你用 disown 处理的是已经挂起的任务，最好先 bg 让它继续跑，再 disown。
3.3 从代码层面创建进程：fork 与 exec 的心法
命令行只是调用者，真正创建进程的能力在内核和系统调用里。Linux 创建进程的核心是 fork 和 exec 这套组合拳。
fork() 的作用是“复制当前进程”，父进程调用一次，返回两次：在父进程里返回子进程的 PID，在子进程里返回 0。如果在子进程里返回 -1，则说明创建失败。这一步复制出来的子进程会拥有父进程的内存映像、文件描述符表、环境变量等。
exec() 族函数（execl、execvp 等）则负责“干正事”，把当前进程的内存映像替换成新程序的二进制内容，然后从新程序的入口点开始执行。
所以标准流程是：先 fork 一份，再在子进程里调用 exec 去执行新程序。这也是为什么很多大服务（比如 Nginx）可以做到“主进程负责监听，子进程负责干活”——主进程先 fork 出多个子进程，每个子进程各自接受连接，共享监听 socket。
我给初学者看 C 伪代码的话，一般会这样写：
c复制#include <stdio.h>
#include <unistd.h>
int main() {
pid_t pid = fork();
if (pid < 0) {
perror("fork failed");
return 1;
} else if (pid == 0) {
// 子进程
printf("I am child, PID=%d\n", getpid());
} else {
// 父进程
printf("I am parent, PID=%d, child PID=%d\n", getpid(), pid);
}
return 0;
}
编译运行后，你会看到父子进程各打印一行。用 ps -ef --forest 能看到它们之间的树形关系。对于不想碰 C 的 Python 朋友，os.fork() 也是同样的语义；更现代化一点的方案是 multiprocessing 或 subprocess，它们内部封装了 fork/spawn 的细节，用起来省心很多。但理解 fork 这个底层机制，对排查分布式任务系统里的诡异父子问题很有帮助。
4. 实操Demo：从一条命令到一个“带子进程”的小程序
4.1 场景搭建：拿什么练手最方便
这个部分我建议你开一个虚拟机或者随便一台 Linux 机器，跟着敲一遍。练手程序不用太复杂，重点是最小化地复现“创建-观察-管理”的闭环。
我常用的练手流程是这样：启动一个自己写的 Python 脚本，让它每 2 秒打印一行日志，顺便睡一会儿。这个脚本的作用是充当“可观察的进程”。名字就叫 demo_proc.py：
python复制#!/usr/bin/env python3
import time
import os
print(f"demo_proc started, PID={os.getpid()}")
while True:
print(f"{time.strftime('%Y-%m-%d %H:%M:%S')} I am alive, PID={os.getpid()}")
time.sleep(2)
这个脚本简单直观，且是前台运行，方便你理解进程生命周期。你可以把它跑在前台，用 Ctrl+Z 挂起，用 bg 放到后台，再用 ps 去验证状态变化。
4.2 复现一个“父子进程”的完整链路
如果你想亲眼看父子进程长什么样，可以编译刚才那段 C 代码。假设文件叫 fork_demo.c：
bash复制gcc fork_demo.c -o fork_demo
./fork_demo
运行完你可能什么都看不到，或者看到两行混在一起的输出。这是因为父子进程的打印顺序不确定，而且 printf 可能被缓冲。想看到更明确的树形关系，可以用下面的方式：
bash复制# 让子进程等待一段时间，方便观察
# 在 fork_demo.c 里子进程分支加个 sleep(30)
等进程还在“存活”的窗口期，马上开另一个终端执行：
bash复制ps -ef --forest | grep -A2 -B2 fork_demo
这时你应该能看到类似这样的输出：
bash复制ubuntu 10123 1 0 10:00 ? 00:00:00 ./fork_demo
ubuntu 10124 10123 0 10:00 ? 00:00:00 ./fork_demo
第二行的 PPID 是第一行的 PID，说明二者是父子关系。如果你在这时把父进程 kill 10123，子进程并不会自动退出，它会被 PID 1 收养，变成“孤儿进程”，然后在后台继续干它自己的事。这是很多服务做守护化（daemonize）的一个底层逻辑：为了防止子进程被终端 SIGHUP 搞死，可以先 fork，然后让父进程退出，子进程被 init 收养，从而脱离原会话。
4.3 查看已创建进程的关键信息：/proc 这个“进程博物馆”
ps 和 top 的输出都来自 /proc 虚拟文件系统。Linux 会把每个进程的运行信息以目录形式暴露在 /proc/<PID>/ 下，相当于一个只读的“进程博物馆”。
排查进程问题时，我经常直接看这几个文件：
/proc/<PID>/status：进程状态、PPID、内存、线程数等摘要信息。/proc/<PID>/cmdline：完整的命令行参数，多个参数以\0分隔，可以用tr '\0' ' '转成可读格式。/proc/<PID>/cwd：进程当前工作目录的软链接，有时候排查某个进程“到底在哪个目录跑起来的”特别有用。/proc/<PID>/fd/：进程打开的文件描述符列表，里面可以看到它打开了哪些文件、哪些 socket。
举个例子，你的 Python 训练脚本 PID 是 12345，想确认它当前工作目录：
bash复制ls -l /proc/12345/cwd
readlink /proc/12345/cmdline | tr '\0' ' '
这种细颗粒度的查看方式，在“多个同名进程”“定位实际运行路径”这类问题上特别好使。ps -ef 有时候只能看到命令名，但结合 /proc 能挖到更多上下文。
5. 新手最容易踩的进程坑：常见问题与排查思路
5.1 启动后进程秒退，ps 里根本看不见
这是我被问过最多的一个问题：“我明明执行了 ./myapp 或者 python xxx.py，但 ps 就是看不到它，它去哪了？”
答案大概率是：进程启动后因为某种原因立即退出了。比如 Python 脚本里有个 FileNotFoundError，运行时崩溃，进程退出了，ps 自然看不到。所以排查顺序应该是：
- 先看你启动时终端输出的错误信息。这是第一手信息，往往直接提示缺文件、缺依赖、端口被占。
- 如果进程是后台跑的，立刻看日志文件。比如
nohup启动的，看nohup.out；重定向到别的日志，看对应日志。 - 如果进程还在，但
ps看不到，考虑它是否换了一个身份运行。比如你用 systemd 启动的服务，实际进程可能是USER=nginx的 nginx worker，用ps aux | grep nginx而不是只 grep 你的命令名。
还有一种很隐蔽的情况：你 grep 的时候把 grep 自己也匹配进去了。比如 ps -ef | grep myapp，如果输出只有一行 grep myapp，那就是没有这个进程。这时候可以用 pgrep -a myapp 避免误判。
5.2 进程怎么杀都不死：僵尸进程和不可中断睡眠
看到一大片 Z 状态的进程，新手通常会慌：“这是不是中毒了？”其实僵尸进程没那么可怕。它代表进程已经退出，只是内核还没有释放它的进程描述符，因为父进程还没调用 wait() 来获取它的退出码。僵尸进程不占 CPU 不占内存，也不能被 kill -9 杀掉（因为人家已经死了），它只是占了内核里的一点空间等待收尸。
解决办法一般是：找到它的父进程，确认父进程是否有 bug，然后重启或通知父进程去回收。如果父进程意外退出，僵尸进程会被 PID 1 收养并回收。所以最粗暴的修复手段就是：把父进程 kill 掉。比如：
bash复制ps -ef | grep defunct
# 找到父进程PID
pstree -p <父进程PID>
# 确认后kill掉父进程
kill <父进程PID>
D 状态则更棘手。它通常表示进程正在做不可中断的内核态操作，比如等待网络文件系统响应。如果系统负载高且大量进程卡在 D，常见原因有：NFS 挂载点失效、磁盘损坏、IO 子系统卡死。此时连 kill -9 都无效，只能等待内核操作完成，或者重启系统/修复存储。遇到这种情况别急着盲目 kill，先观察是哪个挂在 /proc/mounts 里的路径出问题了。
5.3 端口被占用但找不到对应进程
这是教科书级的进阶问题。比如你想启动服务，提示 port 8080 already in use，但 ps -ef | grep 8080 什么都搜不到——因为进程名根本不含端口号。
正确姿势是用网络相关命令找：
bash复制ss -lntp | grep 8080
输出里会包含 users:(("nginx",pid=2366,fd=10)) 这样的内容，直接告诉你 PID。如果你的系统是老一点的环境，没有 ss，就用：
bash复制lsof -i :8080
如果 lsof 也没有，可以直接看 /proc 里的 socket inode。但这步对新手有点绕，我还是建议优先把 lsof 装好，它是排查端口问题的利器。找到 PID 后，再决定是 kill 还是去修改配置换端口。
5.4 我自己的排查习惯和常用组合拳
最后分享一套我日常排查进程问题的固定动作，尤其适合服务器环境：
- 先
uptime看负载，判断整体压力。 - 再
top -bn1 | head -20看 CPU 和内存占用最高的进程，-bn1表示非交互式的批处理模式，只输出一次，适合写进脚本。 - 针对性用
ps -eo pid,ppid,stat,etime,cmd --sort=-%cpu | head查看关键进程的父子关系和运行时长。 - 如果有服务异常，看日志时别忘了
journalctl -u 服务名 --since "5 minutes ago"，这比盲目翻文件快得多。
这套组合在绝大多数“进程异常”场景下都能定位到 80% 的问题。我在实际工作中发现，很多所谓的神秘故障，最后都落在“状态没看全”“日志没对上”“父子关系没理清”这三类问题上。
进程管理就是这样，命令本身不复杂，复杂的是你得把这些命令和内核的机制串联起来。你看 ps 的输出时，能想到它在读 /proc；看到 Z 状态时，能想到父进程还没 wait；看到端口占用时，知道去查 socket 归属。这个思维建立起来之后，Linux 在你眼里就不再是一堆零散命令的集合，而是一套自洽的系统。