Day 02 · 进程深入：生命周期与状态机

1. task_struct：进程在内核里长什么样

昨天提了一句，每个进程在 Linux 内核里都对应一个叫 task_struct 的 C 结构体。今天我们认真看一眼这个东西，因为之后所有讨论都围绕它。

定义在 include/linux/sched.h，整个结构体 ~3000 行、200+ 字段，但你不需要全记，只需要理解 5 组关键字段：

struct task_struct {
    /* ── 组 A：身份标识 ── */
    pid_t            pid;            // 进程/线程 ID（每个 task 唯一）
    pid_t            tgid;           // 线程组 ID（同进程的所有线程共享）
    struct task_struct *real_parent; // 真实父进程指针
    struct task_struct *parent;      // 当前父进程（可能被 ptrace 改）
    struct list_head children;       // 子进程链表
    struct list_head sibling;        // 同父进程下兄弟链表

    /* ── 组 B：当前状态 ── */
    long             state;          // R / S / D / T / Z（下一节详谈）
    int              exit_state;     // 退出时的状态
    int              exit_code;      // 退出码（main 返回值）
    int              exit_signal;    // 被什么信号杀死的

    /* ── 组 C：资源持有 ── */
    struct mm_struct      *mm;       // 地址空间（页表、各段位置）
    struct files_struct   *files;    // 打开的文件描述符表
    struct signal_struct  *signal;   // 信号处理函数表
    struct fs_struct      *fs;       // 工作目录、umask

    /* ── 组 D：身份与权限 ── */
    const struct cred *cred;         // UID/GID/capabilities

    /* ── 组 E：调度与时间 ── */
    unsigned int     policy;         // SCHED_NORMAL / FIFO / RR
    int              prio, static_prio, normal_prio;
    struct sched_entity se;          // CFS 调度实体（含 vruntime）
    u64              utime, stime;   // 在用户态/内核态累计的 CPU 时间

    /* … 还有 namespace、cgroup、ptrace、性能计数器等等 100+ 字段 */
};

记几个对今天有用的细节：

• pid vs tgid：在 Linux 内核眼里，线程也是 task。同一进程的多个线程，每个有自己的 pid（独一无二），但它们共享同一个 tgid（等于线程组里第一个线程的 pid，也就是用户视角的「进程 ID」）。所以你 ps 看到的「进程 PID」其实是 tgid。
• real_parent vs parent：通常一样，但被 strace/gdb ptrace 之后 parent 会指向调试器。后面 wait 信号传递时只看 real_parent。
• mm 字段：指向 mm_struct，里面记录了进程的虚拟地址空间布局（昨天讲的 text/data/heap/stack 各段起止地址、页表入口）。线程共享同一个 mm_struct——这就是「线程共享内存」的实现机制。

所有这些字段加起来，平均一个进程的 task_struct 大约占 10-20 KB 内核内存。你机器上跑 500 个进程，内核就为此用掉 5-10 MB——这是"进程"的固定成本，也是为什么"轻量线程""协程"在高并发场景下被青睐。

2. 进程状态机：R / S / D / T / Z 五个字母的全部秘密

进程不是一直在跑的。它在生命周期里在几个状态间反复切换。当你 ps aux 看到 STAT 列（mac 上也叫 STAT），那个字母就是当前状态。

3. fork：复制一个完整的进程

Linux 创建新进程不是「凭空造一个」，而是「复制一个现成的」。这就是 fork() 系统调用。它的语义非常特别：

#include <unistd.h>
pid_t fork(void);

调用 fork() 一次，返回两次——一次在父进程里返回（值是新创建的子进程 PID），一次在子进程里返回（值是 0）。第一次见这个 API 几乎所有人都会楞住。Python 里大概是这样：

import os

pid = os.fork()       # ← 这一行神奇地"分裂"了

if pid == 0:
    # 这段代码在子进程里执行
    print(f"我是子进程，PID={os.getpid()}，我妈是 {os.getppid()}")
    os._exit(0)
