Linux系统编程：环境变量、进程地址空间与进程控制实战

1. 环境变量：程序启动前就收到的那张“便签”

1.1 环境变量到底存了什么、为什么程序都需要它

做Linux系统编程的人，迟早会遇到这样一个问题：程序明明在终端里手动跑得好好的，结果扔进crontab定时任务里就报“找不到某个依赖库”，或者脚本在交互环境里一切正常，一到systemd服务却拿不到需要的信息。十有八九，问题出在环境变量上。

环境变量本质上就是一组键值对，操作系统和运行中的进程用它来交换“与你当前工作环境有关”的配置信息。常见的有PATH（命令搜索路径）、HOME（当前用户主目录）、LANG（语言和编码）、SHELL（当前shell路径）、PWD（当前工作目录）、LD_LIBRARY_PATH（动态库额外搜索路径）等。你可以把环境变量理解成一张便签，程序在启动时前就被塞到了手里：上面写着“你在哪里、你的家在哪、去哪找命令、去哪找动态库”，程序不需要自己猜测这些信息，直接读便签即可。

这里有一个容易混淆的点：环境变量虽然在shell里敲一条export命令就能设置，但它并不是shell自己发明的概念。环境变量是进程级别的机制，准确说是进程环境的一部分，由内核在启动程序时维护。每个进程都有一块属于自己的“环境变量区”，本质是一个以null结尾的字符串数组，数组里每个元素形如“KEY=value”。当你登录系统、启动shell时，系统会从/etc/profile、~/.bashrc等配置文件中初始化一批环境变量，之后你在终端里执行的每个命令，都会从当前shell手里继承这一整份环境变量副本。

从事系统编程的角度看，环境变量有三个特点特别重要：

• 它是进程自带的“全局配置”，任何被启动的子进程都会自动继承它，这是进程间传递配置最传统也最简单的手段之一。
• 它在进程启动后可以被修改、新增、删除，但这些修改只影响当前进程以及之后再创建的子进程，回不去改父进程。
• 它和命令行参数一样，都是程序“外部输入”的一部分，因此很多程序会用环境变量控制运行行为，比如用GDB调试时常见的MALLOC_CHECK_、LD_PRELOAD这类调试开关。

理解“便签的继承与隔离”规则，是掌握环境变量编程的关键起点。

1.2 命令行三板斧与C语言读写实操

先看最常用的几个操作，任何一台Linux机器上都能验证。

bash复制# 查看全部环境变量
env

# 查看单个环境变量
echo $PATH

# 设置/修改环境变量（仅对当前shell及后续子进程生效）
export MY_TEST_VALUE="hello_from_env"

# 删除环境变量
unset MY_TEST_VALUE

这四条命令，搞定日常90%的需求。注意执行export后，新设置的环境变量只对当前shell以及之后启动的子进程可见。如果你在终端里执行了export，再去启动一个脚本，脚本里能读到；但如果你的程序是通过systemd服务启动的，就只取决于服务配置里指定的Environment或EnvironmentFile，shell里怎么设都传不过去，因为服务进程不是你的shell派生的子进程。

命令行之外，C语言里操作环境变量主要有这些接口：

c复制#include <stdio.h>
#include <stdlib.h>

extern char **environ;

int main(void) {
    // 读取：直接读，不修改
    const char *path = getenv("PATH");
    if (path) {
        printf("PATH = %s\n", path);
    } else {
        printf("PATH not set\n");
    }

    // 设置：setenv会复制一份字符串到环境区
    if (setenv("MY_TEST_VALUE", "hello_from_env", 1) != 0) {
        perror("setenv failed");
        return 1;
    }

    // 追加方式修改
    setenv("PATH", "/opt/mybin", 1); // overwrite=1 覆盖旧值
    // 注意：setenv覆盖PATH不是追加，要追加需要先getenv再拼接

    // 直接遍历环境变量区
    for (char **env = environ; *env != NULL; env++) {
        printf("%s\n", *env);
    }

    // 删除
    unsetenv("MY_TEST_VALUE");

    return 0;
}

