Linux多进程编程实战：从fork到进程间通信与并发设计

从开发采集服务那次事故讲起。当时A同学负责一个数据汇聚项目，上游有十几个外部数据源要拿取，第一版图省事全部开线程，每个线程拉一个源。结果某个源偶然卡死，连带整个进程崩溃，其余数据源全部中断，日志也没留下多少。排查到最后才发现不是业务逻辑问题，而是多线程共享地址空间带来的脆弱性。后来改成多进程架构，每个数据源一个子进程，哪个挂了拉哪个，主控进程完全不受影响。从那以后，我在Linux下做并发方案设计时，第一个考虑的往往是进程，而不是线程。

这篇文章就把我在【C++|Linux系统编程】多进程及其应用这条路上积累的东西整理出来，内容包括进程到底是怎么创建的、如何正确回收子进程、几种进程间通信方式怎么选型、一个可参考的并发计算Demo，以及我在生产环境中踩过的坑。适合对C++语法有基础、但对Linux系统编程还比较陌生的读者，也适合那些已经会写fork但总在僵尸进程、通信同步上翻车的开发者。

1. 为什么我在Linux下做并发第一选择是多进程

先把这个核心问题说清楚：多进程的价值不是"更高级"，而是"更安全、更好管理"。在很多教科书里，多线程被描述成轻量级的并发方案，听起来比进程省资源、切换快。但真实工程环境里，进程的独立性往往比那点开销重要得多。

1.1 进程在Linux里的真实形态

从内核角度看，一个进程不只是"正在运行的程序"。它包含一个task_struct结构、独立的虚拟地址空间、独立的文件描述符表、独立的信号处理设置、当前工作目录、环境变量等一堆状态。这个独立性意味着两个进程之间默认不共享任何内存，一个进程里段错误崩溃，不会污染相邻进程的内存数据。这也是多进程架构最核心的隔离价值。

C++开发者在写代码时，很容易把"进程"和"程序"混在一起。程序是磁盘上的二进制文件，进程是程序被内核加载后形成的一个动态实例。同一个程序可以同时运行出多个进程，每个进程拥有各自的地址空间，互不干扰。

bash复制# 查看当前系统进程信息
ps -ef
# 查看进程树
pstree

你在终端敲下./a.out，shell会先fork出一个子进程，然后子进程exec加载a.out，最终呈现出来的就是"当前终端多了一个进程"。这套机制在Linux里无处不在，服务启动、命令执行、脚本调用，底层几乎都是fork与exec的组合。

1.2 多进程和多线程的本质差异

网上关于进程线程的对比已经很多了，但真正影响工程决策的其实是这几条。

第一，崩溃隔离能力完全不同。线程共享进程的地址空间，任何一个线程踩了非法内存，整个进程都会收到段错误信号直接退出。进程则不同，子进程崩了只会留下一个终止状态，主进程可以通过wait族函数感知并恢复。第二，清理机制更简单。多线程程序一旦异常退出，线程锁、条件变量、堆都可能处于半初始化状态，重启比修复容易。多进程则可以用"重启子进程"这种粗暴但可靠的方式解决问题。第三，权限和安全隔离。一个进程崩溃不会影响其他进程持有的数据，模块之间天然有边界，这在加载不可信的第三方动态库时尤其重要。

多进程不是没有代价。进程创建开销大，进程间通信需要跨越内核边界，内存不共享导致数据传递要拷贝。但这些代价换来的稳定性收益，在高并发、高可靠的服务里往往非常值得。

1.3 什么场景不该用多进程

我不是说所有并发都要用进程。高频小任务的并行计算，需要共享大块内存做数据交换的场景，多线程协同更合适。多进程适合的是"任务边界清晰、彼此独立、失败可控"的场景：采集任务、请求处理、批量任务分发、沙箱隔离。选型之前先问自己三个问题：子任务崩溃了能不能接受整体退出？任务之间是否需要频繁共享几十GB的缓存数据？进程启动延迟是否能在业务容忍范围内？如果答案是否定的，那该用线程还是要用线程。

2. fork与exec：进程诞生背后的两个关键函数

进程不是自己冒出来的，是另一个进程通过fork“复制”出来的。理解fork的机制，是整篇多进程编程的地基。很多人写不好多进程代码，问题往往出在没搞懂fork之后到底发生了什么。

2.1 fork的返回值逻辑：同一个函数，两种人生

