当前位置：首页 > news >正文

风中低语：Linux 信号处理的艺术与实践

news 2026/3/26 17:05:37

1、信号的处理时机

直奔主题，谈谈信号的 ·处理时机·

1.1、处理情况

普通情况

所谓的普通情况就是指信号没有被阻塞，直接产生，记录未决信息后，再进行处理

在这种情况下，信号是不会被立即递达的，也就无法立即处理，需要等待合适的时机

特殊情况

当信号被阻塞后，信号产生时，记录未决信息，此时信号被阻塞了，也不会进行处理

当阻塞解除后，信号会被立即递达，此时信号会被立即处理

特殊情况很好理解，就好比往气球里吹气，当气球炸了，空气会被立即释放，因为空气是被气球阻塞的，当气球炸了之后（阻塞解除），空气立马往外跑，这不就是立即递达、立即处理吗？

通情况就有点难搞了，它需要等待 “合适” 的时机，才能被递达，继而被处理

1.2、“合适” 的时机

信号的产生是异步的

也就是说，信号可能随时产生，当信号产生时，**进程可能在处理更重要的事，**此时贸然处理信号显然不够明智

比如进程正在执行一个重要的IO，突然一个终止信号发出，IO立即终止，对进程、磁盘都不好

因此信号在产生后，需要等进程将更重要的事忙完后（合适的时机），才进行处理

合适的时机：进程从内核态返回用户态时，会在操作系统的指导下，对信号进行检测及处理

至于处理动作，分为：默认动作、忽略、用户自定义

搞清楚 “合适” 的时机后，接下来需要学习用户态和内核态相关知识

2、用户态与内核态

对于用户态、内核态的理解及引出的进程地址空间和信号处理过程相关知识是本文的重难点

2.1、概念

先来看看什么是用户态和内核态

用户态：执行用户所写的代码时，就属于用户态
内核态：执行操作系统的代码时，就属于内核态

自己写的代码被执行很好理解，操作系统的代码是什么？

操作系统也是由大量代码构成的
在对进程进行调度、执行系统调用、异常、中断、陷阱等，都需要借助操作系统之手
此时执行的就是操作系统的代码

也就是说，用户态与内核态是两种不同的状态，必然存在相互转换的情况

用户态切换为内核态：

当进程时间片到了之后，进行进程切换动作
调用系统调用接口，比如 open、close、read、write 等
产生异常、中断、陷阱等

内核态切换为用户态：

进程切换完毕后，运行相应的进程
系统调用结束后
异常、中断、陷阱等处理完毕

信号的处理时机就是内核态切换为用户态，也就是当把更重要的事做完后，进程才会在操作系统的指导下，对信号进行检测、处理

下面来结合进程地址空间深入理解操作系统的代码及状态切换的相关内容（拓展知识）

2.2、重谈进程地址空间

首先简单回顾下进程地址空间的相关知识：

进程地址空间是虚拟的，依靠页表+MMU机制与真实的地址空间建立映射关系
每个进程都有自己的进程地址空间，不同进程地址空间中地址可能冲突，但实际上地址是独立的
进程地址空间可以让进程以统一的视角看待自己的代码和数据

在这里插入图片描述

不难发现，在进程地址空间中，存在1 GB的内核空间，每个进程都有，而这 1 GB 的空间中存储的就是操作系统相关代码和数据，并且这块区域采用内核级页表与真实地址空间进行映射

为什么要区分用户态与内核态？

内核空间中存储的可是操作系统的代码和数据，权限非常高，绝不允许随便一个进程对其造成影响
区域的合理划分也是为了更好的进行管理

在这里插入图片描述

所谓的执行操作系统的代码及系统调用，就是在使用这1 GB的内核空间

进程间具有独立性，比如存在用户空间中的代码和数据是不同的，难道多个进程需要存储多份操作系统的代码和数据吗？

当然不用，内核空间比较特殊，所有进程最终映射的都是同一块区域，也就是说，进程只是将操作系统代码和数据映射入自己的进程地址空间而已
而内核级页表不同于用户级页表，专注于对操作系统代码和数据进行映射，是很特殊的

