1. 第三天的学习基点：从单进程到进程协作的认知升级

先交代一下背景：我系统的学习路线是照着《Linux环境编程》的章节往下推，前两天把文件I/O、文件描述符、标准流缓冲、以及文件系统的基本操作摸了一遍。到第三天，内容开始脱离"单个程序怎么读写文件"的层面，转入"多个程序之间怎么配合、怎么打架、怎么通信"的进程视角，这也是从"会用API"到"理解系统"的关键转折点。

第三天的核心内容，我总结下来是四块：进程环境与生命周期、进程控制（fork与exec族）、进程退出与回收、简单进程间通信（管道）。这四块其实是环环相扣的——先搞清楚一个进程是怎么从出生到死亡的，才能理解为什么要wait回收子进程；理解了进程是独立的内存映像，才能明白管道为什么是"文件描述符的复制"，而不是"共享内存"。

我用一个具体的实验场景贯穿整天的学习：写一个模拟Shell的最小实现，只支持外部命令执行、一个内置的cd命令、以及用管道连接两个命令（比如ls | wc -l）。这个项目不大，但能把第三天的知识点全部串起来，也是很多网络服务、任务调度程序的雏形。整篇笔记我会按照这个项目的推进顺序来写，把每个知识点落到"为什么会报错、为什么这么写"的层面。

先说一个对初学者特别重要的心理建设：学Linux环境编程，不要死记API签名，要去记API背后的三个问题——这个函数做了什么？它改变了什么系统状态？调用失败时可能的原因是什么？第三天的内容尤其如此，因为fork、exec、wait这几个函数的行为，一旦理解偏差，写出来的程序会出现非常隐蔽的bug，比如孤儿进程、僵尸进程、管道读写端没有关闭导致的死锁。这些坑今天我都会逐一展开。

2. 进程环境剖析：main函数不是一切的起点，也不是一切的终点

很多从Windows C/C++转过来的同学会有个惯性：程序就是从main开始，到return 0结束。在Linux上，这个认知需要修正。main函数只是一个C运行时的入口点，不是内核加载程序的入口点。

2.1 内核视角下的进程启动过程

当我们用shell执行一个程序时，内核做的事情是按顺序往下推的：

1. 通过execve系统调用加载可执行文件（ELF格式），解析出代码段、数据段、栈、堆的初始布局。
2. 将入口地址设置为ELF头中记录的e_entry，这个入口通常不是main，而是C运行时库（crt1.o里的_start）代码。
3. _start做一系列准备工作：初始化栈（把argc、argv、envp压栈）、设置好调用约定所需的栈帧，然后调用__libc_start_main。
4. __libc_start_main负责完成C库的全局初始化——比如stdio缓冲区的初始化、atexit注册的清理函数栈、线程运行环境的准备。
5. 最后才调用我们的main(argc, argv, envp)。

这就解释了为什么在main的第一行代码执行之前，程序其实已经"活"了一小段时间。如果你的程序崩溃在main之前的初始化阶段，那么gdb-backtrace里看到的调用栈会非常奇怪，没有main帧，只有_start和__libc_start_main的帧。我第一次遇到这种崩溃时完全懵了，以为是链接器问题，后来才知道是某个全局对象的构造函数里访问了未初始化状态。

2.2 进程终止的六种途径

《Linux环境编程》第三天花了很大篇幅讲进程终止，这里我直接给一张行为对照表，比干读文字高效得多：

这里有一个第三天最容易踩的坑：exit和_exit的区别。很多人知道前者会刷新缓冲区，后者不会，但实际写代码时仍然会犯。比如下面这个经典问题：

#include <stdio.h> #include <unistd.h> int main(void) { printf("hello, world"); _exit(0); }

这段程序运行后，终端上什么都看不到，因为printf的输出还在用户空间的stdio缓冲区里，_exit直接进内核终止进程，缓冲区没被刷新，内容就丢了。如果把_exit换成exit，输出正常显示。这在日志模块里尤其危险——如果你在某个库代码里用了_exit，那之前所有打日志的printf内容都可能丢失，排查起来非常隐蔽。