else:
    # 这段代码在父进程里执行
    print(f"我是父进程，PID={os.getpid()}，我刚生了个孩子 PID={pid}")
    os.waitpid(pid, 0)  # 等子进程死透

fork 后的子进程是父进程的近乎完美的克隆：

• 地址空间完全一样（同样的 text/data/heap/stack 内容）
• 所有打开的文件描述符（包括同一个 socket 连接，引用计数 +1）
• 同样的环境变量、工作目录、用户身份
• 从同一行代码继续执行（PC 一样）

父子的差异只有几个：PID 不同、ppid 不同、fork 返回值不同、CPU 时间累积清零。

为什么 Linux 设计成 fork + exec 两步走

表面看这很奇怪——既然要起一个新程序，为什么不直接「创建+加载」一步到位（像 Windows 的 CreateProcess）？答案是灵活性。fork 完之后、exec 之前，你有一个珍贵的窗口：子进程已经是一个独立 task，但还没变成目标程序。你可以在这个窗口里：

• 关掉一些不该继承的文件描述符
• 切换用户身份（setuid 降权）
• 改环境变量
• 设置资源限制（rlimit）
• 挂到一个 cgroup 里限制 CPU/内存
• 进入新的 namespace（容器的核心机制）

所有这些「准备工作」做完，再 exec 真正的目标程序——目标程序生来就在受限环境里。这就是 Docker、K8s、systemd 创建容器/服务的标准模式。如果是一步到位的 CreateProcess，你就没机会做这些事。

4. 写时复制 COW：为什么 fork 不慢

读到这里你应该有个疑问：fork 要复制整个地址空间，一个 10GB 内存的进程 fork 一下不就要复制 10GB 吗？那 fork 不就慢死了？

答案是 Copy-On-Write（写时复制，COW）。Linux 不真的复制内存，它只复制页表，然后把所有页都标成「只读」。父子两个进程指向同一份物理内存。

这个机制的妙处是：

1. fork 本身 O(进程页表大小)，跟实际内存使用量基本无关。一个 10GB 进程 fork 跟一个 10MB 进程 fork 一样快（~微秒级）。
2. 如果 fork 后立即 exec，根本不会触发任何复制——exec 会丢弃旧地址空间装载新程序，浪费的页全部回收。这就是 fork+exec 模式高效的根本原因。
3. 父子如果都是只读访问（比如读同一份模型权重），物理内存只有一份。这就是为什么 vLLM、DataLoader 用 fork 起 worker 比 spawn 省内存——子进程能"白嫖"父进程已经加载的模型权重，直到它们写入才会真正复制。

5. exec：把当前进程「变身」

exec 是一个系统调用家族（execve、execvp、execl 等，glibc 提供的方便变体），核心是 execve()：

int execve(const char *path,           // 可执行文件路径
           char *const argv[],         // 命令行参数
           char *const envp[]);        // 环境变量

它做的事简单粗暴：用一个新程序替换掉当前进程的所有代码和数据。具体来说：

1. 检查可执行文件的权限、ELF 头合法性
2. 检查 setuid / setgid 位，必要时切换权限
3. 丢弃当前进程的整个地址空间（mm_struct 整个重建）
4. 把新可执行文件的 text/data 段 mmap 到新地址空间
5. 把命令行参数和环境变量复制到新栈顶
6. 把 PC 设到新程序的 entry point（动态链接器 ld-linux.so）
7. 从那里开始执行

注意 execve 成功就不返回——返回到哪里去呢？原来的代码已经被覆盖了。只有失败（比如文件不存在）才会返回 -1。

什么东西在 exec 之后保留？task_struct 自己（pid、ppid、children 关系）、已打开的文件描述符（除非设了 O_CLOEXEC）、信号 mask、cgroup/namespace 归属、资源限制 rlimit。什么东西被清掉：地址空间、信号处理函数（除了忽略的 SIG_IGN）、内存锁。

6. wait / waitpid：回收子进程

父进程通过 wait 家族系统调用「等待」子进程结束并回收其残余资源：

pid_t wait(int *status);                        // 等任意一个子进程
pid_t waitpid(pid_t pid, int *status, int options); // 等指定子进程，可非阻塞
int waitid(idtype_t, id_t, siginfo_t*, int);    // 更通用的版本