当我们执行诸如open这类的系统调用时，会跑到内核空间中调用对应的函数

而跑到内核空间就是用户态切换为内核态了（用户空间切换至内核空间）

这个跑到是如何实现的呢？

在 CPU 中，存在一个 CR3 寄存器，这个寄存器的作用就是用来表征当前处于用户态还是内核态
当寄存器中的值为 3 时：表示正在执行用户的代码，也就是处于用户态
当寄存器中的值为 0 时：表示正在执行操作系统的代码，也就是处于内核态
通过一个寄存器，表征当前所处的状态，修改其中的值，就可以表示不同的状态，这是很聪明的做法

在这里插入图片描述

重谈进程地址空间后，得到以下结论

所有进程的用户空间 [0, 3] GB 是不一样的，并且每个进程都要有自己的用户级页表进行不同的映射
所有进程的内核空间 [3, 4] GB 是一样的，每个进程都可以看到同一张内核级页表，从而进行统一的映射，看到同一个操作系统
操作系统运行的本质其实就是在该进程的内核空间内运行的（最终映射的都是同一块区域）
系统调用的本质其实就是在调用库中对应的方法后，通过内核空间中的地址进行跳转调用

那么进程又是如何被调度的呢？

1. 操作系统的本质

操作系统也是软件啊，并且是一个死循环式等待指令的软件
存在一个硬件：操作系统时钟硬件，每隔一段时间向操作系统发送时钟中断

2. 进程被调度，就意味着它的时间片到了，操作系统会通过时钟中断，检测到是哪一个进程的时间片到了，然后通过系统调用函数schedule()保存进程的上下文数据，然后选择合适的进程去运行

2.3、信号的处理过程

当在内核态完成某种任务后，需要切回用户态，此时就可以对信号进行检测并处理了

情况1：信号被阻塞，信号产生/未产生

信号都被阻塞了，也就不需要处理信号，此时不用管，直接切回用户态就行了

下面的情况都是基于信号未被阻塞且信号已产生的前提

情况2：当前信号的执行动作为默认

大多数信号的默认执行动作都是终止进程，此时只需要把对应的进程干掉，然后切回用户态就行了

在这里插入图片描述

情况3：当前信号的执行动作为忽略

当信号执行动作为忽略时，不做出任何动作，直接返回用户态

在这里插入图片描述

情况4：当前信号的执行动作为用户自定义

这种情况就比较麻烦了，用户自定义的动作位于用户态中，也就是说，需要先切回用户态，把动作完成了，重新坠入内核态，最后才能带着进程的上下文相关数据，返回用户态

在内核态中，也可以直接执行自定义动作，为什么还要切回用户态执行自定义动作？

因为在内核态可以访问操作系统的代码和数据，自定义动作可能干出危害操作系统的事
在用户态中可以减少影响，并且可以做到溯源

为什么不在执行完自定义动作直接后返回进程？

因为自定义动作和待返回的进程属于不同的堆栈，是无法返回的
并且进程的上下文数据还在内核态中，所以需要先坠入内核态，才能正确返回用户态

在这里插入图片描述

==注意：用户自定义的动作，需要先切换至用户态中执行，执行结束后，还需要坠入内核态

通过一张图快速记录信号的处理过程

在这里插入图片描述

3、信号的捕捉

接下来谈谈信号是如何被捕捉的

3.1、内核如何实现信号的捕捉？

如果信号的执行动作为用户自定义动作，当信号递达时调用用户自定义动作，这一动作称为信号捕捉

用户自定义动作是位于用户空间中的

当内核态中任务完成，准备返回用户态时，检测到信号递达，并且此时为用户自定义动作，需要先切入用户态，完成用户自定义动作的执行；
因为用户自定义动作和待返回的函数属于不同的堆栈空间，它们之间也不存在调用与被调用的关系，是两个独立的执行流，需要先坠入内核态（通过 sigreturn() 坠入），再返回用户态（通过 sys_sigreturn() 返回）

在这里插入图片描述

3.2、sigaction

sigaction也可以用户自定义动作，比signal功能更丰富

在这里插入图片描述