关于atexit的注册顺序，实验才能记住：atexit注册的清理函数是LIFO（后进先出）执行的。也就是说，你最后注册的清理函数最先执行。这个设计是有道理的——资源之间的依赖关系往往是最晚申请的先释放，比如先开数据库连接再开缓存连接，关闭时就该先关缓存再关数据库。我写服务端模块时，清理函数经常按"先关新资源、再关旧资源"的顺序注册，避免依赖颠倒。

2.3 环境变量表和进程的内存布局

第三天的笔记里还有一个重要知识点：进程环境表本质上是一块字符串数组，以NULL结尾。extern char **environ就是指向这块内存的指针。通过setenv/unsetenv修改环境变量时，如果新值比旧值长，C库会重新分配一块环境表，并将原来的environ指针整体替换掉。

这解释了为什么在多线程程序里不要随便调setenv——它可能触发整个环境表的搬迁，而这种搬迁本身不是线程安全的，多线程同时设置环境变量，轻则丢数据，重则触发未定义行为。单线程程序里无所谓，服务端程序必须谨慎。

内存布局方面，进程地址空间从低地址到高地址依次是：代码段、已初始化数据段（.data）、未初始化数据段（.bss）、堆（向上增长）、共享库内存映射区、栈（向下增长）、命令行参数与环境变量区。这个布局在第三天一定要刻进脑子里，因为后面学共享内存、内存映射、栈溢出攻击都会反复提到。

第三天我做的第一个实验是把一个全局变量的地址、一个局部变量的地址、一个malloc返回的地址打出来，观察它们的分布。真实运行结果大致如下：

全局变量(data段): 0x55a2c1e01010 malloc分配的堆内存: 0x55a2c22012a0 局部变量(栈): 0x7ffd3f6a2b5c

栈地址和其余地址之间隔了一大段空间，这段空间就是共享库映射区。看懂了这张图，后面学 mmap 时会有天然的亲切感。

3. fork的真相：为什么子进程从fork之后的语句开始执行

第三天绝对的主角是fork。这个函数我早在教科书上见过无数次，但真正写代码验证之后，才体会到它的精妙和反直觉。

3.1 fork返回值的双重身份

fork的行为一句话概括：调用一次，返回两次。父进程中返回子进程的PID（大于0），子进程中返回0。这两个返回值可以理解成"身份标识"——父进程拿到的是一张"我生了个孩子，这是TA的编号"的纸条；子进程拿到的是"我其实是那个孩子"的身份牌。

很多人第一次看代码会困惑：为什么同一个函数调用，变量pid在两个进程中会有不同的值？

#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) { printf("子进程: 我的PID是%d，父亲的PID是%d\n", getpid(), getppid()); } else { printf("父进程: 我的PID是%d，孩子的PID是%d\n", getpid(), pid); } return 0; }

关键在于理解fork是复制整个进程的内存映像，而不是"跳到某个位置重新执行"。子进程拥有的是一份父进程内存的逐位拷贝，它被内核调度器放入运行队列时，处于一个"从fork系统调用即将返回"的状态，CPU的寄存器上下文都被恢复成fork返回前的样子。所以子进程"看到"的是pid变量还没赋值的结果，然后继续执行下一行——也就是if (pid < 0)这个分支判断。

用这个类比也许更好理解：fork就是在"函数调用处"发生了一次时间线克隆。父进程沿着原有时间线继续走，子进程从同一个岔路口（fork调用返回的那一刻）以另一套身份继续走。两条时间线后续的变量修改互不影响，因为它们已经有了各自独立的物理页表。

3.2 写时复制（COW）机制：fork不是暴力拷贝

如果fork真的是"逐位拷贝整个内存"，那fork一个占用2GB内存的进程会极其低效。事实上Linux的fork利用了写时复制（Copy-On-Write）技术：

• fork时，内核只需要拷贝父进程的页表，并将所有可写页面标记为只读。
• 父子进程此时实际上共享同一批物理页面。
• 当其中一方尝试写入这些页面时，触发缺页异常，内核才真正分配新物理页，并把旧页面内容复制过去，更新页表映射，然后恢复可写权限。