fork调用一次，返回两次。这是一种经典的迷惑行为。父进程里fork返回的是子进程的PID，子进程里fork返回的是0。如果返回-1，说明创建失败。这个设计让同一个代码分支能被两个进程复用：

cpp复制#include <unistd.h>
#include <sys/wait.h>
#include <iostream>

int main() {
    pid_t pid = fork();
    if (pid < 0) {
        std::cerr << "fork failed" << std::endl;
        return 1;
    } else if (pid == 0) {
        // 子进程执行的逻辑：getpid返回自身PID
        std::cout << "child: pid=" << getpid()
                  << " ppid=" << getppid() << std::endl;
        _exit(0);  // 子进程退出，避免继续执行父进程代码
    } else {
        // 父进程执行的逻辑：变量存放的是子进程PID
        int status = 0;
        waitpid(pid, &status, 0);
        std::cout << "parent: child " << pid
                  << " exit code=" << WEXITSTATUS(status) << std::endl;
    }
    return 0;
}

这里有个非常关键的习惯：子进程逻辑结束后一定要调用_exit而不是return。_exit直接执行退出系统调用，不会flush C++标准库的缓冲区；return则会触发析构函数和缓冲清理。在多进程场景下，父子进程各持有一份标准库缓冲区的副本，如果子进程return，会导致缓冲区被刷新两次，输出内容重复、顺序错乱。

2.2 写时复制：fork的延迟拷贝魔法

早期的fork会直接复制父进程整个地址空间，代价惊人。现在的Linux实现采用写时复制（COW）。fork创建子进程时，父子进程共享同一批物理内存页，但页表标记为只读。只要父子都不修改数据，共享就一直持续。一旦有一方写入，内核触发缺页异常，才真正复制这一页内存，写入方拿到自己的私有副本。

这个机制带来的直接好处是：fork一个大量分配但很少修改内存的程序，开销比想象中低得多。很多服务fork完就立即exec，几乎不触碰父进程的堆，所以fork可以做到很轻量。但反过来说，如果父子进程都频繁修改同一块数据区，写时复制会不断触发页复制，性能反而会下降。

2.3 exec族函数：让子进程变成另一个它

fork负责“复制”，exec负责“变身”。exec族函数会用一个新的程序镜像替换当前进程的代码段、数据段、堆和栈，但PID保持不变。这一组函数的区别主要在参数传递方式上：

cpp复制#include <unistd.h>

int main() {
    pid_t pid = fork();
    if (pid == 0) {
        // execlp会在PATH环境变量中查找ls
        execlp("ls", "ls", "-l", nullptr);
        // exec失败才会走到这里
        _exit(127);
    }
    return 0;
}

execl族的参数列表是可变参数，第一个字符串是程序名，后面是参数，结尾要传nullptr。execv族则把参数放进一个数组中。带p后缀的函数会通过PATH搜索可执行文件，不带p的则需要写完整路径。exec替换的只是当前进程的程序内容，文件描述符、PID、当前工作目录这些进程属性默认不会变，除非在exec前设置了对应的标志位。

2.4 vfork与碰不得的历史坑

老代码里偶尔能看到vfork，它曾经的作用是创建一个共享地址空间的子进程，然后子进程立即exec，避免一次完整的地址空间复制。但现在Linux的fork已经用写时复制大幅优化了创建成本，vfork带来的共享父进程内存语义反而极其危险——子进程栈、堆、局部变量全部不独立，在子进程里误改父进程的栈帧，会导致父进程崩溃。

我的建议很简单：新代码一律不要用vfork，全部用fork。如果你维护历史代码发现vfork，优先考虑替换掉，别在它上面加新逻辑。

3. 僵尸进程与孤儿进程：子进程退出的善后工作

子进程结束了，事情就完了吗？远远没有。Linux里一个子进程退出后，内核不会立刻清空它的所有数据结构，task_struct至少还会保留pid、退出码、资源使用统计等信息，等待父进程来“收尸”。如果父进程不做任何处理，这个子进程就会变成僵尸进程。

3.1 僵尸进程是怎么产生的

当一个子进程调用exit或_exit退出时，它会给父进程发送SIGCHLD信号，自己进入TASK_ZOMBIE状态。此时进程的用户空间已经完全清空，但内核里的task_struct还在，因为它要向父进程交代“我的退出码是什么”。父进程调用wait或waitpid，读取退出状态之后，内核才会彻底释放这个进程的所有资源。

