一、可重入函数：信号处理的第一大 “坑”

信号的异步性意味着信号处理函数可能在任意时刻打断主程序的执行流程—— 主程序执行到一半，突然跳转到信号处理函数，处理完后再切回主程序继续执行。这种特性极易引发函数重入问题，导致数据错乱、程序崩溃，这也是信号处理中最容易踩的坑。

1.1 什么是重入？什么是可重入函数？

1.1.1 重入的定义

当一个函数被不同的控制流程调用，在第一次调用还未执行完毕时，再次进入该函数执行，这种现象称为函数重入。

在信号场景中，重入的典型场景是：

主程序正在执行函数 A → 产生信号，触发信号处理函数 → 信号处理函数中又调用了函数 A → 函数 A 发生重入。

1.1.2 可重入 / 不可重入函数的定义

• 可重入函数（Reentrant Function）：多个控制流程同时调用该函数，不会导致数据错乱、逻辑异常的函数，即支持重入的函数。
• 不可重入函数（Non-reentrant Function）：多个控制流程同时调用时，会因访问共享资源（全局变量、静态变量、堆内存等）导致数据错乱的函数，即不支持重入的函数。

用通俗的话讲：可重入函数是 “独来独往” 的，只访问自己的局部变量和参数；不可重入函数是 “爱占共享资源” 的，会访问全局 / 静态资源，或调用其他不可重入函数。

1.2 信号场景下的重入问题演示

我们以链表插入为例，模拟信号处理中最典型的重入问题，直观感受数据错乱的原因。

1.2.1 案例场景

主程序调用insert函数向全局链表插入节点node1，执行到一半时，被信号处理函数打断；信号处理函数也调用insert函数向同一个全局链表插入节点node2，执行完成后切回主程序；主程序继续执行insert的剩余逻辑，最终导致链表数据错乱。

1.2.2 实战代码

代码语言：javascript

AI代码解释

#include <iostream>
#include <unistd.h>
#include <signal.h>
#include <cstdlib>
using namespace std;

// 定义链表节点结构
typedef struct node
{
    int val;
    struct node* next;
} node_t;

// 全局链表头节点（共享资源）
node_t* head = NULL;
// 定义两个全局节点
node_t node1 = {10, NULL};
node_t node2 = {20, NULL};

// 链表插入函数（向头部插入，不可重入）
void insert(node_t* p)
{
    // 步骤1：将新节点的next指向原头节点
    p->next = head;
    // 模拟耗时操作，增加信号中断的概率
    usleep(100000);
    // 步骤2：将头节点更新为新节点
    head = p;
    cout << "插入节点" << p->val << "完成" << endl;
}

// 信号处理函数：调用insert插入node2
void sig_handler(int signo)
{
    cout << "\n信号处理函数执行：插入node2" << endl;
    insert(&node2);
}

int main()
{
    // 注册SIGINT信号处理函数，按下Ctrl+C触发
    signal(SIGINT, sig_handler);
    cout << "进程PID：" << getpid() << endl;
    cout << "主程序执行：插入node1（按下Ctrl+C触发信号）" << endl;
    
    // 主程序插入node1，大概率会被信号中断
    insert(&node1);
    
    // 遍历链表，查看结果
    cout << "\n最终链表：";
    node_t* cur = head;
    while (cur)
    {
        cout << cur->val << " -> ";
        cur = cur->next;
    }
    cout << "NULL" << endl;

    return 0;
}

1.2.3 编译运行与测试

代码语言：javascript

AI代码解释

g++ reentrant.c -o reentrant
./reentrant

运行后立即按下 Ctrl+C，触发信号中断，输出结果如下：

代码语言：javascript

AI代码解释

进程PID：12345
主程序执行：插入node1（按下Ctrl+C触发信号）

信号处理函数执行：插入node2
插入节点20完成
插入节点10完成

最终链表：10 -> NULL

1.2.4 问题分析

从结果可以看到，节点 20 明明插入成功，但最终链表中只有节点 10，数据发生了错乱，根源在于insert 函数是不可重入的，且访问了全局链表头节点，具体执行流程如下：

1. 主程序执行insert(&node1)，完成步骤 1：node1->next = NULL（原 head 为 NULL），随后进入耗时操作；
2. 按下 Ctrl+C，触发 SIGINT 信号，打断主程序，执行信号处理函数sig_handler；
3. 信号处理函数执行insert(&node2)，完成步骤 1：node2->next = NULL，步骤 2：head = &node2，插入完成，此时head指向 node2；
4. 信号处理完成，切回主程序，继续执行insert(&node1)的步骤 2：head = &node1，将head重新指向 node1；
5. 最终node2被 “覆盖”，链表中只有node1，数据错乱。