操作细节上有几个坑，值得单独说：

• setenv和putenv都被广泛使用，但行为不同。setenv会为你传入的字符串做一份拷贝，之后你修改原字符串缓冲区不影响环境变量；putenv则直接把传入字符串的指针交出去，你后续改动这个char*指向的内容，环境变量会跟着变。用putenv时千万别传栈上临时变量，否则函数返回后环境变量区留着悬空指针，后果很难排查。
• getenv返回的指针指向环境变量区，不要在它上面做释放或修改，规范用法是立即拷贝走。
• environ这个全局变量声明在<unistd.h>中，但在自己代码里需要写extern char **environ;，注意编译时的标准选择，有些较严格的标准下会降低可见性，建议_GNU_SOURCE或直接按上面方式声明。

1.3 环境变量的继承规则：fork与exec才是关键

环境变量的传递链路，本质上是被fork和exec这两个系统调用决定的。简单说：

• 调用fork()创建子进程时，子进程会获得父进程环境变量区的完整拷贝，父子进程各自独立，之后谁改环境变量都不影响对方。
• 调用exec系列函数替换当前进程镜像时，环境变量默认被保留传递给新程序。同时execle、execlpe这一批变体允许你在调用时手动指定一份全新的环境变量数组。

这个机制对后台服务、脚本解释器、构建系统尤其重要。我的一个实际经验：在项目里给Java程序写启动脚本时，有时候要同时设置JAVA_HOME、JVM参数、classpath等，如果直接写一堆export当然可行，但更优雅的做法是用env命令为特定命令构造环境：