如果父进程迟迟不调用wait族函数，僵尸进程会一直挂着。ps命令下能看到一堆状态为Z的进程。这不是内存泄漏那么简单的概念——每个僵尸进程占据一个进程表项，进程号是有限的，积攒到上限后系统就再也无法fork新进程。

bash复制ps -eo pid,ppid,stat,comm | grep -w Z

出现大量Z进程时，第一件事就是去审查父进程的wait逻辑。有些开发者以为"子进程自己退出就行了"，完全没有wait，这在单次fork的Demo里看不出问题，跑时间长了服务器就慢慢僵住。

3.2 wait和waitpid：两种回收姿势

wait是最原始的回收函数，调用时会阻塞，直到任意一个子进程退出。阻塞等待在某些场景下很浪费，但用起来简单：

cpp复制#include <sys/wait.h>
#include <unistd.h>
#include <iostream>

int main() {
    pid_t pid = fork();
    if (pid == 0) {
        std::cout << "child start" << std::endl;
        _exit(42);
    }
    // 父进程阻塞等待任意子进程退出
    int status = 0;
    pid_t r = wait(&status);
    if (WIFEXITED(status)) {
        std::cout << "child(" << r << ") exit code=" 
                  << WEXITSTATUS(status) << std::endl;
    }
    return 0;
}

waitpid则更灵活，可以指定等待哪个PID，也可以用options控制是否阻塞。关键参数是WNOHANG，搭配这个标志位，waitpid在没有子进程退出时立即返回0，让父进程可以继续干别的活：

cpp复制#include <sys/wait.h>
#include <unistd.h>
#include <iostream>

int main() {
    pid_t pid = fork();
    if (pid == 0) {
        sleep(2);
        _exit(7);
    }
    // 非阻塞轮询：每500ms检查一次子进程状态
    int status = 0;
    pid_t r = 0;
    while ((r = waitpid(pid, &status, WNOHANG)) == 0) {
        usleep(500 * 1000);
        std::cout << "waiting..." << std::endl;
    }
    if (r == pid && WIFEXITED(status)) {
        std::cout << "child exit code=" << WEXITSTATUS(status) << std::endl;
    }
    return 0;
}

退出状态里的低位和高位各有含义，别直接printf整个status。用WIFEXITED判断是正常退出还是信号杀死，用WEXITSTATUS取真正的退出码。如果是信号杀死的，可以用WIFSIGNALED和WTERMSIG获取信号编号。

3.3 孤儿进程与SIGCHLD的异步回收

如果父进程比子进程先退出，子进程会变成孤儿进程，被内核托付给PID为1的init进程收养。孤儿进程不是问题，因为init会自动回收它；反倒是父进程没退出、又不wait，才是僵尸问题的根源。

父进程可以先注册一个SIGCHLD信号处理器，在子进程退出时自动执行wait回收，避免主循环轮询。这里要注意一个反直觉的点：信号处理器函数内部能做的事情极其有限，不能调用malloc、free这类非异步信号安全函数。正确姿势是只在handler里做一次waitpid，然后记录状态或者直接退出，把剩余工作交给主循环：

cpp复制#include <csignal>
#include <sys/wait.h>
#include <unistd.h>
#include <iostream>
#include <atomic>

std::atomic<int> child_exit_count = 0;

void on_child_exit(int) {
    int status = 0;
    // 循环回收，避免一个信号到达时其实有多个子进程退出
    while (waitpid(-1, &status, WNOHANG) > 0) {
        child_exit_count.fetch_add(1);
    }
}

int main() {
    struct sigaction sa;
    sa.sa_handler = on_child_exit;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART;
    sigaction(SIGCHLD, &sa, nullptr);

    for (int i = 0; i < 3; i++) {
        pid_t pid = fork();
        if (pid == 0) {
            sleep(1);
            _exit(0);
        }
    }
    // 主循环继续做自己的事
    while (child_exit_count.load() < 3) {
        sleep(1);
        std::cout << "main working, reaped=" 
                  << child_exit_count.load() << std::endl;
    }
    std::cout << "all children reaped" << std::endl;
    return 0;
}

这段代码里用到了sigaction而不是老的signal，因为signal的语义在不同平台上有差异，sigaction能明确指定自动重启被信号打断的系统调用，行为稳定得多。

3.4 子进程里应该调用什么退出函数

