写这篇文章之前，我想先聊聊我自己的体会。早期做Linux开发时，有段时间我特别怕处理信号相关的问题，尤其是那种“明明kill了进程，却没有任何反应”的情况。后来把信号的pending（未决/保存）机制彻底弄明白之后，很多诡异的现象突然就说得通了。信号保存这个概念，说难并不难，本质就是内核里一张位图，但这张位图牵扯出的行为，却影响着后台服务、嵌入式程序，甚至每一次你按下的Ctrl+C。
这篇文章我会用最直白的方式，从信号保存的原理讲起，配合可直接运行的代码和调试技巧，把“信号保存+简单使用”这件事讲透。无论你是刚接触Linux编程的学生，还是准备面试的开发者，又或是被奇怪信号问题折磨的运维和嵌入式工程师，看完应该都会有收获。
1. 为什么要把“信号保存”单独拿出来讲
在Linux下排查问题时，你有没有遇到过这种场景：一个进程明明收到了kill命令，进程却毫无反应，日志里也什么都没留下，仿佛信号被“吞”掉了。反过来，有时候只是发了一次信号，程序却崩溃了，完全超出预期。这些现象背后，大都指向同一个概念：信号从产生到真正被进程处理之间，存在一个“保存”的中间阶段，专业术语叫pending，也就是未决状态。
信号机制是Linux/Unix体系中最基础也最容易让人困惑的进程间通信方式。绝大多数人对信号的理解止步于“Ctrl+C能终止程序”“kill -9能强杀进程”，但这只是信号默认行为的最浅层。真正决定一个信号行为走向的，是内核如何记录它、保存它、以及何时把它递送给进程。当信号因为某些原因没能立刻被处理（最常见的原因是被阻塞），它就会被内核暂存起来，等待合适的时机再递送。这个暂存的动作，就是标题里说的“信号保存”。
为什么要单独关注这个点？因为在实际开发里，大量bug都出在这个层面。比如你在程序启动时用sigprocmask屏蔽了SIGINT，结果一段时间后需要恢复，却发现Ctrl+C不生效了；又比如你在信号处理函数里执行了非异步安全的操作，导致程序卡死。这些问题如果不理解信号保存的原理，排查起来只能靠猜。理解了原理之后，所有现象都能用一句话解释：信号没被处理，是因为它被保存在了pending集合里，还没有进入递送环节。
这篇文章主要围绕三个系统调用展开：sigprocmask（修改阻塞集合）、sigpending（查看未决集合）、sigaction（注册信号处理函数）。这三者组合起来，就是一套对信号生命周期进行“控制-查看-消费”的完整工具箱。配套的代码我都实际编译运行过，不依赖任何第三方库，你可以直接复制到自己的Linux环境里验证。
2. 信号从哪来、到哪去：一张位图说清保存原理
想弄明白信号保存，先要建立一个小模型。每个进程内部都维护着两张核心位图：blocked集合和pending集合。blocked集合表示哪些信号被当前进程屏蔽（阻塞），pending集合表示哪些信号已经产生、但尚未被处理。在Linux的通用平台上，信号编号从1到64，其中1到31是标准信号，SIGRTMIN到SIGRTMAX之间是实时信号。每个信号在这两张位图里只占一个bit，这个设计直接决定了标准信号的一个经典特性：不排队。
信号的生命周期可以拆成三步：产生、挂起、递送。产生信号的方式很多：键盘输入Ctrl+C产生SIGINT，调用kill或者killpg向目标进程发送信号，进程自己调用raise向自身发信号，硬件异常会带来SIGILL、SIGSEGV，内核还会为特定事件生成信号，比如SIGCHLD（子进程退出）、SIGALRM（定时器到期）。信号产生后，内核不会立刻安排进程执行对应的处理逻辑，而是先检查目标信号在blocked集合里是否被屏蔽。如果没被屏蔽，信号直接进入递送阶段；如果被屏蔽了，内核就把对应的bit在pending集合里置位，表示“这个信号已经被保存，等待以后处理”。等到进程取消阻塞，内核发现pending里有这个信号，才会真正递送，触发你注册的处理函数，或者执行默认动作。
这里有一个必须区分的细节：pending也分两类。一类是进程级pending，一类是线程级pending。在很多现代Linux系统使用NPTL线程库的情况下，每个线程都有自己独立的blocked和pending集合。没有进行特殊设置时，信号默认由主线程接收和处理。面试里经常追问的点就在这：如果一个信号同时被进程和线程阻塞，线程级的pending优先级更高，会先于进程级pending被处理。新手不需要把全部细节背下来，但要记住一个核心结论：决定信号能不能递送，看的是当前线程的blocked集合；记录有没有迟到的信号，看的是pending集合。
用生活里的事来类比更容易理解。想象你正在开会，手机上收到一条紧急消息，如果开了免打扰，这条消息不会立刻响铃，而是出现在通知栏里，这相当于信号被保存到了pending；免打扰就是阻塞集合；等会议结束你关掉免打扰，看到通知，再决定要不要回复，这个动作就是信号递送。而且通知栏里相同来源的推送只占一条位置，一下来十条也一样显示一条，处理和一次显示同等效果。这就是标准信号不排队的直观解释。
还有两个信号非常特殊：SIGKILL和SIGSTOP。它们不能被阻塞、不能被捕获，也不允许被忽略。内核把它们当作最后的手段，用于强制终止进程和暂停进程。无论你怎么构造blocked集合，sigprocmask都会悄悄忽略对这两个信号的设置。所以不要试图通过屏蔽信号来阻止kill -9，规划和面试时都要记住这个边界。
3. 信号保存三件套：sigprocmask、sigpending、sigaction
理论模型建立之后，就要落地到接口。围绕信号保存和简单使用，最核心的三个系统调用是：sigprocmask负责修改blocked集合，sigpending负责读取pending集合，sigaction负责注册或修改信号处理函数。把这三个接口配合起来，就能覆盖“屏蔽信号→查看信号是否被保存→取消屏蔽→信号递送处理”的完整链路。
3.1 sigprocmask：修改阻塞信号集
sigprocmask的原型是这样的：
int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);how有三个取值，这是最容易搞混的地方：
- SIG_BLOCK：把set集合中的信号加入当前阻塞集合，已有的阻塞项保留。适合“追加屏蔽”的场景。
- SIG_UNBLOCK：把set集合中的信号从阻塞集合里移除。适合“解除屏蔽”的场景。
- SIG_SETMASK：直接用set集合替换当前阻塞集合，不管之前阻塞了什么。
oldset参数用于保存修改前的阻塞集合，方便之后恢复现场。比如你先用SIG_SETMASK读取当前集合，完成修改，最后再用SIG_SETMASK把oldset还原回去，这是一种很常见的临时屏蔽信号手法。
需要额外提醒的是，Post和POSIX标准都明确了一点：在多线程程序里，sigprocmask的行为是未定义的。别看单线程下一切正常，一旦引入pthread，就一定要改用pthread_sigmask，这个函数参数和sigprocmask完全一致，只是针对线程的独立阻塞集合操作。我见过不少线上问题，就是单线程代码里用了sigprocmask，后面加了多线程改造，结果信号处理全部乱套。
3.2 信号集操作，先清空再添加
sigprocmask的set参数类型是sigset_t，使用前必须先初始化：用sigemptyset把集合清空，或者用sigfillset把集合全部置位，然后用sigaddset往集合里添加指定信号，用sigdelset从集合里移除指定信号，用sigismember查询某个信号是否在集合中。这是新手最容易踩的坑：声明一个sigset_t变量后不初始化就直接传给sigprocmask，里面是随机值，导致意外阻塞了一堆信号。记住一个顺序：先初始化和清空，再逐信号操作。
sigset_t set; sigemptyset(&set); sigaddset(&set, SIGINT); sigprocmask(SIG_BLOCK, &set, NULL);这三行就是“屏蔽SIGINT”的标准写法。
3.3 sigpending：查看未决信号
sigpending的原型也很简单：
int sigpending(sigset_t *set);内核把当前线程对应的pending集合拷贝到set参数里，程序随后可以用sigismember逐个检查哪些信号处于未决状态。这里要特别注意，sigpending只是“查看”，不会清除pending状态。如果想主动丢弃某个已保存的信号，需要另外的思路，比如把该信号的处理方式设置为SIG_IGN，然后让它在阻塞期间产生，等恢复阻塞时内核发现该信号被忽略，会直接放弃递送。这个技巧在处理一些周期性但无意义的信号时能派上大用场。
3.4 sigaction：注册可靠的处理函数
注册信号处理函数，建议直接用sigaction而不是signal。原因在于sigaction的行为是可预测的，而signal在不同glibc版本、不同编译选项下的语义并不统一。sigaction的原型是：
int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);struct sigaction里面值得关注的字段有三个。sa_handler是普通处理函数指针，赋值为SIG_IGN表示忽略信号，SIG_DFL表示恢复默认行为；sa_mask指定执行处理函数期间要额外屏蔽的信号集合；sa_flags支持SA_RESTART等重要标志，设置后，如果进程正在阻塞的系统调用（如read、accept）被信号打断，内核会自动重启该系统调用，而不是返回错误。如果面试官问signal和sigaction的区别，抓住两个核心点就行：sigaction可以明确控制处理期间的屏蔽信号集合，支持附加参数，行为稳定可控。
4. 实操：亲手把信号“封存”再“释放”
纸上谈兵做到这一步，该动手了。下面用一个完整的C程序演示信号保存的全过程。程序逻辑分四步：注册SIGINT的处理函数；用sigprocmask屏蔽SIGINT；循环多次向自己发送SIGINT，并用sigpending观察信号是否被保存；最后取消屏蔽，观察处理函数只在恢复后执行一次。
#include <stdio.h> #include <signal.h> #include <unistd.h> #include <stdlib.h> #include <string.h> static void handle_sigint(int sig) { char msg[] = "\n[handler] caught SIGINT\n"; write(STDOUT_FILENO, msg, sizeof(msg) - 1); } static void show_pending(void) { sigset_t pending; sigemptyset(&pending); sigpending(&pending); if (sigismember(&pending, SIGINT)) { printf("[info] SIGINT is pending (saved but not delivered)\n"); } else { printf("[info] no SIGINT pending\n"); } } int main(void) { struct sigaction sa; sigset_t block_set; memset(&sa, 0, sizeof(sa)); sa.sa_handler = handle_sigint; sigemptyset(&sa.sa_mask); sa.sa_flags = 0; if (sigaction(SIGINT, &sa, NULL) < 0) { perror("sigaction"); exit(1); } sigemptyset(&block_set); sigaddset(&block_set, SIGINT); if (sigprocmask(SIG_BLOCK, &block_set, NULL) < 0) { perror("sigprocmask"); exit(1); } printf("[demo] SIGINT blocked. Sending 3 SIGINT signals...\n"); for (int i = 0; i < 3; i++) { kill(getpid(), SIGINT); show_pending(); sleep(1); } printf("[demo] unblocking SIGINT now...\n"); if (sigprocmask(SIG_UNBLOCK, &block_set, NULL) < 0) { perror("sigprocmask unblock"); exit(1); } printf("[demo] after unblock, handler should have run.\n"); sleep(1); return 0; }编译和运行：
gcc -Wall -o signal_demo signal_demo.c ./signal_demo真实输出如下：
[demo] SIGINT blocked. Sending 3 SIGINT signals... [info] SIGINT is pending (saved but not delivered) [info] SIGINT is pending (saved but not delivered) [info] SIGINT is pending (saved but not delivered) [demo] unblocking SIGINT now... [handler] caught SIGINT [demo] after unblock, handler should have run.看到没有，连续发送3次SIGINT，每次sigpending都显示信号被保存，但处理函数没有执行。取消阻塞后，handle_sigint只运行了一次。这就是标准信号不排队的实证：同样的信号在pending阶段只保存一份，同时到达的多个实例会被合并。如果你把这套代码的SIGINT换成SIGRTMIN+1，并注册带siginfo_t参数的信号处理函数，就能看到相反的效果，每个实时信号都会被独立保存、独立处理，这也是大并发场景下信号偶尔也需要“上了保险丝”的原因。
4.1 实时信号与标准信号的本质差异
标准信号（1到31）的pending集合只是一张位图，每个信号一个bit，所以多次发送同一标准信号，pending集合里只有一次记录。实时信号（SIGRTMIN到SIGRTMAX）就不同了，Linux内核为它们维护了一个真正的队列，每次发送都会在pending队列里增加一个实例，排队递送。用代码验证只需要两步：把示例中的SIGINT改成SIGRTMIN+1，然后在struct sigaction里用sa_sigaction字段注册函数，并设置sa_flags |= SA_SIGINFO。处理函数原型变成：
void rt_handler(int sig, siginfo_t *info, void *context);这种差异意味着什么？如果你关心信号的“次数”，而不是仅关心“有没有信号”，就必须选择实时信号或者使用管道、消息队列等机制承载信息。很多程序只屏蔽SIGINT一次两次没感觉，但一旦遇到高频信号，标准信号丢事件的问题就会暴露，理解这个差异能帮你少走不少弯路。
4.2 信号处理函数里该做什么、不该做什么
示例里我特意用了write而不是printf来打印信息，这不是随手之举。在信号处理函数中调用printf、malloc、fopen这类非异步信号安全的函数，是生产环境中很常见也是很隐蔽的隐患。原因很简单：信号随时可能中断主流程，主流程如果刚好在执行printf内部已经拿到了相关锁，信号处理函数再次调用printf就会尝试拿同一把锁，造成死锁。信号处理函数可能中断malloc的内部状态，导致堆损坏。
正确的做法是，把信号处理函数当作一个“事件记录指针”，在里面用write系统调用写入少量字节，或者把处理逻辑所需的变量标记为volatile sig_atomic_t，仅仅置一个标志位，真正的业务逻辑放在主循环里检查标志后执行。这样虽然多了一次循环轮询的开销，但把不确定性严格限制在最小范围内，程序行为可预测得多。
还有一个常见误区是递归触发。如果处理函数执行期间又收到同一个信号，根据系统默认行为，该信号会被临时阻塞，直到处理函数返回。这本身是一次保护，但如果你在sa_mask里又添加了别的信号，处理期间这些信号都会被屏蔽。需要精确控制时，务必用sigaction的sa_mask字段显式声明，而不是随便用signal函数加个handler完事。
5. 常见问题与排查技巧实录
信号保存机制在实战中踩坑极多。这里把我的排查经验整理成一张速查表，方便你在项目里对照使用。
| 现象 | 可能原因 | 排查建议 |
|---|---|---|
| 阻塞后发多个相同信号，取消阻塞只处理一次 | 标准信号不排队，pending集合是位图 | 需要计数语义就用实时信号，或改用消息队列/管道 |
| sigpending始终为空，但程序确实收到了信号 | 信号根本没被阻塞，已经直接递送 | 检查sigprocmask的返回值，确认how参数和集合内容 |
| 程序不响应Ctrl+C | SIGINT被忽略或屏蔽 | 检查是否把SIGINT设置成了SIG_IGN；检查阻塞集合 |
| 屏蔽信号后进程仍然崩溃 | 导致崩溃的不是你以为的SIGSEGV，可能是SIGABRT | 用core dump或gdb catch定位具体信号 |
| 恢复阻塞后没有立即看到处理效果 | pending信号在处理函数执行期间被同信号再次屏蔽 | 检查sa_mask是否包含当前信号，必要时调整 |
5.1 不看代码也能查信号状态
运行中的进程，可以通过/proc文件系统直接查看信号相关的集合信息。进入/proc目录下的进程目录，在status文件里有三个关键字段：
- SigBlk：当前阻塞集合
- SigPnd：当前进程未决集合
- SigCgt：已捕获的信号集合
查询方式：
grep -E 'Sig(Blk|Pnd|Cgt)' /proc/1234/status输出是一串十六进制数，每一位对应一个信号编号，bit0对应信号1，依次类推。把十六进制转成二进制，就能精确知道某个信号当前处于什么状态。这条命令在生产环境极为好用，不改动代码、不打断服务，就能回答“我的信号到底存没保存”这类问题。
5.2 用gdb直观观察信号递送时机
如果觉得十六进制麻烦，还可以用gdb来验证信号的处理时机。在gdb里执行：
handle SIGINT print然后运行程序，从另一个终端向该进程发送SIGINT。gdb会在信号递送的那一瞬间中断程序，此时用bt查看调用栈：如果栈顶还在主循环，说明信号尚未递送；如果栈顶已经进入handle_sigint，说明正在处理。反复用SIG_BLOCK和SIG_UNBLOCK切换，你就能亲眼看到信号从保存到递送的完整轨迹。这个方法比口头解释直观得多，适合用来教学或者清晰定位问题。
5.3 给开发者的几条忠告
处理信号相关问题，多年实践下来，我总结出几条铁律。第一，信号处理函数里少做事，能write就write，能置标志就置标志，绝不碰堆操作和锁。第二，阻塞和忽略是两回事：阻塞意味着延迟处理，信号还保存着，随时可能递送；忽略意味着永不处理，信号来了直接丢弃，两者的调试方式完全不同。第三，多线程程序里不要直接用sigprocmask管理全局信号，要用pthread_sigmask配合sigwait做集中处理。第四，警惕SIGPIPE和SIGALRM的默认动作，SIGPIPE默认终止进程，很多网络服务没处理它导致写已关闭连接的socket时进程静默退出；SIGALRM默认也是终止进程，如果代码里无意间使用了alarm，进程就可能定时暴毙，日志里什么都查不到。这几条每一条都是生产环境里的真实教训。
6. 面试与日常使用中的心得
先解决一个很多人没想透的问题：信号保存和信号处理函数的注册之间是什么关系？信号保存是内核态的状态记录，只要信号产生且被阻塞，无论你有没有为它注册处理函数，它都会进入pending集合。信号处理是用户态的动作，发生在递送阶段。即使你从头到尾没调用sigaction，SIGINT也有默认行为，照样会先经历pending过程，只不过递送时执行的是默认动作（终止进程）。理解了先后关系，面试题“SIGINT被阻塞时按Ctrl+C进程会怎样”就不难回答了：进程不会退出，信号被保存；取消阻塞后，信号进入递送阶段，这时才触发默认动作或处理函数。
面试官如果问到“信号被保存的位置”，你需要能给出清晰的回答：在内核的进程控制块task_struct中，维护了pending链表和blocked信号集，用户态无法直接访问，只能通过sigpending和sigprocmask这类系统调用间接访问。如果追问线程场景，可以补充说每个线程也有自己的pending集合，NPTL实现中线程级pending的优先级更高。能把这些讲清楚，信号相关的问题基本能拿住大部分分数。
6.1 实际项目中的信号应用场景
信号保存机制绝不是面试题里的摆设。守护进程启动时，通常先屏蔽掉SIGINT、SIGTERM等信号，完成配置文件加载和资源预分配后，再解除屏蔽，避免中途被打断导致状态不一致。嵌入式Linux项目里，父进程可以把SIGCHLD延迟到统一时机处理，减少频繁上下文切换的开销。高并发网络服务里，普遍会屏蔽或忽略SIGPIPE，否则客户端断开连接后的一次写操作就足以让整个服务进程退出。
我自己就踩过SIGPIPE的坑。某次线上服务不定期消失，日志无异常，重启后能跑一阵，之后又消失。排查到最后，用/proc/status里的SigCgt字段对比发现，SIGPIPE没有被捕获。原来路由节点主动断开连接时，服务端写socket触发了SIGPIPE的默认终止动作。从那以后，我写服务端程序的第一件事就是列一张项目里可能出现的信号清单，逐个确认处理策略：忽略的、捕获的、保留默认的。这个习惯帮我避免了很多半夜被叫醒的烦恼。
关于信号，还有一个很值得继续探索的方向：signalfd。等你理解了本文讲的保存机制再去看signalfd，会突然豁然开朗，它本质上就是把内核的pending集合转换成了文件描述符上的可读事件，让你可以用读文件的方式消费信号，并且能无缝整合进epoll事件循环。能走到这一步，说明你对信号的理解已经不只是停留在调用API，而是真正看到了机制背后的设计思路。这也是我觉得Linux信号最迷人的部分：几千行代码的背后，是一个把异步处理抽象成“保存-递送-消费”的简洁模型，值得我们反复琢磨。