这就带来了一个非常重要的实践推论：fork的开销和进程的内存大小关系不大，主要取决于页表的大小和进程的活动页面数。我在一台4核8GB的机器上测试过，fork一个空闲的1.2GB进程，耗时大约1毫秒；而如果这个进程在疯狂写入堆内存，fork耗时能涨到几十毫秒。所以在设计高并发网络服务时，如果选择fork模型，要特别注意fork之前的工作负载——最好在fork前避免大量脏页累积。

3.3 fork失败、并发调度和缓冲区复制坑

fork返回-1的情况主要有三种：进程数达到系统上限（EAGAIN）、内存不足（ENOMEM）、以及某些安全限制（EPERM）。在长时间运行的服务端程序里，我见过"不断fork导致进程数涨到上限"的线上事故，这通常是某个子进程没有正常退出导致的进程泄漏，排查时用ps -ef | grep一眼就能看到几百个同名的僵尸或运行态进程。

关于父子进程的执行顺序，必须明确：fork返回后，父子进程谁先运行，完全由内核调度器决定，没有任何保证。如果你的代码依赖"父进程先执行"或"子进程先执行"，那就必须用同步机制（如管道、信号量、wait）。我第二天就在这个小地方吃过亏——子进程在父进程还没来得及设置某些共享状态时就运行了，结果全部跑偏。

还有一个特别隐蔽的坑：fork之前如果有未刷新的stdio缓冲区，那么这份缓冲区会被父子进程各持有一份，导致输出内容被打印两次。典型的错误写法是：

printf("before fork\n"); fflush(stdout); // 这一行很重要 fork();

去掉fflush后，"before fork\n"还在缓冲区里，fork复制了整个进程内存，于是子进程和父进程各自在退出时刷新自己的缓冲区，"before fork\n"就打印了两遍。如果输出是写日志，这种"日志重复"往往是fork导致的，而很多人会去日志系统里找原因，找半天找不到。经验就是：fork之前，先fflush所有你关心的输出流。

4. 模拟Shell实验的第一次迭代：exec族函数与PATH搜索逻辑

第三天学习exec族之前，我做的模拟Shell只能fork出子进程，但子进程执行的还是和父进程一样的代码。要让子进程"变成"另一个程序，就必须用exec族函数。

4.1 exec族的六个变体和语义对比

exec族一共有六个函数：execl、execv、execle、execve、execlp、execvp。名字里的字母含义很有规律：

• l（list）：参数以列表形式逐个传入，最后一个参数必须是NULL。适合参数个数确定的场景。
• v（vector）：参数放在一个字符串数组中，数组同样以NULL结尾。适合动态拼接参数的场景。
• p（path）：按PATH环境变量搜索可执行文件，如果传的文件名不含路径，会遍历PATH中的目录逐个尝试。不带p的版本则要求你显式给出文件路径。
• e（environment）：允许你传入自定义的环境变量数组，而不是继承当前进程的环境表。

我最终在模拟Shell里选了execvp，因为它最容易复现"用户在终端输入命令"的行为——ls、ps这种不带路径的命令需要按PATH去搜索。

这里有一个必须养成的习惯：exec调用成功后不会返回，因为当前进程已经被替换了，原来的代码段、数据段全部被新程序覆盖。如果你在exec后面还写了代码，那这段代码永远只在exec失败的情况下才会执行。所以标准的做法是：

execvp(argv[0], argv); perror("execvp failed"); // 能走到这一行，说明exec失败了 exit(127); // 127是shell惯例中"command not found"的退出码

4.2 为什么exec不需要"重新fork一个线程"，而是"原地换血"

对比Windows的CreateProcess（一步完成创建+加载），Linux的fork+exec两步走看起来绕了一圈，却带来了强大的灵活性。理解它需要回到第三天反复强调的"进程是资源容器"这个模型：

• fork负责"复制容器"：新容器拥有旧容器的全部资源副本——文件描述符、信号处理设置、环境变量、工作目录、umask等。
• exec负责"替换容器中的代码和数据"：新程序运行在一个继承了全套上下文的新容器里。