子进程退出方式有讲究。C++代码里最常见的错误是在子进程里写return 0或者exit(0)。exit(0)会flush所有标准库缓冲区，触发全局对象析构，还可能多次执行这些操作。多进程环境下每个子进程都有一份父进程拷贝过来的缓冲区副本，如果父进程往stdout写了几行日志还没flush，子进程一exit会把缓冲区内容重复输出一遍。

子进程里最干净的做法是_exit()或_Exit()，它们直接发起退出系统调用，不跑任何用户态清理逻辑。如果你确实需要在子进程里做特殊清理，提前手动调用对应的清理函数，最后再用_exit结束。

4. 进程间通信：管道、共享内存与信号的实际选型

进程隔离带来了稳定，也带来了新的麻烦：两个进程之间怎么传数据？Linux提供的方案很多，管道、消息队列、共享内存、信号、信号量、套接字，各有各的适用边界。选错通信方案，多进程并发比单线程还慢的情况也是真实发生过的。

4.1 匿名管道：最简单但只能单方向传

pipe函数创建一对文件描述符，fds[0]用于读，fds[1]用于写。管道是半双工的，数据从写端流到读端，方向固定。由于管道需要父子进程共享文件描述符，所以必须在fork之前创建：

cpp复制#include <unistd.h>
#include <cstring>
#include <iostream>

int main() {
    int fds[2] = {0, 0};
    if (pipe(fds) != 0) {
        perror("pipe");
        return 1;
    }
    pid_t pid = fork();
    if (pid == 0) {
        // 子进程关闭写端，只保留读端
        close(fds[1]);
        char buf[128] = {0};
        ssize_t n = read(fds[0], buf, sizeof(buf) - 1);
        std::cout << "child received: " << buf << std::endl;
        close(fds[0]);
        _exit(0);
    }
    // 父进程关闭读端，只保留写端
    close(fds[0]);
    const char* msg = "hi from parent";
    write(fds[1], msg, strlen(msg));
    close(fds[1]);
    wait(nullptr);
    return 0;
}

管道有两个很容易踩的坑。第一个，关闭不必要的端。如果不关闭，父进程持有读端，子进程写完后管道就永远无法收到EOF，读端阻塞在read上，程序卡死。第二个，管道有缓冲容量限制，默认通常是64KB，写端写满后继续write会阻塞，一直等到读端消费数据。如果父子进程同时双向写，就很容易互相等待形成死锁。

4.2 命名管道：打破父子关系的限制

匿名管道只能在有共同祖先的进程间使用，不相关进程用不了。命名管道FIFO解决了这个问题，它是文件系统里的一个特殊文件，通过路径名来通信。命令行上最常见的一行用法是：

bash复制mkfifo /tmp/myfifo
# 终端A：写入数据
echo "hello" > /tmp/myfifo
# 终端B：读取数据
cat /tmp/myfifo

FIFO在文件系统里可见，但数据不落盘，内核在内存里维护管道缓冲区。用FIFO做进程间通信时，注意open的阻塞行为：只读方式打开FIFO会阻塞，直到有写方打开；只写方式同理。如果不想阻塞，可以用O_NONBLOCK标志，但读无数据时会立即返回，处理起来要小心。

4.3 共享内存：最快的通道，但必须自己上锁

管道的每一次读写都是一次数据拷贝，进程间数据量一大，性能瓶颈就很明显。共享内存直接把同一块物理内存映射到多个进程的虚拟地址空间，写入方写数据，读取方直接看到，省掉了内核中转。

POSIX共享内存的经典用法是shm_open + ftruncate + mmap。下面这段代码实现了一个父子进程共享内存写入与同步的骨架：

cpp复制#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <cstring>
#include <semaphore.h>
#include <iostream>

