在Linux系统编程中，fork和exec是两个基础且常被混淆的系统调用。它们都和进程有关，但承担的职责完全不同：fork负责“生”出一个新进程，exec负责让某个进程“变”成另一个程序。只有把两者的边界理清，才能写出正确的多进程程序，也更容易理解shell、守护进程以及容器底层的运行逻辑。
一、fork的工作原理与特点
fork是Linux中用于创建新进程的系统调用。调用fork的进程称为父进程，新生成的进程称为子进程。从内核角度看，fork会复制父进程的绝大部分资源，包括虚拟地址空间、文件描述符表、信号处理方式等，从而得到一个几乎一模一样的副本。
现代Linux采用写时复制（Copy-On-Write，COW）机制优化fork性能。也就是说，fork之后父子进程暂时共享同一物理内存页，只有当某一方试图修改内存时，内核才真正复制对应的页。这使得fork调用本身非常轻量，不必立刻拷贝全部内存。
下面的C代码展示了fork的基本用法：
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main() {
pid_t pid = fork(); // 创建子进程
if (pid < 0) {
perror("fork failed");
return 1;
} else if (pid == 0) {
// 子进程分支，fork返回0
printf("子进程 PID=%d, 父进程 PID=%dn", getpid(), getppid());
} else {
// 父进程分支，fork返回子进程PID
printf("父进程 PID=%d, 创建的子进程 PID=%dn", getpid(), pid);
}
return 0;
}
从代码可以看出，fork在一次调用中会返回两次：在父进程中返回子进程的PID，在子进程中返回0。这种“一个调用、两份返回”的特性，是fork区别于普通函数的最重要标志。
fork之后，子进程继承了父进程打开的文件描述符、环境变量和信号掩码，但拥有自己独立的PID以及独立的程序计数器。也正因如此，如果只调用fork而不做其他操作，子进程会继续执行和父进程相同的代码路径，只是上下文数据不同。
二、exec系列调用的作用与机制
exec并不是单一的系统调用，而是一组以exec开头的函数（如execl、execv、execle等），它们最终都依赖于内核的execve。exec的核心作用是：在当前进程的地址空间内，加载一个新的程序文件，并用它完全覆盖掉原有进程的代码段、数据段和堆栈。
调用exec成功后，进程ID不变，但运行的程序已经变成新加载的程序。原进程的代码从此不再执行，相当于这个进程“脱胎换骨”。如果exec调用失败，则原进程继续运行，通常会在失败时返回-1并设置errno。
下面示例展示在子进程中调用execl执行ls命令：
#include <stdio.h>
#include <unistd.h>
int main() {
pid_t pid = fork();
if (pid == 0) {
// 子进程中执行 ls -l
execl("/bin/ls", "ls", "-l", (char *)NULL);
// 若执行到此行，说明exec失败
perror("execl failed");
} else if (pid > 0) {
wait(NULL); // 父进程等待子进程结束
printf("子进程执行完毕n");
}
return 0;
}
在这段代码中，子进程先由fork产生，随后立即调用execl加载/bin/ls。exec成功时，子进程原先的main函数后续逻辑被丢弃，转而执行ls程序；父进程则通过wait回收子进程状态，避免产生僵尸进程。
exec系列函数支持多种参数传递方式。以execv为例，它通过数组传递参数；以execle为例，还能额外指定环境变量。但无论哪种形式，它们的本质都是“替换当前进程映像”，不会创建新进程。
三、fork与exec的核心区别对比
从系统层面看，fork和exec最直观的区别在于是否产生新进程。fork产生新PID，exec不生成新PID。fork保留原程序，exec替换原程序。二者在进程生命周期中扮演不同角色。
通过下表可以更清晰地比较：
| 对比维度 | fork | exec |
|---|---|---|
| 是否创建新进程 | 是，生成子进程 | 否，替换当前进程 |
| 进程PID变化 | 子进程获得新PID | PID保持不变 |
| 原程序代码 | 父子都保留 | 被新程序覆盖 |
| 返回值特征 | 父返回子PID，子返回0 | 成功不返回，失败返回-1 |
| 典型用途 | 并发处理、服务多连接 | 运行外部命令、加载新程序 |
在实际工程中，单独使用fork的场景并不多，通常是为了后续调用exec做准备；而单独使用exec几乎没有意义，因为那会直接终止当前程序自身。因此Unix/Linux设计了一个经典组合：先fork，再在子进程中exec，父进程继续做自己的事。
这种组合也是shell执行命令的底层模型。当你在终端输入ls，shell先fork出子进程，子进程exec加载ls程序，父进程shell则等待命令结束并再次读取输入。理解这一点，就能明白为什么后台程序、管道和重定向都依赖于fork加exec的结构。
四、常见误区与注意事项
初学者常误以为fork会立刻完整复制父进程内存，从而导致性能焦虑。实际上写时复制机制已经大幅降低开销，只有在子进程大量写内存时才触发真实拷贝。不过，若父进程持有大块共享内存或锁，fork仍可能带来隐性复杂度。
另一个误区是认为exec能自动回收资源。exec虽然替换了程序映像，但进程之前打开的文件描述符默认仍然保持打开（除非设置了FD_CLOEXEC标志）。如果子进程exec了新程序却未关闭多余的描述符，可能造成文件描述符泄漏，父进程侧也会因描述符被占用而无法释放资源。
下面代码演示如何设置FD_CLOEXEC避免描述符泄露：
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
int main() {
int fd = open("test.txt", O_RDONLY);
if (fd < 0) return 1;
// 设置执行exec时自动关闭该描述符
fcntl(fd, F_SETFD, FD_CLOEXEC);
if (fork() == 0) {
execl("/bin/cat", "cat", "test.txt", (char *)NULL);
}
return 0;
}
上例中，通过fcntl设置FD_CLOEXEC，保证子进程在exec时自动关闭fd，避免将不必要的文件句柄暴露给新程序。这是多进程服务程序中推荐的做法，尤其在网络服务fork处理请求时更为重要。
此外，fork之后若在父、子进程中都使用多线程，会面临仅复制调用线程的问题，容易导致死锁。因此一般约定：多线程程序中尽量避免直接fork，或确保fork后立即exec，不执行其他非异步信号安全调用。
五、总结与实践建议
fork和exec是Linux进程模型的左右手：fork解决“如何多出一个人来干活”，exec解决“让这个人去干别的活”。二者配合既保持了父进程的掌控力，又赋予了子进程执行任意程序的能力。
在编写C或服务端程序时，若需要并发处理任务且任务逻辑就在本程序内，可以只fork不exec；若需要调用外部命令或插件式加载新逻辑，则必须fork加exec。同时，注意文件描述符、信号处理和僵尸进程回收，才能构建稳定可靠的Linux应用。
forkexecprocess_creation修改时间：2026-08-08 07:15:40