这意味着，在fork和exec之间，父进程可以精确地调整子进程的资源状态：重定向标准输入输出（dup2）、关闭不需要的文件描述符、设置信号处理函数、修改工作目录。这套"先复制、再调整、最后换程序"的三段式操作，正是shell实现重定向和管道的基础。

我在模拟Shell里就是这么做的：fork之后，如果命令带了>重定向，就在exec之前用open+dup2把子进程的STDOUT_FILENO重定向到目标文件。因为fork保证子进程有一份独立的文件描述符表，在子进程里做重定向不会影响父进程shell的输入输出。

4.3 exec之后的信号处理：一个容易忽略的继承问题

signal函数设定的信号处理方式是继承到子进程的，而且exec不会重置它们。这个特性偶尔会带来诡异的问题：

假设父进程（一个服务端程序）通过fork+exec启动一个子进程去做外部任务，而父进程之前用sigaction设置了SIGCHLD处理器——子进程退出时父进程会立刻得到通知。行为没问题，但如果你不小心在父进程里设置了SIGALRM的处理器，而某个第三方库fork+exec的子进程里触发了SIGALRM，它也会执行父进程的那个处理器函数——而那个函数可能并不存在于新程序的地址空间中。

吸取教训的做法：在exec之前，把不需要继承的信号处理方式全部重置为SIG_DFL，或者用pthread_sigmask之类的接口确保信号掩码符合预期。这是很多网络服务框架不约而同采用的标准姿势。

4.4 让子进程真正执行"外部命令"的过程复盘

模拟Shell第一版跑通的代码框架大致是：