代码语言：javascript

AI代码解释

#include <signal.h> int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact); struct sigaction { void (*sa_handler)(int); //自定义动作 void (*sa_sigaction)(int, siginfo_t *, void *); //实时信号相关，不用管 sigset_t sa_mask; //待屏蔽的信号集 int sa_flags; //一些选项，一般设为 0 void (*sa_restorer)(void); //实时信号相关，不用管 };

返回值：成功返回 0，失败返回 -1 并将错误码设置

参数1：待操作的信号

参数2：sigaction结构体，具体成员如上所示

参数3：保存修改前进程的sigaction结构体信息

这个函数的主要看点是sigaction结构体

其中部分字段不需要管，因为那些是与实时信号相关的，我们这里不讨论

重点可以看看sa_mask字段

sa_mask：当信号在执行用户自定义动作时，可以将部分信号进行屏蔽，直到用户自定义动作执行完成

也就是说，我们可以提前设置一批待阻塞的屏蔽信号集，当执行signum中的用户自定义动作时，这些屏蔽信号集中的信号将会被屏蔽（避免干扰用户自定义动作的执行），直到用户自定义动作执行完成

可以简单用一下sigaction函数

代码语言：javascript

AI代码解释

#include <iostream> #include <cassert> #include <cstring> #include <signal.h> #include <unistd.h> using namespace std; static void DisplayPending(const sigset_t pending) { // 打印 pending 表 cout << "当前进程的 pending 表为: "; int i = 1; while (i < 32) { if (sigismember(&pending, i)) cout << "1"; else cout << "0"; i++; } cout << endl; } static void handler(int signo) { cout << signo << " 号信号确实递达了" << endl; // 最终不退出进程 int n = 10; while (n--) { // 获取进程的 未决信号集 sigset_t pending; sigemptyset(&pending); int ret = sigpending(&pending); assert(ret == 0); (void)ret; // 欺骗编译器，避免 release 模式中出错 DisplayPending(pending); sleep(1); } } int main() { cout << "当前进程: " << getpid() << endl; //使用 sigaction 函数 struct sigaction act, oldact; //初始化结构体 memset(&act, 0, sizeof(act)); memset(&oldact, 0, sizeof(oldact)); //初始化 自定义动作 act.sa_handler = handler; //初始化 屏蔽信号集 sigaddset(&act.sa_mask, 3); sigaddset(&act.sa_mask, 4); sigaddset(&act.sa_mask, 5); //给 2号 信号注册自定义动作 sigaction(2, &act, &oldact); // 死循环 while (true); return 0; }

在这里插入图片描述

当 2 号信号的循环结束（10 秒），3、4、5 信号的阻塞状态解除，立即被递达，进程就被干掉了

注意：屏蔽信号集 ·sa_mask· 中已屏蔽的信号，在 ·用户自定义动作· 执行完成后，会自动解除 ·阻塞· 状态

4、信号部分小结

截至目前，信号处理的所有过程已经全部学习完毕了

信号产生阶段：有四种产生方式，包括键盘键入、系统调用,软件条件、硬件异常

信号保存阶段：内核中存在三张表，blcok表、pending表以及handler 表，信号在产生之后，存储在pending表中

信号处理阶段：信号在内核态切换回用户态时，才会被处理

在这里插入图片描述

===== 补充 =====

下面是一些补充知识

5、可重入函数

可以被重复进入的函数称为可重入函数

比如单链表头插的场景中，节点node1还未完成插入时，node2 也进行了头插，最终导致节点node2丢失，造成内存泄漏

在这里插入图片描述

导致内存泄漏的罪魁祸首：对于node1和node2来说，操作的单链表是同一个，同时进行并发访问（重入）会出现问题的，因为此时的单链表是临界资源

我们学过的函数中，90% 都是不可重入的

函数是否可重入是一个特性，而非缺点，需要正确看待

不可重入的条件：

调用了内存管理相关函数
调用了标准 I/O 库函数，因为其中很多实现都以不可重入的方式使用数据结构

6、volatile

volatile关键字可以避免编译器的优化，保证内存的可见性