int main() {
    // 创建一个共享内存对象
    const char* shm_name = "/demo_shm";
    int fd = shm_open(shm_name, O_CREAT | O_RDWR, 0666);
    if (fd < 0) {
        perror("shm_open");
        return 1;
    }
    ftruncate(fd, 4096);
    // 映射到本进程地址空间
    void* map = mmap(nullptr, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (map == MAP_FAILED) {
        perror("mmap");
        return 1;
    }
    close(fd);

    sem_t* sem = sem_open("/demo_sem", O_CREAT, 0666, 1);
    pid_t pid = fork();
    if (pid == 0) {
        sem_wait(sem);
        snprintf((char*)map, 4096, "child write: %d", getpid());
        sem_post(sem);
        munmap(map, 4096);
        _exit(0);
    }
    sem_wait(sem);
    snprintf((char*)map, 4096, "parent write");
    sem_post(sem);
    wait(nullptr);
    sem_wait(sem);
    std::cout << "final content: " << (char*)map << std::endl;
    sem_post(sem);

    munmap(map, 4096);
    shm_unlink(shm_name);
    sem_unlink("/demo_sem");
    return 0;
}

编译时加-lrt和-lpthread。共享内存本身不提供同步机制，两个进程同时写同一块区域就是灾难。上面代码里用信号量sem_t做互斥保护，读写前后必须成对sem_wait和sem_post。别以为"调试时没出问题"就是正确的，竞态条件本来就是概率性问题。

共享内存还有一个生命周期问题。shm_open创建的名字是内核级对象，关闭文件描述符不会删除它；只有显式调用shm_unlink才会移除。服务器进程重启时最容易遇到的就是泄漏一堆/system/demo_shm这样的残留对象，越积越多。

4.4 信号：事件通知的角色，不是数据通道

信号适合做简单通知，不适合传输数据。进程可以用kill()系统调用给另一个进程发信号，但信号能携带的信息量极小。用它来做"子进程任务完成请处理"的事件通知是可以的，但不能用它传几百字节的业务数据。

生产环境中常见的错误是滥用SIGUSR1/SIGUSR2做业务通信。信号本身会打断进程当前执行流程，在信号处理函数里访问全局数据结构一不留神就出问题。如果只是做命令触发，信号够用；要传复杂结构，走共享内存或管道更稳。

4.5 几种通信方式怎么选

我每次做方案都会列一张表，把通信需求量化一下再决定。

选型的原则是：数据量小但实时性要求高，用管道或消息队列；数据量大、频繁读写，上共享内存+信号量；只是想让对方"知道一件事"，用信号；需要跨机器、跨服务通信，那就直接上套接字，不要绕进程间通信方案。

5. 多进程落地示例：一个简单的并发计算服务

说了这么多原理，这些知识合在一起能做什么？我以一个模拟的批量数据处理任务为例，讲一下完整的多进程方案是怎么组织的。

5.1 业务场景设定

假设有一段需要并发执行的整数计算函数，比如对大量图片做特征值统计的简化版。每个任务互相独立，输入是一批区间参数，输出是计算结果。我们用主进程负责派发任务和汇总结果，多个子进程并行执行计算，每个子进程处理完一个任务后通过管道把结果回传给父进程。

这样一个模型在很多真实项目里都有影子：批处理任务分发、数据采集、日志分析。子进程可以做得花花哨哨，但核心流程是固定的：父进程fork若干子进程，每个子进程循环读取自己的任务描述文件或管道输入，完成计算再回写结果。

5.2 父进程与子进程代码骨架

下面的代码用fork创建两个子进程，每个子进程被分配一组起始偏移量参数。计算完成后通过管道把结构化结果发回父进程。为了演示方便，计算函数简化为计算一个区间内所有整数的和。真正做生产改造时，可以把每段计算替换为实际的图像处理、网络抓取或数据分析任务：

cpp复制#include <unistd.h>
#include <sys/wait.h>
#include <sys/mman.h>
#include <cstring>
#include <iostream>
#include <vector>
#include <sstream>

struct TaskResult {
    int worker_id;
    long sum;
};

long compute_sum(int start, int end) {
    long result = 0;
    for (int i = start; i < end; i++) {
        result += i;
    }
    return result;
}

void worker_process(int worker_id, int start, int end, int pipe_fd) {
    TaskResult r;
    r.worker_id = worker_id;
    r.sum = compute_sum(start, end);
    // 子进程把结果写回管道
    write(pipe_fd, &r, sizeof(r));
    _exit(0);
}

int main() {
    std::vector<int> ranges = {100, 200, 300, 400, 500};
    std::vector<pid_t> pids;
    int pipe_fds[2] = {0, 0};
    if (pipe(pipe_fds) != 0) {
        perror("pipe");
        return 1;
    }

    for (size_t i = 0; i < ranges.size(); i++) {
        pid_t pid = fork();
        if (pid < 0) {
            perror("fork");
            continue;
        }
        if (pid == 0) {
            // 子进程关闭管道的读端
            close(pipe_fds[0]);
            int start = static_cast<int>(i) * 1000;
            int end = start + ranges[i];
            worker_process(static_cast<int>(i), start, end, pipe_fds[1]);
        } else {
            pids.push_back(pid);
        }
    }

    // 父进程关闭写端，开始汇总结果
    close(pipe_fds[1]);
    long total = 0;
    for (size_t i = 0; i < ranges.size(); i++) {
        TaskResult r;
        ssize_t n = read(pipe_fds[0], &r, sizeof(r));
        if (n == sizeof(r)) {
            std::cout << "worker " << r.worker_id
                      << " sum=" << r.sum << std::endl;
            total += r.sum;
        }
    }
    close(pipe_fds[0]);

    for (pid_t pid : pids) {
        waitpid(pid, nullptr, 0);
    }
    std::cout << "total=" << total << std::endl;
    return 0;
}

这段代码有几个细节值得注意。管道写端在fork前创建，子进程继承后，父进程和所有子进程各自持有一份写端副本。父进程必须关闭自己的写端，否则管道永远不会出现EOF，read会一直阻塞。所有子进程都往同一个管道的写端写数据，这没问题，写操作在PIPE_BUF以内是原子的，struct TaskResult足够小，不会交错。

5.3 为什么不用线程而用进程做这个任务

这个场景里每个任务的计算完全独立，没有共享的可变状态，最适合进程模型。用线程也能跑，但要在创建线程时处理返回值收集，线程中途崩溃还可能导致整体退出。进程方案里，某个子进程因为计算逻辑bug崩溃，父进程的read会返回0或者收到SIGCHLD，它可以决定跳过这个任务或者重新创建子进程，容错性更强。

5.4 进程池：比每次fork更优雅的生产方案

上面这个Demo每来一组任务就fork一次，在进程创建开销很大的场景下效率不够。生产环境里更常见的做法是预先创建一组固定数量的子进程，空闲时等待任务，来了任务就领取执行，执行完再等下一个。这就是进程池。

进程池的好处有三个：一是避免了频繁fork/exec的系统调用开销；二是可以让每个子进程预先加载模型、连接数据库、初始化日志系统，省掉重复初始化；三是控制并发数，防止子进程无限膨胀压垮系统。进程池的难点在于任务分配。实践中常用一个共享内存队列加信号量做任务编排，或者更简单直接点，用socketpair建立双向通道，父进程向空闲子进程发送任务描述。

我在做某个模拟项目X的时候，就通过socketpair加固定进程池处理了大量网络请求，子进程启动时一次性加载好特征库，单轮请求处理延迟比每次fork的实现低了一个数量级。这个经验验证了进程池在真实负载下的价值。

6. 我在生产环境中踩过的多进程坑

原理和方法都讲完了，最后这部分是全篇最实在的内容。以下坑都是我在真实项目中踩出来的，有些坑调试了几个通宵。

6.1 在子进程里使用标准库函数导致死锁

这是一个让人跳到崩溃的坑。某个采集服务在主进程里启动了多个线程，其中某个线程调用了fork。结果子进程拿到了一份fork时点的地址空间副本，包括那些正处于锁定状态的互斥锁。子进程如果再调用malloc或者printf这类需要内部锁的函数，发现锁已经处于locked状态，而且是另一个线程持有的，于是无限阻塞。这就是多线程环境下fork的经典死锁问题。

解决方案分三个层次。第一，永远不要在多线程模式下fork后执行复杂逻辑，除非立即exec。第二，如果必须继承环境，fork后只调用async-signal-safe函数。第三，可以用pthread_atfork注册在fork前加锁、fork后清锁的回调，但这只是权宜之计，解决不了根本问题。

6.2 忽略文件描述符继承导致连接数被耗尽

fork会复制父进程的所有文件描述符，包括已打开的监听socket、日志fd、数据库连接fd。子进程如果不关掉自己用不到的fd，这些句柄会一直占着，直到进程退出。每天大量fork应用服务，文件描述符累积速度非常快，最终触发EMFILE错误，整个系统无法建立新的连接。

我处理过的某个服务就从这条坑里爬出来过。排查手段很简单：ls /proc/<pid>/fd/ | wc -l 数一下进程里的fd数量，如果数量异常飙升，基本就是子进程没有关闭继承的fd。修法是在子进程里显式close不需要的fd，更彻底的做法是给fd打上FD_CLOEXEC标记，这样exec时自动关闭。

6.3 子进程退出码的表象与真相

子进程被信号杀死和正常退出，wait返回的status值表现完全不同。很多人以为status里保存的就是返回值，直接打印发现是个十六进制大数，困惑半天。status的编码规则是：低7位是信号编号，若进程被信号杀死；第8位起是真正的退出码。不要手动拆位，用WIFEXITED、WIFSIGNALED、WEXITSTATUS、WTERMSIG这些宏。确保子进程逻辑写完时把错误码设定好，否则父进程只能看到一个笼统的1。

6.4 fork炸弹：一台服务器被拖垮的真实教训

某次测试环境里，一个同事的脚本在循环里反复fork，没有设置任何退出条件，系统进程数在几十秒内涨到上限附近，整个服务器响应缓慢。root权限下可以kill -9杀掉父进程，但子进程还在不停复制，最后只能重启虚拟机。

教训就这么几条：不要在循环里无保护地调用fork；fork前先检查当前进程数getppid、getpid的层级关系；现场控制手段是限制单用户最大进程数（ulimit -u）。即使是在做压力测试，也要给fork炸弹留出防护措施。

6.5 共享内存同步的竞态问题

共享内存是IPC里性能最优的通道，也是同步问题最多的通道。我曾经在多个子进程同时对共享内存做累加统计时，漏掉了信号量保护，结果多次运行结果不一致。这个问题在单核机器上可能碰巧没问题，一到多核环境就原形毕露。

排查竞态问题有一个通用手段：每次运行前对比输出与非共享本地实现的差异。如果差异是随机的，优先怀疑共享内存区没有正确加锁。修法就是所有对共享内存的读写操作统一走sem_wait和sem_post配对，串行化临界区。临界区太大会影响并发，所以又要反过来尽量缩小临界区的代码量。

6.6 调试多进程程序的武器

多进程程序常规gdb调试不太顺手，因为gdb默认只跟踪父进程。调几个关键参数可以改善体验：

bash复制# 让gdb在fork后跟随子进程
set follow-fork-mode child
# 保留调试所有进程（新版本的gdb多进程调试支持）
set detach-on-fork on

如果想看进程内部到底发生了什么系统调用，用strace跟踪会更直观：

bash复制# 同时跟踪多个子进程的系统调用，输出到各自日志
strace -f -o /tmp/trace.log ./your_app

还有一种排查工具就是定期查看进程状态：

bash复制watch -n 1 'ps -eo pid,ppid,stat,cmd | grep your_app'

状态列出现Z，说明有僵尸；状态列出现D，说明进程卡在不可中断的IO上，多半和磁盘或网络相关。

6.7 信号处理函数中的不定式

SIGCHLD的信号处理器里，我只使用waitpid和计数的原子变量。因为信号处理函数可能在任意位置打断代码运行，很多操作不安全。最常见的错误是在处理函数里写日志，调用非异步安全的logging库，程序崩溃不要惊讶。如果想了解哪些库调用是安全的，看signal-safety的文档，标准里列出的异步信号安全函数就那几十个，写handler前先确认一遍自己调用的库在这份清单里。

我在实践中摸索出来的经验是：信号处理函数越短越好，最好短到只写一个原子变量加一次waitpid循环就结束，其余统计分析全部放到主循环里完成。

最后说几句实战体会

多进程编程在Linux下是一门越用越有味道的课程。它不像写业务代码那样马上有产出反馈，但它决定了一个高并发服务能不能在物理机中止出血来、在异常情况下降级而不死透。我在做某个跨平台数据服务的迭代时，把并发模型从多线程逐步改造成多进程后，整体稳定性有了质的提升，故障排查也从"动不动重启整个服务"变成了"拉起挂掉的那个子进程就完事"。

如果你刚开始接触这篇文章里的内容，建议按以下顺序练手：先单独把fork的返回值跑明白，再写一个waitpid加WNOHANG的轮询回收程序，然后试着通过管道传一段结构化消息，之后加一个共享内存加信号量为数据"提速"，最后把整个流程整合成可以复用的任务分发框架。每一步都在上一篇的基础上加深一点点，回头再看整个体系，很多东西会自然串起来。

最后再分享一个小技巧：写多进程代码时，多利用/proc文件系统验证进程的真实状态。比如/proc/<pid>/status里的State字段带Z就是僵尸进程，带D就是不可中断睡眠；/proc/<pid>/fd/里的软链接能看到这个进程到底打开了哪些文件。这些信息比想象中准确得多，排查疑难杂症时能省大量时间。