1.3 不可重入函数的判定条件

只要满足以下任意一个条件，该函数就是不可重入的，绝对不能在信号处理函数中调用：

1. 访问全局变量、静态变量：如上述案例中的全局链表头head，多个流程同时修改会导致数据不一致；
2. 调用 malloc/free：malloc/free 通过全局链表管理堆内存，重入会导致堆结构错乱；
3. 调用标准 I/O 库函数：如 printf、scanf、fopen 等，标准 I/O 库的实现依赖全局数据结构（如缓冲区），重入会导致 I/O 错乱；
4. 调用其他不可重入函数：函数的可重入性具有传递性，调用不可重入函数的函数，自身也不可重入。

1.4 可重入函数的设计原则

要编写支持信号场景的可重入函数，需遵循以下核心原则，简单来说就是 “不碰共享资源，只靠自己”：

1. 仅访问局部变量和函数参数：局部变量和参数存储在函数栈中，每个控制流程有独立的栈空间，不会冲突；
2. 不调用任何不可重入函数：避免传递不可重入性；
3. 不修改全局变量、静态变量：若必须访问共享资源，需通过信号量、互斥锁等同步机制保护（信号处理中慎用锁，易引发死锁）；
4. 操作原子化：对共享资源的修改尽量做成 “一步完成” 的原子操作，减少被信号中断的概率。

1.5 信号处理中避免重入问题的解决方案

在信号处理中，避免重入问题的核心思路是 **“让信号处理函数尽可能简单”**，具体有三种解决方案，优先级从高到低：

方案 1：信号处理函数仅设置全局标志位（推荐）

信号处理函数不执行任何复杂逻辑，仅设置一个全局标志位，主程序轮询该标志位，检测到标志位被置位后，再在主程序中执行具体的处理逻辑。核心优势：信号处理函数执行时间极短，被中断的概率低，且主程序的处理逻辑在单流程中执行，无重入问题。

实战代码（优化上述链表案例）

代码语言：javascript

AI代码解释

#include <iostream>
#include <unistd.h>
#include <signal.h>
#include <cstdlib>
using namespace std;

typedef struct node
{
    int val;
    struct node* next;
} node_t;

node_t* head = NULL;
node_t node1 = {10, NULL};
node_t node2 = {20, NULL};
// 全局标志位：标记是否收到SIGINT信号
volatile sig_atomic_t sig_received = 0;

// 链表插入函数（不可重入，仅在主程序中调用）
void insert(node_t* p)
{
    p->next = head;
    usleep(100000);
    head = p;
    cout << "插入节点" << p->val << "完成" << endl;
}

// 信号处理函数：仅设置标志位（原子操作）
void sig_handler(int signo)
{
    sig_received = 1;
    cout << "\n收到SIGINT信号，置位标志位" << endl;
}

int main()
{
    signal(SIGINT, sig_handler);
    cout << "进程PID：" << getpid() << endl;
    cout << "主程序执行：插入node1（按下Ctrl+C触发信号）" << endl;
    
    // 主程序插入node1
    insert(&node1);
    
    // 轮询标志位，检测到信号后执行后续处理
    if (sig_received)
    {
        cout << "主程序检测到信号，插入node2" << endl;
        insert(&node2);
    }
    
    // 遍历链表
    cout << "\n最终链表：";
    node_t* cur = head;
    while (cur)
    {
        cout << cur->val << " -> ";
        cur = cur->next;
    }
    cout << "NULL" << endl;

    return 0;
}

运行结果：无论何时按下 Ctrl+C，链表插入都不会错乱，因为insert函数仅在主程序单流程中执行。

方案 2：利用 sigaction 的 sa_mask 屏蔽相关信号

使用sigaction注册信号处理函数时，通过sa_mask字段设置临时屏蔽集，在信号处理函数执行期间，屏蔽当前信号和其他可能引发重入的信号，避免嵌套中断。核心优势：从根本上阻止了重入的发生，适合必须在信号处理函数中执行少量逻辑的场景。

方案 3：使用可重入的系统调用替代库函数

若信号处理函数中必须执行 I/O、内存操作，优先使用系统调用（如 write、read、brk）替代标准库函数（如 printf、malloc），系统调用是内核实现的，具有原子性和可重入性。注意：系统调用的功能较为基础，需要自己封装上层逻辑。

1.6 高频面试题：为什么 printf 不能在信号处理函数中调用？

答案：

1. printf 是标准 I/O 库函数，不是系统调用，其实现依赖全局的缓冲区结构；
2. 主程序执行 printf 时，会操作缓冲区，若此时被信号中断，信号处理函数中再调用 printf，会导致缓冲区的重入访问，造成数据错乱、输出乱码；
3. 替代方案：使用write(STDOUT_FILENO, ...)系统调用实现打印，write 是可重入的。