比如在下面这个例子中

借助全局变量flag设计一个死循环的场景，在此之前将2 号信号进行自定义动作捕捉，具体动作为：将flag改为1，可以终止main函数中的循环体

代码语言：javascript

AI代码解释

#include <stdio.h> #include <signal.h> int flag = 0; // 一开始为假 void handler(int signo) { printf("%d号信号已经成功发出了\n", signo); flag = 1; } int main() { signal(2, handler); while(!flag); // 故意不写 while 的代码块 { } printf("进程已退出\n"); return 0; }

在这里插入图片描述

初步结果符合预期，2 号信号发出后，循环结束，程序正常退出

这段代码能符合我们预期般的正确运行是因为当前编译器默认的优化级别很低，没有出现意外情况

通过指令查询gcc 优化级别的相关信息

代码语言：javascript

AI代码解释

man gcc : /O1

在这里插入图片描述

其中数字越大，优化级别越高，理论上编译出来的程序性能会更好

事实真的如此吗？

让我们重新编译上面的程序，并指定优化级别为O1

代码语言：javascript

AI代码解释

gcc test2 test2.c -O1

编译成功后，再次运行程序

在这里插入图片描述

此时得到了不一样的结果：2 号信号发出后，对于 flag 变量的修改似乎失效了

将优化级别设为更高是一样的结果，如果设为 O0 则会符合预期般的运行，说明我们当前的编译器默认的优化级别是 O0

查看编译器的版本

代码语言：javascript

AI代码解释

gcc --version

在这里插入图片描述

那么我们这段代码哪个地方被优化了呢？

答案是while循环判断首先要明白：

对于程序中的数据，需要先被load到CPU中的寄存器中
判断语句所需要的数据（比如 flag），在进行判断时，是从寄存器中拿取并判断
根据判断的结果，判断代码的下一步该如何执行（通过 PC 指针指向具体的代码执行语句）
所以程序在优化级别为O0或更低时，是这样执行的：

在这里插入图片描述

7、SIGCHLD 信号

在进程控制学习时期，我们明白了一个事实：父进程必须等待子进程退出并回收，并为其 “收尸”，避免变成 “僵尸进程” 占用系统资源、造成内存泄漏

那么父进程是如何知道子进程退出了呢？

在之前的场景中，父进程要么就是设置为阻塞式专心等待，要么就是设置为WNOHANG 非阻塞式等待，这两种方法都需要父进程主动去检测子进程的状态

如今学习了进程信号相关知识后，可以思考一下：子进程真的是安安静静的退出的吗？

答案当然不是，子进程在退出后，会给父进程发送SIGCHLD信号
可以通过SIGCHLD信号通知父进程，子进程要退出了，这样可以解放父进程，不必再去主动检测，而是子进程要退出的时候才通知其来 “收尸”

在这里插入图片描述

SIGCHLD信号比较特殊，默认动作SIG_DEF是什么都不做

首先通过程序证明一下子进程会发出SIGCHLD信号

代码语言：javascript

AI代码解释

#include <stdio.h> #include <stdlib.h> #include <signal.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> void handler(int signo) { printf("进程 %d 捕捉到了 %d 号信号\n", getpid(), signo); } int main() { signal(SIGCHLD, handler); pid_t id = fork(); if(id == 0) { int n = 5; while(n) printf("子进程剩余生存时间: %d秒 [pid: %d ppid: %d]\n", n--, getpid(), getppid()); // 子进程退出 exit(-1); } waitpid(id, NULL, 0); return 0; }

通过自定义捕捉，打印相关信息

在这里插入图片描述

因此可以证明SIGCHLD是被子进程真实发出的，当然，我们可以自定义捕捉动作为回收子进程，让父进程不再主动检测子进程的状态，可以自己忙自己的事

代码语言：javascript

AI代码解释