关键点：

• 父进程必须调 wait 才能得到子进程的退出码（status 里编码），否则丢了。
• wait 不仅是"得知结果"，更是回收子进程的 task_struct。子进程 exit 时它不是立刻消失，而是变成 Z 状态，等父进程 wait 才彻底释放。
• 用 WNOHANG 选项可以让 waitpid 非阻塞——"如果子进程还没死就立刻返回，别等"。

# Python 里典型用法
import subprocess

p = subprocess.Popen(['sleep', '1'])
return_code = p.wait()      # 阻塞直到子进程结束，自动 reap

# 或者非阻塞轮询
while p.poll() is None:     # poll() 内部用 waitpid + WNOHANG
    print("还在跑...")
    time.sleep(0.1)

7. 僵尸进程与孤儿进程

僵尸（Zombie）

子进程 exit 之后到父进程 wait 之前的这段时间，子进程的状态是 Z。它"已经死了，但还没下葬"：

• 地址空间已经被回收（不占内存）
• 但 task_struct 还在（占几 KB 内核内存 + 一个 PID）
• 状态字段记录了退出码，等父进程来取

正常情况僵尸状态非常短，父进程一 wait 就消失。但如果父进程写得不规范——比如开了很多子进程从不 wait——僵尸就会堆积。一旦堆到系统 PID 上限（/proc/sys/kernel/pid_max，通常 32768），系统就再也 fork 不出新进程，整个机器瘫痪。

# 查系统现存僵尸
ps aux | awk '$8 ~ /Z/ { print }'

# 或者
ps -eo pid,ppid,state,comm | grep ' Z '

孤儿（Orphan）

如果父进程先于子进程死掉（不管是正常退出还是被 kill），子进程就成了「孤儿」。孤儿不会立刻死，但它没爸了，谁来 wait 它？

Linux 的答案：所有孤儿被自动过继给 PID=1 的 init 进程（现代发行版上是 systemd）。init 的设计职责之一就是「永远在循环 wait()」，所以孤儿一旦 exit 立刻被收尸，不会变成僵尸。

这个机制非常重要——它保证系统永远不会因为孤儿堆积而垮掉。但有个陷阱：

8. 进程组与会话（简介）

这部分日常用不上，但你做信号处理、终端交互时会撞到，先建立概念，将来需要再深挖：

• 进程组（Process Group）：一组相关的进程，由一个 process group leader 领导。在 shell 里你跑 cat file | grep foo | wc，这三个进程是同一个进程组。这样设计是为了批量发信号——你按 Ctrl-C，shell 给整个前台进程组发 SIGINT，所有进程一起退出。
• 会话（Session）：一组进程组，通常对应一次"登录会话"。一个 session 关联一个控制终端，关闭终端时 session 里所有进程组会收到 SIGHUP。nohup 命令就是为了让进程脱离 session，避免被这个信号杀掉。
• 守护进程（daemon）：脱离了所有控制终端的后台进程。创建一个 daemon 的标准 11 步流程（fork、setsid、再 fork、chdir、umask、关闭 fd…）就是为了切干净这些关系，让进程独立于任何 session 存活。

想跑实验？在 mac 终端跑 ps -j，看 PGID 和 SID 两列，它们就分别是进程组和会话 ID。

📝 今日小练习

# zombie_demo.py
import os, time

pid = os.fork()
if pid == 0:
    # 子进程：立刻退出
    print(f"child {os.getpid()} exiting")
    os._exit(0)
else:
    # 父进程：故意不 wait，睡 60 秒
    print(f"parent {os.getpid()} sleeping, child pid = {pid}")
    time.sleep(60)
    # （正常的代码应该在这里调 os.waitpid(pid, 0)）

ps -p <子进程PID> -o pid,ppid,state,command
# 你应该看到 state = Z（mac 上可能显示为 ?Z）

strace -f -e trace=clone,execve,wait4,exit,exit_group bash -c 'ls /tmp > /dev/null'