替代实战代码（信号处理中安全打印）

代码语言：javascript

AI代码解释

#include <iostream>
#include <unistd.h>
#include <signal.h>
#include <cstring>
using namespace std;

// 信号处理函数中使用write系统调用打印
void sig_handler(int signo)
{
    const char* msg = "收到SIGINT信号，安全打印\n";
    // write是系统调用，可重入
    write(STDOUT_FILENO, msg, strlen(msg));
}

int main()
{
    signal(SIGINT, sig_handler);
    while (true)
    {
        cout << "主程序正常打印..." << endl;
        sleep(1);
    }
    return 0;
}

二、volatile 关键字：破解编译器优化的信号 “失效” 问题

在信号处理中，我们经常会用全局标志位来实现主程序和信号处理函数的通信，但在开启编译器优化后（如-O2），会出现标志位被修改但主程序检测不到的情况，信号仿佛 “失效” 了 —— 这一问题的根源是编译器的寄存器优化，而解决它的关键就是volatile 关键字。

2.1 编译器优化导致的信号 “失效” 问题

我们先看一个简单的案例，直观感受问题现象：主程序轮询全局标志位flag，信号处理函数修改flag，开启编译器优化后，主程序永远检测不到flag的变化。

2.1.1 实战代码（未加 volatile）

代码语言：javascript

AI代码解释

#include <stdio.h>
#include <signal.h>
#include <unistd.h>

// 全局标志位，未加volatile
int flag = 0;

// 信号处理函数：将flag从0置1
void sig_handler(int sig)
{
    printf("信号处理函数：flag = 0 → 1\n");
    flag = 1;
}

int main()
{
    // 注册SIGINT信号，Ctrl+C触发
    signal(SIGINT, sig_handler);
    printf("进程PID：%d，flag初始值：%d\n", getpid(), flag);
    printf("按下Ctrl+C修改flag，主程序轮询flag...\n");
    
    // 轮询flag，为0则一直循环
    while (!flag);
    
    // 若flag置1，退出循环并打印
    printf("主程序检测到flag=1，进程正常退出\n");
    return 0;
}

2.1.2 测试 1：不开启编译器优化（正常运行）

代码语言：javascript

AI代码解释

gcc volatile.c -o volatile
./volatile

运行后按下 Ctrl+C，输出结果如下：

代码语言：javascript

AI代码解释

进程PID：12346，flag初始值：0
按下Ctrl+C修改flag，主程序轮询flag...
^C信号处理函数：flag = 0 → 1
主程序检测到flag=1，进程正常退出

现象：信号处理函数修改flag后，主程序检测到变化，退出循环，程序正常结束。

2.1.3 测试 2：开启编译器优化（O2），信号 “失效”

代码语言：javascript

AI代码解释

gcc volatile.c -o volatile -O2
./volatile

运行后按下 Ctrl+C，输出结果如下：

代码语言：javascript

AI代码解释

进程PID：12347，flag初始值：0
按下Ctrl+C修改flag，主程序轮询flag...
^C信号处理函数：flag = 0 → 1
^C信号处理函数：flag = 0 → 1
^C信号处理函数：flag = 0 → 1

现象：信号处理函数确实执行了，flag被修改为 1，但主程序的while (!flag)循环永远执行，检测不到flag的变化，信号仿佛 “失效” 了。

2.2 问题根源：编译器的寄存器优化

为什么开启-O2优化后会出现这种问题？核心原因是编译器对全局变量的寄存器缓存优化，具体分析如下：

1. 主程序中的while (!flag)是一个死循环，编译器在-O2优化下，会认为flag是一个只读变量（主程序中没有修改flag的代码）；
2. 编译器将flag的值缓存到 CPU 的寄存器中，主程序的while循环直接检测寄存器中的值，而不是内存中的实际值；
3. 信号处理函数修改的是内存中的 flag 值，但寄存器中的值始终为 0，因此主程序永远检测不到flag的变化，循环无法退出。

简单来说：编译器优化让主程序 “读不到” 内存中被信号处理函数修改后的真实值，导致数据不一致。

2.3 volatile 关键字：保持内存的可见性

2.3.1 volatile 的核心作用

volatile是 C/C++ 的关键字，中文译为 “易变的”，其核心作用是：

告知编译器，被该关键字修饰的变量是 “易变的”，不允许对其进行寄存器缓存优化，对该变量的任何读 / 写操作，都必须直接操作/访问内存中的实际值，而不能操作寄存器中的缓存值。

简单来说，volatile打破了编译器的寄存器优化，保证了变量的内存可见性—— 任何流程对变量的修改，其他流程都能立即看到内存中的真实值。