#include <stdio.h> #include <stdlib.h> #include <signal.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> pid_t id; // 将子进程的id设为全局变量，方便对比 void handler(int signo) { printf("进程 %d 捕捉到了 %d 号信号\n", getpid(), signo); // 这里的 -1 表示父进程等待时，只要是已经退出了的子进程，都可以进行回收 pid_t ret = waitpid(-1, NULL, 0); if(ret > 0) printf("父进程: %d 已经成功回收了 %d 号进程，之前的子进程是 %d\n", getpid(), ret, id); } int main() { signal(SIGCHLD, handler); id = fork(); if(id == 0) { int n = 5; while(n) { printf("子进程剩余生存时间: %d秒 [pid: %d ppid: %d]\n", n--, getpid(), getppid()); sleep(1); } // 子进程退出 exit(-1); } // 父进程很忙的话，可以去做自己的事 while(1) { // TODO printf("父进程正在忙...\n"); sleep(1); } return 0; }

父进程和子进程各忙各的，子进程退出后会发信号通知父进程，并且能做到正确回收

在这里插入图片描述

那么这种方法就一定对吗？

答案是不一定，在只有一个子进程的场景中，这个代码没问题，但如果是涉及多个子进程回收时，这个代码就有问题了
根本原因：SIGCHLD也是一个信号啊，它可能也会在block表和pending表中被置为 1，当多个子进程同时向父进程发出信号时，父进程只能先回收最快发出信号的子进程，并将随后发出信号的子进程 SIGCHLD 信号保存在 blcok 表中，除此之外，其他的子进程信号就丢失了，父进程处理完这两个信号后，就认为没有信号需要处理了，这就造成了内存泄漏
解决方案：自定义捕捉函数中，采取while循环式回收，有很多进程都需要回收没问题，排好队一个个来就好了，这样就可以确保多个子进程同时发出SIGCHLD信号时，可以做到一一回收
细节：多个子进程运行时，可能有的退了，有的没退，这会导致退了的子进程发出信号后，触发自定义捕捉函数中的循环等待机制，回收完已经退出了的子进程后，会阻塞式的等待还没有退出的子进程，如果子进程一直不退，就会一直被阻塞，所以我们需要把进程回收设为WNOHANG非阻塞式等待

正确的代码长这样：

代码语言：javascript

AI代码解释

#include <stdio.h> #include <stdlib.h> #include <signal.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> void handler(int signo) { printf("进程 %d 捕捉到了 %d 号信号\n", getpid(), signo); // 这里的 -1 表示父进程等待时，只要是已经退出了的子进程，都可以进行回收 while (1) { pid_t ret = waitpid(-1, NULL, WNOHANG); if (ret > 0) printf("父进程: %d 已经成功回收了 %d 号进程\n", getpid(), ret); else break; } printf("子进程回收成功\n"); } int main() { signal(SIGCHLD, handler); // 创建10个子进程 int n = 10; while (n--) { pid_t id = fork(); if (id == 0) { int n = 5; while (n) { printf("子进程剩余生存时间: %d秒 [pid: %d ppid: %d]\n", n--, getpid(), getppid()); sleep(1); } // 子进程退出 exit(-1); } } // 父进程很忙的话，可以去做自己的事 while (1) { // TODO printf("父进程正在忙...\n"); sleep(1); } return 0; }

在这里插入图片描述

其实还有一种更加优雅的子进程回收方案

由于UNIX历史原因，要想子进程不变成僵尸进程，可以把SIGCHLD的处理动作设为SIG_IGN忽略，这里的忽略是个特例，只是父进程不对其进行处理，但只要设置之后，子进程在退出时，由操作系统对其负责，自动清理资源并进行回收，不会产生僵尸进程

也就是说，直接在父进程中使用 signal(SIGCHLD, SIG_IGN) 就可以优雅的解决子进程回收问题，父进程既不用等待，也不需要对信号做出处理

原理：在设置SIGCHLD信号的处理动作为忽略后，父进程的PCB中有关僵尸进程处理的标记位会被修改，子进程继承父进程的特性，子进程在退出时，操作系统检测到此标记位发生了改变，会直接把该子进程进行释放

SIGCHLD的默认处理动作是忽略（什么都不做），而忽略动作是让操作系统帮忙回收，父进程不必关心

注意：这种情况很特殊，只能保证在Linux系统中有效，其他类UNIX系统中可能没啥用