pid_t pid = fork(); if (pid == 0) { // 子进程：准备环境 if (redirect) { int fd = open(target_file, O_WRONLY|O_CREAT|O_TRUNC, 0644); dup2(fd, STDOUT_FILENO); close(fd); } execvp(cmd, args); perror("execvp"); exit(127); } else { // 父进程：等待 waitpid(pid, &status, 0); }

跑通之后我试了ls -l、ps aux、echo hello，结果都符合预期。但接着就遇到了第一个莫名其妙的问题：交互式的vi、less跑不起来，屏幕上花屏或者程序直接退出。排查后才知道，这类程序需要读取终端控制信息（termios设置），而fork+exec之后子进程继承的终端模式并不总是理想状态；另外它们还依赖前台进程组、作业控制等机制。第三天的知识范围还没覆盖到进程组和终端控制，所以我把"支持交互式程序"划到了后续学习计划里，在模拟Shell里只支持非交互式外部命令。

5. waitpid的深水区：从僵尸进程到退出状态解码

进程退出后，如果父进程没有及时回收，它就变成僵尸进程——进程已经终止，但内核还保留着它的进程描述符和退出状态，等父进程来"收尸"。这就是第三天笔记里"孤儿进程与僵尸进程"那一节的实物来源。

5.1 为什么要有僵尸态：内核必须保存"死因"

很多人觉得僵尸进程是一种设计缺陷，但实际上内核必须保留退出进程的最小信息，直到父进程确认接收。这个最小信息就是：PID、退出状态、资源使用统计。它们是父进程调用wait/waitpid时要拿到的"死因报告"。如果内核在进程终止时立刻释放全部信息，那父进程的waitpid就会失去意义——它无法得知子进程是正常退出（exit code是多少）、还是被信号杀死（哪个信号）。

我说个实际测试结果：让子进程主动进入死循环，父进程不调用wait。然后ps查看状态，子进程显示为Z（zombie）。这时即使你用kill -9去杀这个僵尸进程，它也纹丝不动——因为它已经"死"了，只是在等待被确认死亡。只有父进程调用wait/waitpid，或者父进程自己也退出（僵尸子进程被init进程收养并回收），僵尸才会消失。

5.2 WEXITSTATUS、WIFSIGNALED等宏的完整解码表

waitpid拿到的status参数是个32位整数，不同位段编码了不同的信息。直接去读数字毫无意义，必须用标准宏解码：

在我写的模拟Shell里，需要根据子进程退出的不同方式打印不同提示——像shell那样"Segmentation fault (core dumped)"。实现起来就是：

if (WIFEXITED(status)) { printf("exit code: %d\n", WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("killed by signal %d\n", WTERMSIG(status)); }

特别注意：WEXITSTATUS只能从0~255取值。如果给exit()传-1，经过取模后子进程退出码实际是255，这一点在脚本判断里容易出错。

5.3 wait与waitpid：阻塞、轮询和WNOHANG

wait只有一个功能：阻塞地等待任意一个子进程终止。waitpid则提供了更多控制：

• pid > 0：只等待指定PID子进程。
• pid == -1：等待任意子进程，类似wait。
• pid == 0：等待与当前进程同一进程组的任意子进程。
• pid < -1：等待指定进程组的任意子进程。
• options = WNOHANG：不阻塞，如果没有子进程退出则立即返回0。
• options = WUNTRACED：也会返回被暂停（而非终止）的子进程状态。

在模拟Shell的普通命令执行场景，用waitpid(pid, &status, 0)最合适——我们关心的是"那个特定命令"的退出结果。而像服务端程序那种"我有大量子进程，谁先挂了我先处理谁"的场景，则适合waitpid(-1, &status, 0)循环收割。

WNOHANG有多重要？假设你写一个事件循环，同时监听网络事件和管理子进程，这时候你就不能死等waitpid，否则网络事件会饿死。标准姿势是在事件循环里加一个非阻塞的waitpid检查，无僵尸则稍后再查。我见过的很多守护进程框架都是这么做的。

5.4 SIGCHLD与自动回收：信号驱动式收割的坑

如果父进程不想轮流阻塞地等每一个子进程，可以注册一个SIGCHLD处理器，子进程退出时内核会向父进程发送这个信号，父进程在信号处理函数里收割子进程。

这个方案看起来优雅，但有几个坑：

1. 信号可能丢失：SIGCHLD是标准信号，不是实时信号，同一时刻多个子进程退出，信号可能被合并为一次。所以在SIGCHLD处理函数里必须用循环while (waitpid(-1, &status, WNOHANG) > 0)把所有僵尸一次收割完，而不是只调一次waitpid。
2. 信号处理函数的安全性：信号处理函数中能做的事极其有限（只能调用异步信号安全函数）——于是你无法在处理器里运行常规的内存分配、打印、甚至printf。这就让"socket关闭、日志写入"等操作很不方便。
3. 标准信号可能会打断主流程中的阻塞调用：比如poll、epoll_wait可能因为SIGCHLD而返回EINTR，你需要重新调用。

鉴于此，我的服务端代码更倾向于用统一事件循环+非阻塞waitpid的方案，而不是SIGCHLD。第三种天的笔记里，模拟Shell用了阻塞waitpid，这是最直观的教学场景。

6. 管道初探：ls | wc -l 的背后发生了什么

学完进程创建和回收，我趁热做了管道实验。管道是Linux进程间通信（IPC）里最古老也最基础的一种机制，第三天学到的管道知识实际上就是shell那条ls | wc -l的全部原理。

6.1 pipe系统调用与文件描述符的"双向错觉"

pipe(fd)会创建一对文件描述符：fd[0]用于读，fd[1]用于写。之所以需要两个fd，是因为管道在Linux里是半双工的——数据只能从写端流向读端。如果你试图从写端读数据、从读端写数据，都会得到错误。

很多初学者以为管道是"一对能互相通信的socket"，实际不是。管道缓冲区在内核里，是一个环形缓冲区，没有名字，只能被创建它的进程及其子进程通过文件描述符访问。

默认管道大小是65536字节（64KB），可以通过fcntl(fd, F_SETPIPE_SZ, ...)调整。当写端写入数据而读端一直不读时，缓冲区满后写操作会阻塞。反过来，读端读完所有数据后再次读，会阻塞等待新数据——这就是管道的同步机制：它天然地让两个进程的生产和消费节奏对齐。

6.2 实现 ls | wc -l 时，每个进程必须关闭哪些fd

模拟Shell支持管道的核心代码逻辑是：

1. 父进程创建管道pipe(fds)。
2. fork()两次，生成两个子进程。
3. 第一个子进程（执行ls）把stdout重定向到fds[1]（写端），然后关闭fds[0]（读端）。
4. 第二个子进程（执行wc）把stdin重定向到fds[0]（读端），然后关闭fds[1]（写端）。
5. 父进程需要关闭两个管道端。
6. 父进程wait两个子进程。

第3、4、5步中关闭多余fd是管道编程最容易出错的地方。如果有任何一个进程还保留着不该有的写端，读端就读不到EOF，wc会一直阻塞等待。我在实验里刻意制造了这个bug——让wc子进程保留写端，结果就是ls | wc -l卡死，终端没有任何输出。排查日志显示wc一直阻塞在read调用上，直到我kill掉相关进程才恢复。

有个非常形象的描述：管道EOF不是"没有数据"，而是"写端不存在了"。读端只有在所有写端副本都被关闭后，才能读到EOF（read返回0）。所以管道的正确关闭策略永远是——谁不用某个端，就立刻关掉它。

6.3 管道实现的隐藏坑：缓冲区写满时的死锁

再往深一层，管道还会带来另一个死锁场景，这是第三天很多同学没意识到的地方：

假设两个进程互相通过管道通信，A负责先写完再读B的响应，B负责先读完A的数据再写响应。如果A写的数据超过64KB，而B还没开始读，A就会阻塞在write上，B自然等不到A读自己的响应，两个进程互相等待，形成死锁。

解决思路是打破"先写后读"的绝对顺序，改用poll/epoll监控多个管道的读写就绪状态，或者改成"先读后写"的协作模式。第三天只需要知道这个坑存在，我留到了后面I/O多路复用的章节再正式处理。

6.4 把管道和进程回收结合起来：父进程的正确收尾顺序

模拟Shell的最终执行流程里，还有一个小细节值得记录：父进程必须先关闭管道两端，再wait子进程。

原因在于，如果父进程不主动关闭写端，那么即使两个子进程都执行完了，写端仍然存在（父进程持有的副本），wc子进程永远读不到EOF——又卡死。我第一次实现时顺序写反了，waited之后才去关fd，结果ls | wc -l偶尔能返回、偶尔卡死，非常玄学。

正确顺序写下来就是：

// 创建管道 pipe(fds); // 子进程1: ls if (fork() == 0) { dup2(fds[1], STDOUT_FILENO); close(fds[0]); close(fds[1]); execlp("ls", "ls", NULL); exit(127); } // 子进程2: wc if (fork() == 0) { dup2(fds[0], STDIN_FILENO); close(fds[0]); close(fds[1]); execlp("wc", "wc", "-l", NULL); exit(127); } // 父进程：关闭两端再等待 close(fds[0]); close(fds[1]); wait(NULL); wait(NULL);

这套"关、拨、等"的顺序，几乎可以复刻所有shell管道行为。真正理解了它，再看"为什么shell要fork一个子进程来执行重定向"这类问题，就会有豁然开朗的感觉。

7. 第三天踩坑实录：从段错误到僵尸堆积的完整排查链

这天的笔记还有一个专门板块，记录做实验过程中真实遇到的坑。不是每个坑都在书里有描述，但每个坑都对应了一个内核机制，所以排查过程本身就是在复习当日内容。

7.1 段错误排查：char *s = "hello" 和 char s[] = "hello" 的区别

实验里我写了这样一段代码，想要测试exec前修改子进程环境变量：

char *env = "MY_VAR=test"; setenv("MY_VAR", env, 1);

运行直接段错误，gdb提示setenv内部崩溃。排查后发现问题根本不是setenv，而是前一行把两个字符串的指针搞混了：setenv的第二个参数需要char *而不是const char *，而C字符串字面量存放在只读内存区，往里面写数据自然段错误。

这个纠正本身很小，但它引出了一个常用考点：字符串字面量存放在只读段，char *s = "..."指向只读内存，char s[] = "..."则是栈上的可变数组。Linux环境编程中处处都能看到这两种形态的区别：argv的字符串是可变数组，而环境变量表某一项的值也是C字符串，同样不能直接修改。很多库代码对这两种情况做了特殊处理，读源码时留意一下就会发现。

7.2 僵尸进程堆积：进程数量缓慢增长的元凶

模拟Shell在第一版完成后，运行一段时间后我发现系统进程数越来越多，ps里一堆<defunct>状态的进程。这是因为父进程只wait了一个子进程，另一个子进程没有被回收。

排查思路是这样的链路：

1. ps -ef | grep defunct确认僵尸进程存在。
2. 对比僵尸进程的PPID，确认它们都属于模拟Shell进程。
3. 检查代码里的wait次数——原来在支持管道的一轮实验中，父进程只调用了wait(&status)一次，管道场景下有两个子进程，其中一个必然漏回收。
4. 修复：把管道场景和单命令场景的收割次数对齐，或者统一改成while (waitpid(-1, &status, WNOHANG) > 0)循环收割。

这里暴露了一个通用教训：父子进程数量必须一致。fork一次，最终就一定要wait一次，这是硬性契约。

7.3 管道卡死的根因：写端副本未完全关闭

前面已经详细说过这个坑，第三天的记录里我专门画了一张"谁持有哪些fd"的表来定位：

排除问题时，只要看到read阻塞，就检查写端是否还有进程持有；只要看到write阻塞，就检查读端是否一直不读。这两个方向基本覆盖了日常90%的管道通信问题。

7.4 不得已用sleep验证并发时的教训

第三天的实验里，为了观察父子进程交替运行，我一度在两个进程里都加了sleep(1)，结果发现调度顺序变得极不稳定，同一个实验多次运行的输出都不一样。后来意识到这不是bug，而是进程调度本身就不提供任何顺序保证。要控制执行顺序，应该用管道或信号机制，而不是赌sleep等待时间。

这成为一个重要转折点——从这之后我写并发相关代码，默认不再依赖sleep做同步，而是显式用IPC原语。经验是：sleep在调试时很方便，但绝对不能作为并发逻辑的一部分。

8. 写在第三天后：如何把今天的知识复利到下一天

第三天学到的东西在后续内容里几乎全程复用。阶段性地总结一下自己真正掌握、以及还需要再回炉的部分，也顺便给正在按同样路线学习的人一些建议。

从"能跑"到"理解"，我认为今天最大的提升是形成了三个心智模型：

第一个模型是"进程生命周期"的心智模型。从fork出生，到exec更改自我，到exit死亡，再到wait被回收，每一步都能问出"此刻的内核状态是什么"。有了这个模型，僵尸进程、孤儿进程、守护进程的建立逻辑就都不再是孤立知识点。

第二个模型是"资源继承"的心智模型。fork之后子进程拥有一份父进程资源的快照——文件描述符、信号处理、环境变量、工作目录。任何资源在fork之后做的修改，父子进程互不影响。这个模型直接映射到后面学文件锁、信号、共享内存时的各种"为什么"。

第三个模型是"文件描述符即一切"的心智模型。管道、socket、文件、终端，本质上都是一套读写接口。dup2改的是进程文件描述符表中的指向关系，close改的是引用计数。今天能熟练操作管道，明天学socket编程就会快很多。

如果让我给同样在学Linux环境编程的人一条建议，那就是：每学一个新的API，都要写一个小程序去验证它的边界行为，而不是只跑通老师的示例代码。比如fork之后分别在父子进程里修改全局变量，你就能亲自看到"内存独立"的事实；不关管道写端，你就能亲眼看到"EOF的定义是写端消失"；不wait，你就能看到僵尸进程。这些实验成本极低，收益却极高。

第三天的模拟Shell虽然还远远达不到生产级shell的水准——不支持交互式程序、不支持作业控制、不支持通配符展开——但它已经完整地支起了"进程+文件描述符"这个Linux系统编程的核心骨架。后面要做的，不过是在这个骨架上持续叠加新的能力模块。这条路,我已经知道该怎么往下走了。