2.3.2 加 volatile 后的解决方案

只需将全局标志位flag用volatile修饰，即可解决上述问题，修改后的核心代码如下：

代码语言：javascript

AI代码解释

// 加volatile修饰，禁止编译器优化
volatile int flag = 0;

2.3.3 测试 3：加 volatile+O2 优化（正常运行）

代码语言：javascript

AI代码解释

gcc volatile.c -o volatile -O2
./volatile

运行后按下 Ctrl+C，输出结果如下：

代码语言：javascript

AI代码解释

进程PID：12348，flag初始值：0
按下Ctrl+C修改flag，主程序轮询flag...
^C信号处理函数：flag = 0 → 1
主程序检测到flag=1，进程正常退出

现象：即使开启-O2优化，主程序也能立即检测到内存中flag的变化，循环退出，程序正常结束。

2.4 信号场景中 volatile 的使用规范

在 Linux 进程信号开发中，volatile几乎是全局标志位的 “标配”，使用时需遵循以下规范，避免误用：

规范 1：必须修饰信号通信的全局 / 静态变量

只有主程序和信号处理函数共享的变量（如标志位）需要加volatile，局部变量无需加 —— 局部变量存储在栈中，每个控制流程有独立的栈，不会被编译器优化到寄存器。

规范 2：结合sig_atomic_t类型使用（更安全）

sig_atomic_t是 C 标准定义的原子数据类型，其特点是：对该类型变量的读 / 写操作是原子的，不会被信号中断。

在信号场景中，推荐将volatile和sig_atomic_t结合使用，定义全局标志位：

代码语言：javascript

AI代码解释

// 信号通信的全局标志位：volatile保证内存可见性，sig_atomic_t保证操作原子性
volatile sig_atomic_t flag = 0;

为什么需要原子性？若变量是 int 类型（4 字节），某些 CPU 对其的写操作可能分为 “低 2 字节 + 高 2 字节” 两步，若在第一步执行后被信号中断，会导致变量值不完整；而sig_atomic_t的操作是一步完成的，避免了这种问题。

规范 3：volatile 不保证 “同步性”，仅保证 “可见性”

重要误区：很多开发者认为volatile能保证多线程 / 多流程的同步，这是错误的！

• volatile的唯一作用：保证变量的内存可见性，禁止编译器优化；
• volatile不保证操作的原子性（除了sig_atomic_t），也不保证多流程的同步性；
• 若多个流程同时修改一个volatile变量，仍会导致数据竞争，需要通过锁、信号量等同步机制保护。

简单来说：volatile 解决 “读不到真实值” 的问题，同步机制解决 “多流程同时修改” 的问题。

规范 4：仅在异步场景中使用，避免滥用

volatile会禁止编译器对变量的优化，增加了内存访问的开销，因此仅在异步场景（信号、多线程、中断）中使用，普通同步场景无需加，避免不必要的性能损耗。

2.5 高频面试题：volatile 关键字的作用？在信号场景中如何使用？

答案：

1. 核心作用：禁止编译器对变量的寄存器缓存优化，保证变量的内存可见性，确保对变量的读 / 写操作都直接访问内存，而非寄存器；
2. 信号场景中的问题：编译器优化会导致主程序读不到信号处理函数修改的全局变量值，信号仿佛 “失效”；
3. 正确使用：用volatile修饰主程序和信号处理函数共享的全局 / 静态标志位，并结合sig_atomic_t类型，保证操作的原子性，定义为volatile sig_atomic_t flag = 0;；
4. 注意事项：volatile 仅保证可见性，不保证同步性，多个流程同时修改变量时仍需同步机制。

三、SIGCHLD 信号：优雅解决僵尸进程问题

在 Linux 进程管理中，僵尸进程是一个经典问题：子进程退出后，父进程未及时回收其退出状态，子进程的 PCB 会一直保留在系统中，占用系统资源，最终导致系统资源耗尽。

传统的解决方案是父进程主动调用 wait/waitpid（阻塞或轮询），但阻塞会导致父进程无法处理自身工作，轮询会增加程序复杂度 —— 而SIGCHLD 信号为我们提供了一种异步、优雅的解决方案，让父进程 “被动接收” 子进程的退出通知，按需回收。

3.1 僵尸进程的产生与传统解决方案回顾

3.1.1 僵尸进程的产生条件

子进程退出后，会向父进程发送SIGCHLD 信号，并将自己置为僵尸状态（Zombie），等待父进程回收；若父进程：

1. 未处理 SIGCHLD 信号；
2. 未调用 wait/waitpid 回收子进程的退出状态；
3. 父进程自身未退出；

则子进程的 PCB 会一直保留，成为僵尸进程。