bash复制env JAVA_HOME=/opt/jdk17 CLASSPATH=/opt/app/lib/*:/opt/app/classes \
    GDK_BACKEND=x11 /opt/app/bin/start.sh

这样做的好处是环境变量只对这一次命令生效，不污染当前shell。编写守护进程时也经常用这个思路：在启动子进程前修改环境、启动完再恢复，避免全局状态污染。

还有一个过时但常被面试题点名的知识点：环境变量区和命令行参数在进程地址空间里其实是连在一起的，就在栈区上方那块高地址区域。当程序启动时，内核会把参数和环境变量依次压到栈顶附近，然后把初始栈指针指向调用栈。所以你在C语言的main(int argc, char *argv[], char *envp[])签名里可以看到第三个参数envp，它和environ指向同一个区域。虽然现在推荐用getenv而不是envp，但理解这个内存布局对后面看进程地址空间很有帮助。

2. 进程地址空间：一张需要刻进脑子里的内存地图

2.1 虚拟地址与物理地址的“障眼法”：每个进程都以为自己独占整台机器

Linux系统编程里，进程地址空间这个概念，说到底是“虚拟地址空间”。每个进程都拥有一个从0x0开始到高位地址结束的连续虚拟地址范围，32位系统一般是4GB，64位系统在x86-64下用户空间通常是128TB（从0x0到0x7fffffffffff）。这个范围看着很唬人，但进程真正用到的虚拟内存只有一小部分，剩下的都是“悬空”映射。

为什么要搞一套虚拟地址出来？想象一下，如果所有进程直接访问物理内存，A进程往地址0x1234写数据，B进程同一时刻也往0x1234写，这俩数据就会互相踩踏。虚拟内存机制相当于给每个进程发了一个“独立王国”，进程看到的所有地址都是自己王国的门牌号，由CPU中的MMU（内存管理单元）负责把虚拟地址翻译成物理地址，翻译过程遵循操作系统维护的页表。这样即使多个进程的虚拟地址完全相同，它们对应的物理页也可能完全不同，进程之间天然隔离，谁也碰不到谁的数据。

对一个系统程序员来说，这种“障眼法”带来的好处特别实在：

• 进程与进程、进程与内核之间有了安全边界，普通进程无法直接访问内核地址空间。
• 每个进程都拥有连续的地址空间，malloc分配内存时不用关心物理内存碎片，操作系统负责在背后拼接物理页。
• 牺牲一点点翻译性能，换来灵活的内存管理：内存映射、文件映射、共享内存等高级手段都基于虚拟内存才可以高效实现。

如果你在写程序时发现“哎呀，我明明malloc了1GB内存，为什么top里RSS才几十MB”，不用奇怪，因为malloc成功只是虚拟地址空间分配成功，物理内存是等你真正写入时才按需分配的，这就是“缺页”机制在起作用。

2.2 栈、堆、数据段与代码段：各自的领地与生长方向

理解进程地址空间，最实在的方式是记住经典布局图。以64位Linux进程为例，从低地址到高地址大致是：

• 代码段（Text）：存放机器指令，只读，通常从0x400000左右开始。
• 数据段（Data）：存放已初始化全局变量和静态变量，又分只读数据和读写数据。
• BSS段：存放未初始化全局变量和静态变量，不占实际文件空间，程序启动时由内核清零。
• 堆（Heap）：malloc/free管理的动态内存区，向高地址方向生长。
• 内存映射区（mmap region）：动态库、mmap映射文件、共享内存等，通常位于堆和栈之间。
• 栈（Stack）：函数调用使用的局部变量、函数参数、返回地址，向低地址方向生长。
• 命令行参数与环境变量区：在栈顶上方的高地址区域。

这里最容易让新手困惑的是栈和堆的“生长方向相反”。栈从高地址向低地址长，堆从低地址向高处长。为什么这么设计？一个关键原因是给两者留出共享的中间区域，不至于一上来就互相撞上。另外，栈向下生长是硬件和编译器约定的，x86的push指令就是先减小栈指针再写入数据，直接吻合这个设计。

栈空间不是无限的。Linux下默认栈大小通常为8MB，你可以用ulimit -s查看，单位是KB。写递归函数不小心死循环时，栈就会一路向下生长，最终超出限制触发“栈溢出”，程序直接段错误（Segmentation fault）。堆则不同，只要物理内存和地址空间够用，malloc申请多少块都行，但堆没限制也可能导致内存膨胀，所以需要在代码里自己做好管理。

还有一个细节，代码段和数据段之间有时还有一块“空洞”，这是为了对齐到页边界（通常4KB或更大）。日常调试段错误时，如果gdb报的地址很奇怪（比如0x0、0x1、0xffffffff...），大概率就是解引用了空指针或者野指针。

2.3 把内存地图“画”出来：/proc/PID/maps实战

纸上谈兵不如动手验证。Linux的/proc伪文件系统提供了一个页面：/proc/<pid>/maps，把进程的内存映射按地址从小到大全部列出来。

写一个小程序，让它sleep住，然后并行开一个终端看它的内存地图：

c复制#include <stdio.h>
#include <unistd.h>

int global_init = 100;
int global_uninit;

int main(void) {
    int local_var = 10;
    printf("PID: %d\n", getpid());
    printf("global_init addr: %p\n", (void *)&global_init);
    printf("global_uninit addr: %p\n", (void *)&global_uninit);
    printf("local_var addr: %p\n", (void *)&local_var);

    while (1) {
        sleep(10);
    }
    return 0;
}

编译运行后，在另一个终端执行：

bash复制cat /proc/<PID>/maps

输出大概长这样（不同环境有差异，但基本结构一致）：

text复制00400000-00401000 r-xp 00000000 08:01 1234567        /home/user/demo
00401000-00402000 r--p 00001000 08:01 1234567        /home/user/demo
00402000-00403000 rw-p 00002000 08:01 1234567        /home/user/demo
...
7ffc5a000000-7ffc5a021000 rw-p 00000000 00:00 0     [stack]
7ffc5a021000-7ffc5a022000 r--p 00000000 00:00 0     [vvar]

注意看第一列地址区间、第二列权限（r读/w写/x执行/p私有/s共享）、最后一列映射对象。这种方式比任何教科书都能直观告诉你：你写的代码、全局变量、栈到底站在内存地图的哪个位置。练习时建议对照着看：打印出来的global_init addr落在maps里r--p对应的数据段区域，local_var addr落在[stack]区间内。

这个技能在排查内存问题、动态库加载失败、编译选项导致的段错误时，都非常有用。排查问题时先看一眼maps，心里基本就有底了。

3. 进程控制：从fork到exec再到wait的完整生命周期

3.1 fork()：一次调用、两次返回

进程控制的起点，是fork。它的行为一句话概括：由当前进程复制出一个新的子进程。子进程是父进程的“克隆”：拥有独立的地址空间拷贝、独立的文件描述符表、独立的环境变量拷贝，但代码段与父进程共享（只读的机器指令没有复制必要）。

fork最违反直觉的地方在返回值。它调用一次，却返回两次：在父进程中返回子进程PID（一个大于0的整数），在子进程中返回0，失败时父进程返回-1并设置errno。利用返回值，同一段代码可以在父子进程里走向不同分支：

c复制#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid = fork();

    if (pid < 0) {
        perror("fork failed");
        return 1;
    } else if (pid == 0) {
        // 子进程
        printf("Child process, I get pid %d, my parent is %d\n", getpid(), getppid());
    } else {
        // 父进程
        printf("Parent process, child pid is %d, my pid is %d\n", pid, getpid());
        wait(NULL);
    }

    return 0;
}

执行后结果大致是：

text复制Parent process, child pid is 12345, my pid is 12344
Child process, I get pid 12345, my parent is 12344

为什么一次调用两次返回？因为fork执行到返回时，内核把当前进程的上下文复制了一份，这两份上下文都会从fork的返回点继续执行，唯一的差别就是返回值寄存器里的内容不同。现代Linux还做了写时复制优化（Copy-On-Write，COW）：创建子进程初期，父子进程共享同一批物理页，只有某一方真正修改数据页时才触发页复制。这大幅降低了fork的成本，也让“先fork再exec”这套组合变得非常廉价。

实操心得：在fork之前创建的线程会导致复杂问题，多线程程序里调用fork尤其危险，子进程只会留下调用fork的线程，其它线程都不见了，但锁的状态可能还停留在“被其它线程持有”的状态，子进程一上锁就死锁。如果必须fork，最好在单线程状态下进行，或者用pthread_atfork注册回调。

3.2 exec族：换程序不换壳

fork复制出来的子进程，往往不是直接干活的。真正常用的组合是fork出一个子进程，然后马上在子进程中调用exec系列函数，把当前进程的代码段、数据段、堆、栈全部替换成新程序的镜像，PID不变，文件描述符不变，但跑的程序已经彻底换掉了。

exec族函数有六个变体：

• execl：参数以可变参数列表传入，路径+每个参数，最后以(char *)NULL结尾。
• execv：参数通过字符串数组传入。
• execle：在execl基础上支持传递自定义环境变量数组。
• execve：在execv基础上支持自定义环境变量，是真正绕不开的系统调用层面函数。
• execvp：在execv基础上使用PATH路径搜索程序。
• execvpe：在execvp基础上自定义环境变量。

看一个标准用法：

c复制#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid = fork();

    if (pid == 0) {
        // 子进程中直接替换为ls命令
        execl("/bin/ls", "ls", "-l", "/tmp", (char *)NULL);
        // 若execl失败才会走到这
        perror("execl failed");
        return 1;
    }

    wait(NULL);
    return 0;
}

注意第一个参数是路径，第二个参数是argv[0]，后续是argv[1]、argv[2]...，一定要以NULL结尾。这里有一个很容易犯的错：第二个参数“ls”虽然看起来只是程序名，但它会成为新进程的argv[0]，很多程序会据此判断自己的名字（比如bash会根据argv[0]决定是否作为登录shell），不要随意乱传。

还有一点：exec成功后将不会返回，因为当前进程映像已经被替换了，所以不需要考虑exec之后的返回路径。正常模式下，exec之后的代码只会在exec失败时被执行。很多初学者在这里逻辑混乱，以为exec之后还能做清理工作，实际上如果exec前打开了文件、分配了内存，最好在exec前处理好，或者利用文件描述符的FD_CLOEXEC标志让exec时自动关闭。

3.3 回收僵尸：wait与waitpid的正确姿势

进程控制的最后一块拼图是回收子进程。如果一个子进程先结束，而父进程没有调用wait/waitpid去收尸，这个子进程会进入“僵尸状态”（Zombie）。僵尸进程不占CPU，但会留在内核进程表中，占用一个PID和部分资源。如果父进程长期不回收，大量子进程变成僵尸，系统最终可能因为PID耗尽而无法创建新进程。

父进程可以调用wait或waitpid来等待子进程终止，获取其退出状态：

c复制#include <sys/wait.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
    pid_t pid = fork();

    if (pid == 0) {
        printf("Child running...\n");
        _exit(42);  // 子进程以42退出
    }

    int status;
    pid_t ret = waitpid(pid, &status, 0);
    if (ret == pid) {
        if (WIFEXITED(status)) {
            printf("Child exited with %d\n", WEXITSTATUS(status));
        } else if (WIFSIGNALED(status)) {
            printf("Child killed by signal %d\n", WTERMSIG(status));
        }
    }

    return 0;
}

一些关键点：

• wait等价于waitpid(-1, &status, 0)，任意一个子进程结束都会返回。
• waitpid(pid, &status, 0)会阻塞等待指定PID的子进程退出。
• 想非阻塞轮询，可以传入WNOHANG标志，子进程未退出时立即返回0。
• WIFEXITED、WEXITSTATUS、WIFSIGNALED、WTERMSIG这些宏用来解析status，别直接拿status当退出码看，退出码只占低8位，还有信号、核心转储等标志位混在其中。
• 如果父进程先于子进程退出，子进程会被1号进程（init/systemd）收养，统一收尸，避免它变成永久僵尸。

实际项目中，父进程通常会在循环里配合SIGCHLD信号来处理子进程退出。当子进程状态变化时，内核会向父进程发送SIGCHLD信号，父进程在信号处理函数里调用waitpid(-1, &status, WNOHANG)，循环回收所有已经退出的子进程，这样就不会因为某个子进程长时间不退出而阻塞父进程的正常工作。

这里有一个容易踩的坑：刚从信号处理函数返回时，主流程如果又去waitpid，可能发现子进程已经被处理完了，返回-1且errno设为ECHILD。在信号处理函数里用WNOHANG+循环清空，主流程再用waitpid轮不到任何子进程，这个现象是正常的，不代表错误。

4. 搭建一个迷你shell：把三块知识串起来

4.1 设计思路：用不到100行代码打通“环境变量+地址空间+进程控制”

讲了这么多，如果只停留在概念层面，总觉得缺了一口气。我建议你动手做一个非常迷你的shell，把前面三块知识全部用起来。

一个shell的核心逻辑很简单，可以分成四步：

1. 打印提示符，读取用户输入的一行命令。
2. 解析命令，把字符串拆成程序名和参数列表。
3. 调用fork创建子进程，在子进程中调用execvp执行命令。
4. 父进程调用waitpid等待子进程结束，然后重新回到第一步。

这不就是把本章的fork、exec、wait再用一遍吗？没错，真实的bash虽然做了大量额外工作（管道、重定向、历史、补全、作业控制），但内核交互部分的基本骨架就是这套fork+exec+wait。

顺带说一句，环境变量在这里也扮演重要角色：shell自己维护一份环境变量表，执行外部命令时通过PATH搜索可执行文件，命令执行完环境变量自然带过去。所以代码里要留一个处理export的内建命令入口。

4.2 核心实现：30行代码能跑

下面这个版本，是我在很多教学场合用过的“最简可用版”：

c复制#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>

#define CMD_MAX 256
#define ARG_MAX 64

int main(void) {
    char buf[CMD_MAX];
    char *args[ARG_MAX];
    int bg;

    while (1) {
        printf("mysh> ");
        fflush(stdout);

        if (!fgets(buf, sizeof(buf), stdin)) {
            break;  // Ctrl+D退出
        }

        // 去掉换行符
        buf[strcspn(buf, "\n")] = '\0';

        // 空命令直接跳过
        if (strlen(buf) == 0) {
            continue;
        }

        // 简单解析：按空格分割
        int argc = 0;
        char *token = strtok(buf, " ");
        while (token && argc < ARG_MAX - 1) {
            args[argc++] = token;
            token = strtok(NULL, " ");
        }
        args[argc] = NULL;

        if (argc == 0) {
            continue;
        }

        // 内建命令：cd 和 export
        if (strcmp(args[0], "cd") == 0) {
            if (chdir(args[1] ? args[1] : "/") != 0) {
                perror("cd failed");
            }
            continue;
        }
        if (strcmp(args[0], "export") == 0) {
            if (argc >= 2) {
                if (putenv(strdup(args[1])) != 0) {
                    perror("export failed");
                }
            }
            continue;
        }

        // 处理后台运行：末尾 & 符号
        bg = 0;
        if (argc > 0 && strcmp(args[argc - 1], "&") == 0) {
            bg = 1;
            args[--argc] = NULL;
        }

        pid_t pid = fork();
        if (pid < 0) {
            perror("fork failed");
            continue;
        }

        if (pid == 0) {
            // 子进程
            execvp(args[0], args);
            // 找不到命令才会到这里
            printf("mysh: %s: command not found\n", args[0]);
            exit(127);
        }

        // 父进程
        if (!bg) {
            waitpid(pid, NULL, 0);
        } else {
            printf("[%d] started\n", pid);
        }
    }

    return 0;
}

这段代码里值得注意的细节有几个：

• strtok是原地修改字符串的，切分完原来的buf内容结构就变了，这对本例够用，但如果要处理带引号的复杂命令，就必须换按字符扫描的分词方式。
• chdir是shell内部使用的函数，它改变的是当前进程的工作目录。如果不用内建方式，而是在子进程里调用cd，那只会改子进程的工作目录，父进程shell的工作目录不会变，所以cd必须作为内建命令处理。
• putenv里用了strdup，因为putenv不拷贝字符串。用一个栈上数组传给它，函数返回后环境变量区指向悬空内存，这是极隐蔽的bug。
• 后台执行&的场景里，父进程不等待子进程，这其实就是最简版的“作业控制”雏形。

4.3 动手验证：把这台小机器转起来

把代码存成myshell.c，编译运行：

bash复制gcc -o myshell myshell.c
./myshell

然后依次输入：

plaintext复制mysh> ls -l /tmp
mysh> echo hello world
mysh> export MY_SHELL=test
mysh> cd /etc
mysh> pwd
mysh> sleep 5 &
[12345] started

看到外部命令正常执行、cd能真正切换目录、export之后echo $MY_SHELL能打印出来、后台任务不阻塞shell，就说明fork+exec+wait这套基础设施已经被你真正跑通了。

顺着这个代码继续扩展，还可以加管道支持（解析|字符，创建pipe，把前一个进程的stdout接到后一个进程的stdin）、重定向（>和<）、通配符展开（用glob函数）、命令历史（readline库）等。每加一个功能，你对进程控制的理解就会更扎实一层。

5. 常见问题与避坑手册：来自真实现场的排查笔记

5.1 环境变量相关问题

问题一：为什么我在程序里调setenv，shell外部env看不到我设置的新变量？

这是对“进程隔离”理解不够导致的。程序是shell的子进程，子进程修改的是自己那份环境变量拷贝，对父进程shell毫无影响。要想让shell里生效，只能用export在shell层设置，或者修改shell的配置文件。

问题二：crontab里找不到命令，但在终端可以。

crontab默认使用的环境非常精简，PATH往往只有一个/usr/bin:/bin，而且不会读你的~/.bashrc。解决办法是在脚本开头显式设置PATH和需要用的环境变量：

bash复制#!/bin/bash
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export JAVA_HOME=/opt/jdk17

问题三：动态库找不到，已设置LD_LIBRARY_PATH仍报错。

检查一下设置LD_LIBRARY_PATH的时机和传递链。用systemd服务启动时，需要写在unit文件的Environment=字段里，或者通过EnvironmentFile=指定。如果确认已经设置，检查是否因为程序中调用setuid/setgid，内核会忽略这些环境变量以防范风险。

5.2 地址空间相关问题

问题一：为什么malloc后内存占用没涨，写一遍数据才涨？

这是虚拟内存与物理内存分离导致的。malloc分配虚拟地址成功后，物理页要等第一次访问才会真正分配。用top看VIRT（虚拟内存）跳得快，RES（常驻内存）按需涨。写共享大数组时，可以先memset一遍来“热”内存，在某些性能评测场景常用这个技巧。

问题二：递归过深导致段错误，该怎么定位？

先用gdb跑一遍程序，段错误时bt看栈回溯，一般能直接定位到递归调用层。然后检查递归终止条件、每次调用的栈占用。如果真的嫌弃默认8MB栈不够，可以用ulimit -s 65536临时调整（单位KB），或者用setrlimit在程序里调整。但“栈不够”常常只是一个表象，更可能是递归逻辑有死循环，先查逻辑再调限制。

问题三：查看进程内存到底怎么用才高效？

优先用/proc/PID/status里的VmSize、VmRSS、VmData等字段。VmData反映数据段+堆的虚拟大小，对定位内存泄漏很有用。如果发现VmRSS持续增长而释放后不下降，结合valgrind定位泄漏点更高效。

5.3 进程控制相关问题

问题一：为什么产生了大量僵尸进程？

因为父进程没调用wait/waitpid。常见场景是父进程fork了很多子进程，但不回收。解决办法：在父进程里注册SIGCHLD信号处理函数，在里面循环调用waitpid(-1, NULL, WNOHANG)回收；或者更简单地，如果确实不关心子进程状态，在main最开始执行signal(SIGCHLD, SIG_IGN)，让init进程自动收养子进程并回收。

问题二：exec成功之后，原来分配的内存没释放，会不会泄漏？

不会。exec会用新程序镜像完整替换当前进程的地址空间，所有堆内存、栈内存全部作废重来。但需要注意：内存是没了，文件描述符、锁、共享内存段这类内核资源不会自动关闭，所以fork后exec前，别随意打开不必要的文件，或者给fd设置O_CLOEXEC。

问题三：waitpid返回-1但errno不是ECHILD，可能是什么？

还可能被信号中断，errno是EINTR。这时候正确的做法是循环重试waitpid。尤其是在信号处理函数中等待子进程时，EINTR几乎必然会遇到。用循环包一下：

c复制while (waitpid(pid, &status, 0) < 0 && errno == EINTR) {
    continue;
}

问题四：多线程程序里fork后死锁。

多线程程序fork产生的子进程只有调用fork的那个线程，但是其它线程持有的锁状态被复制过来，却没有任何线程去释放它们。处理办法是使用pthread_atfork注册prepare、parent、child三个回调，在fork前上锁、fork后解锁。但更稳妥的策略是：架构上尽量避免多线程进程里调用fork。

最后分享一个我自己调试时常用的排查套路：遇到“程序行为像幽灵一样”的问题，先别急着改代码，打开strace -f -o trace.log ./your_program看一次系统调用轨迹。fork、exec、wait、修改环境变量、读取配置文件，每一步都会以系统调用的形式留下痕迹。很多时候，看一眼strace输出，问题原因立刻浮出水面，比盲目加日志高效得多。这套“环境变量+地址空间+进程控制”的组合拳，只要你完整跑通一次迷你shell实验，后面写守护进程、写构建系统、调线上进程崩溃，都会更有底气。