深入理解Linux信号：进程间异步通信的捕获、阻塞与实战指南

1. 从一次诡异崩溃说起：信号是哪种“进程间通信”

先讲一个我真实排查过的场景。某天凌晨，线上的一台业务机突然出现服务抖动，日志里没有报错，进程也没有core dump文件生成，但连接数一下子掉到零。运维同事第一反应是进程被OOM Killer杀了，查了一圈系统日志，发现内存占用并不高。最后我们用strace -p挂上去，才看到进程其实是收到了SIGTERM信号，然后走完了默认动作——直接终止。为什么会有SIGTERM？顺着时间线往前翻，发现是同机上一个定时任务脚本误调用了pkill -f，把匹配到的进程全部杀了。

这个案例就是典型的“进程间通信”——一个进程（脚本里的pkill）向另一个进程（业务进程）发送了一个信号。信号在这里扮演的并不是传递数据的角色，而是一个“通知”：你该退出了。很多初学者把IPC简单理解为“传数据”，管道传字节流、共享内存传结构体、消息队列传封装好的消息，这都没错。但信号这种东西，它传的不是数据，而是“事件”。它有自己独特的使用场景和脾气，和管道、共享内存完全不是一回事。

聊信号之前，得先把它在整个IPC家族里的位置放对。Linux下的进程间通信方式大致可以分成几类：管道/命名管道（FIFO）、System V消息队列、共享内存、套接字、信号量，以及信号（Signal）。其中绝大部分IPC都是“同步”的，你写我读、你发我收，双方在时间轴上是有确定顺序的。而信号是唯一一种“异步”的IPC：发送方发出信号之后根本不需要等接收方处理，接收方也不知道什么时候会来信号，它可能正在用户态执行一条普通的赋值语句，也可能正卡在某个系统调用里，然后内核突然把控制流切换到信号处理函数。这种“打断感”正是信号最核心的特征，也是后面所有坑的源头。

打个比方，管道像是你来我往的微信聊天，两个人按顺序对话；共享内存像一块公共留言板，大家看着同一块内容做事；而信号更像是“电话铃响”——不管你在干嘛，电话一响你就得停下手里的事去接。正因为这种强制打断的异步性，信号处理函数里的代码必须非常小心，否则很容易出问题。对任何玩Linux服务端的人，搞懂信号不只是一个知识点，它直接决定你的程序能不能优雅退出、能不能正确处理子进程、能不能在异常时保住现场。

2. 信号的全家福：编号、默认动作与可移植性

2.1 先给常见信号排个队

Linux上信号用正整数编号区分，每个编号对应一个宏名。这些宏名是标准化的，但具体编号在不同架构上有细微差别，比如SIGBUS在x86上是7，在有些架构上又是不同的值。日常写代码千万别直接写数字，老老实实用宏名。

我从实际使用频率排个序，下面这几个你早晚会碰见：

这里有个容易踩认知偏差的点：SIGKILL和SIGTERM大家天天都在用，但在“优雅退出”这件事上，你只应该依赖SIGTERM。SIGTERM可以被进程捕获，进程收到之后可以做清理工作、保存状态、通知上下游，然后自愿退出。SIGKILL则是直接由内核强制干掉，没有机会执行任何用户态代码，也不会有core dump。很多服务治理体系里，先发SIGTERM给进程，等超时了再补SIGKILL，这个先后顺序很重要。

再提两个“看起来是异常，其实很常见”的信号。一个是SIGPIPE，如果你用socket或管道做通信，对端已经关闭连接，你还往上写数据，内核不是让你write返回错误，而是直接给你进程发SIGPIPE，默认动作就是终止。所以很多网络服务项目里要显式忽略SIGPIPE，再靠write的EPIPE错误码做业务处理。另一个是SIGCHLD，子进程退出时内核会给父进程发这个信号，如果父进程不处理也不wait，子进程就会变成僵尸进程躺在进程表里，日积月累能让你系统进程数爆掉。

2.2 可靠信号与实时信号的分水岭

Linux信号还有一个重要维度：可靠与不可靠。这里的历史背景是早期Unix里信号处理存在丢失问题。什么叫丢失？如果进程还没来得及处理一个信号，又来了两个同类型的信号，内核可能只记录“有这个信号来了”这个事实，不会帮你去重计数，等处理完第一个，第二个就没了。换句话说，信号不是排队机制，它是一个位图。位图里某一位被置1，代表“有一个某编号的信号来了”，你处理完清零，如果期间又来了三次，位图依然只有一位，你还是只知道“来过”，不知道“来了几次”。

为了解决这个问题，POSIX标准引入了实时信号，编号从SIGRTMIN（一般是34）到SIGRTMAX（一般是64）。实时信号是有队列的，能保证发送几次就接收几次，并且带一个伴随的整数值，可以传递一个小数据。但实时信号是稀缺资源，业务代码里不要轻易占用，很多运行时和中间件会用它做内部机制，比如某些线程库用来做线程取消和同步。

我见过不少新手搞混“信号丢失”和“信号阻塞”。丢失是因为内核不排队，而阻塞是进程主动告诉内核“现在不想处理某类信号”，先放在未决集合里。阻塞不等于忽略，等解除阻塞之后，信号还会补处理一次——但同样地，如果阻塞期间同类型信号来了五次，解除之后只处理一次。这个位图模型请刻在脑子里，它会帮你避免后面的很多误解。

还有一点必须提：处理完信号之后，处理函数的返回值是void，它没有返回值可以告诉系统“我处理好了”。这是很多人的认知盲区，但也说明信号处理本身就是“打断+返回”的模型，你不可能在里面做复杂事务，这也是为什么信号处理函数要写得极短，只做标记、只做记录、只做唤醒。

3. 捕获与处理：signal() 和 sigaction() 的选型对比

3.1 为什么我不推荐 signal()

接到信号之后，进程有三种选择：默认动作、忽略、自定义处理。自定义处理就是用signal()或sigaction()为某个信号注册一个处理函数。

先说signal()，它接口很简单：

void (*signal(int signum, void (*handler)(int)))(int);

调用一次，第二个参数传函数指针。看起来简单，但它在不同Unix衍生系统上的语义差别非常大。在早期System V里，信号处理完之后会把该信号恢复成默认动作，意味着你得在handler里重新再设一遍signal，否则第二次同信号来了就直接走默认动作。在BSD里又不同，处理完会保留。Linux的signal()实现是兼容BSD的，所以一般不会遇到恢复默认的坑，但它依然有两个硬伤。

第一个硬伤：signal()在建立handler的时候，默认不设置SA_RESTART标志，这意味着很多慢速系统调用（比如read、write、wait、accept）可能会被中断，返回EINTR错误。你写网络程序时如果还用signal()，很可能碰到“明明什么都没做错，read怎么返回-1了”的诡异问题，查errno才知道是EINTR。这个问题在sigaction()里可以通过SA_RESTART优雅解决，后面细说。

第二个硬伤：signal()不能精确控制信号处理过程中的阻塞条件。你用sigaction()可以在处理一个信号时临时屏蔽其他信号，防止嵌套打断，而signal()是做不到的。

所以我的建议很简单：所有新代码一律用sigaction()。signal()可以留在写小程序、写测试Demo时用，但生产代码里最好别出现。这不是歧视这个接口，而是减少不确定性的问题。

3.2 sigaction() 结构体里的关键字段

sigaction()的原型：

int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);

oldact可以传NULL，但如果你想知道之前是谁在处理这个信号，就可以传一个结构体指针，内核会把旧的处理配置填进去。这在写库函数时特别有用——保存旧handler，用完再恢复，不破坏调用方原本的配置。

struct sigaction里几个字段：

struct sigaction { void (*sa_handler)(int); void (*sa_sigaction)(int, siginfo_t *, void *); sigset_t sa_mask; int sa_flags; void (*sa_restorer)(void); };

sa_handler和sa_sigaction其实是一个联合体（在具体实现里），你用了SA_SIGINFO标志，就表示使用带三个参数的函数，否则使用单参数版本。三参数版本能拿到siginfo_t，里面有发送者PID、uid、信号伴随值等额外信息，很多监控类程序靠这个区分信号来源。

sa_mask是处理这个信号期间要额外阻塞的信号集合。注意，正在被处理的信号本身通常会被自动阻塞，不用你重复加。sa_flags则是行为控制位，常用的有：

• SA_RESTART：让慢速系统调用在信号处理完后自动重启，而不是返回EINTR错误。
• SA_SIGINFO：使用siginfo_t三参数版本。
• SA_NOCLDWAIT：只对SIGCHLD有意义，加上后子进程退出自动回收，不产生僵尸，但你也无法用wait拿到子进程退出状态了，需要权衡。

3.3 一个完整可编译的信号捕获示例

写一个具有实用性的示例：一个服务进程，收到SIGTERM时做优雅退出，收到SIGUSR1时打印当前计数。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <signal.h> #include <unistd.h> static volatile sig_atomic_t g_running = 1; static volatile sig_atomic_t g_print = 0; static void handle_term(int sig) { // 只做标记，不调用复杂函数 g_running = 0; } static void handle_user(int sig) { g_print = 1; } static void setup_signal(int signum, void (*handler)(int), int flags) { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = handler; sigemptyset(&sa.sa_mask); sa.sa_flags = flags; if (sigaction(signum, &sa, NULL) == -1) { perror("sigaction"); exit(1); } } int main(void) { setup_signal(SIGTERM, handle_term, SA_RESTART); setup_signal(SIGUSR1, handle_user, SA_RESTART); long counter = 0; while (g_running) { counter++; if (g_print) { g_print = 0; // 主循环里做实际工作 printf("counter == %ld\n", counter); fflush(stdout); } // 模拟业务忙碌 usleep(1000); } printf("graceful exit, counter == %ld\n", counter); return 0; }

这里我用了volatile sig_atomic_t类型的标志变量。为什么不用普通int？因为handler在主循环执行的任意时刻可能被插入，处理器缓存、编译器优化都可能导致主循环读到旧值。sig_atomic_t保证了对这个变量的读写是原子操作，加上volatile保证编译器不从寄存器里直接取旧副本，每次都从内存读。这是信号处理函数与主循环通信唯一安全又简单的方式。

如果业务要求复杂一些，比如信号处理函数里要通知别的线程，那就需要用self-pipe技巧或者事件循环的唤醒机制，这已经是进阶玩法了。

4. 发送、阻塞与未决：信号的生命周期管理

4.1 发送手段五花八门，但目标未必一样

信号不是只能从命令行用kill发。用户态程序里常见的发送方式有这么几种：

• kill(pid, sig)：向指定PID的进程发送信号，需要目标进程与自己同用户，或自己有权限。
• raise(sig)：向自己当前线程发送信号。注意，它发送的对象是调用线程，不是整个进程。
• alarm(seconds)：设置一个秒级的定时器，倒计时结束后内核给进程发送SIGALRM。它一次只能设置一个，后面设置的会覆盖前面的。
• timer_create()/timer_settime()：POSIX定时器，能到纳秒级，还能选择发给进程还是某个线程，信号可以带siginfo，比alarm强太多。
• killpg()/pkill：向整个进程组发送信号，这经常是误杀事故的元凶。

假设你要向某个线程发信号，pthread_kill(thread, sig)是线程级发送，但信号能不能准确路由到目标线程，还要看整个进程的线程信号屏蔽字配置，这块到第5部分专门说。

实际开发里，信号发送经常被当成“控制命令”。我维护过的一个守护进程，就是用SIGUSR1触发配置重载。它比某种基于网络的命令通道更简单，但也更粗糙——因为它不可靠、不排队，你不能用它传大数据。如果你发现自己需要靠信号传递结构化信息，再传个JSON，建议停下来想想是不是该换消息队列或者Unix域套接字。

4.2 阻塞与忽略，很多人都理解反了

这是面试里最经典的高频易错点，也是实际排障中最容易看走眼的地方。

“忽略”是处理方式的一种，代表信号过来之后什么都不做；而“阻塞”是信号还没到进程手里，内核先把它的对应位置在未决信号集里置位，等解除阻塞后再处理。忽略一个信号，内核收到同类信号直接丢掉；阻塞一个信号，信号只是暂时押着，不丢。

用sigprocmask()设置进程级的阻塞集合：

sigset_t set; sigemptyset(&set); sigaddset(&set, SIGUSR1); sigprocmask(SIG_BLOCK, &set, NULL);

把SIGUSR1加进阻塞集合后，即使你向进程发一百次SIGUSR1，进程也感知不到。等到你调用sigprocmask(SIG_UNBLOCK, &set, NULL)解除，内核才把未决的最后一个SIGUSR1递送给进程。一百次还是只处理一次。

这个特性在工程上有个很有意思的用法：临界区保护。如果你的关键代码段不能被打断，那就先把可能打断它的信号都block掉，尤其是SIGTERM、SIGINT这种，等出了临界区再解除。我见过某些数据库中间件就是这么做的，把“是否允许被Ctrl+C中断”当成一个业务状态来管理。但注意，SIGKILL和SIGSTOP这两个信号无论如何都block不了，内核根本不给机会，这是系统的最后底牌。

另一个容易被忽略的关联是：当你用sigaction()给某个信号注册handler时，如果设置sa_mask包含另一个信号，那么在handler执行期间，那个信号也会被临时阻塞。但等你handler返回，一切恢复原样。这是在信号处理级而非进程级做局部屏蔽。

4.3 sigsuspend() 的原子性，普通写法模拟不来

假设主程序要等到某个信号来了再继续往下走，很多人第一反应是写个while循环：

while (flag == 0) { pause(); }

但这样有个窗口：如果信号在while判断完flag之后、进入pause()之前到达，那么这个信号会被“吞掉”，进程将永远睡下去。有没有解决？有，用sigsuspend()。它的逻辑是：原子地替换当前进程的阻塞信号集，然后挂起，直到收到一个信号且该信号被允许递送时，返回之前恢复原来的阻塞集。

用法上有个经典套路：“解除某个信号的阻塞，同时等待它到达”。先把目标信号阻塞起来，如果信号早就来了，那它必然在未决集里，不会丢失；然后sigsuspend(&set)里set不包含这个目标信号，意思是一边放开目标信号，一边挂起等待，一旦到达，sigsuspend返回，整个流程不存在竞态窗口。

sigset_t oldset, waitmask; sigemptyset(&waitmask); sigaddset(&waitmask, SIGUSR1); sigprocmask(SIG_BLOCK, &waitmask, &oldset); // ... 做一些需要保护的事情 ... sigsuspend(&oldset); // 原子地解除SIGUSR1的阻塞并等待

很多服务器程序里的“主线程等待退出信号”就适合用这个模式，而不是傻傻地sleep(1)轮询标志位。

5. 真实项目里吃过的亏：信号处理六大陷阱

5.1 在信号处理函数里调用printf？你可真敢

新手最常犯的错：在handler里写printf或者malloc，甚至调用sprintf。要知道，信号处理函数的执行是异步的，它可能在主程序执行到任意位置时被插入。如果主程序正执行到malloc内部，恰好持有堆内存分配的锁，此时信号来了，handler里的malloc再次进入同一套锁逻辑，直接死锁。

POSIX标准给出了一个清单：异步信号安全函数（async-signal-safe functions），在这个清单外的函数都不能在信号处理函数里随便调。清单里包括read、write、open、close、wait、_exit、sigaction等，但很不幸，printf、malloc、free、pthread_*这些常见函数都不在里面。

那怎么在handler里做日志？最实用的办法是write到预先打开的文件描述符，或者在handler里只设置标志位，由主循环统一做实际处理。如果你想输出一个数字，用write配合手写整数转字符串，不要用printf。

再补充一个细节：handler里需要记录错误号时，建议先保存errno，处理完再恢复。因为信号可能打断主程序的任意系统调用，而handler里一旦调用了可能修改errno的函数，主程序拿到的错误码就乱了。

5.2 EINTR问题：你的read为什么总是被中断

当进程处于阻塞的系统调用中（比如read一个管道，管道里暂时没有数据），一个信号到达并处理完，默认情况下这个系统调用会被中断并返回-1，errno置为EINTR。很多初写网络程序的人看到read返回-1第一反应是网络断了，实际上只是“被信号打扰了”。

解决的思路不只一种：

• 在sigaction的flag里加SA_RESTART，让内核自动帮你重启大多数被中断的系统调用。
• 不依赖SA_RESTART，循环里判断errno == EINTR就重试。

我自己的经验是：如果程序里信号处理逻辑很清晰，SA_RESTART基本能解决90%的问题。但注意，SA_RESTART对某些系统调用并不生效，比如select、poll、epoll_wait、nanosleep、wait等，还是会返回EINTR。所以网络服务里主循环还是要对EINTR做兼容。我见过一个高可用程序，epoll里不处理EINTR，每次被信号打断就直接break出循环，结果服务周期性退出，排了一天查出来就这么个点。

5.3 SIGCHLD与僵尸进程的爱恨情仇

父进程没耐心等子进程，但内核在子进程退出后不会立刻删除进程表项，而是保留到父进程调用wait/waitpid来回收状态。如果父进程从未wait过，子进程就变成僵尸。

正确处理SIGCHLD的标准姿势是：在handler里只调用waitpid(-1, &status, WNOHANG)，循环回收所有已退出的子进程。为什么用WNOHANG？因为handler是异步的，你不知道此刻有多少个子进程退出，用非阻塞方式全部收割一遍，绝不能在里面死等，那是阻塞式wait，会把信号处理函数永远挂住，别的信号再来就全堵死了。

用waitpid(-1, ...)循环的时候还有个坑：如果同一时刻有多个子进程退出，handler里一次waitpid只回收一个，必须循环到返回0或-1为止，不然僵尸收割不干净。把这个逻辑放到SIGCHLD handler里，是Linux服务端程序的标准操作。

5.4 多线程进程里的信号路由，比想象中拧巴

多线程情况下，信号怎么路由是一个容易让人抓狂的问题。基本规则是：进程级别发送的信号（kill、raise对进程的默认行为）可以被进程内任意一个未阻塞该信号的线程处理，而不是一定发给主线程。如果你在主线程里设置了SIGTERM handler，但另一个工作线程没有阻塞SIGTERM，内核完全可能把SIGTERM投递给那个工作线程，从而触发你想象不到的后果。

一个常见的工程做法是：所有线程都继承进程的初始信号屏蔽字，然后在主线程里对感兴趣的信号设置handler，同时让其他线程把信号都block掉。怎么做到？在创建线程之前用pthread_sigmask()设置阻塞集合，新线程会继承这个屏蔽字。主线程单独撤销对目标信号的阻塞，这样信号只会被投递到主线程。

sigset_t set; sigemptyset(&set); sigaddset(&set, SIGTERM); sigaddset(&set, SIGINT); pthread_sigmask(SIG_BLOCK, &set, NULL); // 在创建线程之前调用 // 创建其他工作线程... // 主线程自己解除阻塞 pthread_sigmask(SIG_UNBLOCK, &set, NULL);

另一个方向是用sigwait()而不是handler：把所有信号都block住，然后专门开一个线程循环sigwait()处理。这种方法避开了“在异步handler里做复杂操作”的所有限制，代码逻辑可以普通同步写，很多消息中间件和数据库服务都这么干，因为信号处理从“异步打断”变成了“同步消费”，心智负担一下小很多。只设handler传标志位是一个可行的入门方案，但如果你真在维护一个高并发服务，我会建议考虑sigwait线程。

这里顺带提一下实时信号：使用SIGRTMIN以上的实时信号时，handler带siginfo_t可以用si_value传递一个指针或整数，很多人把它当成轻量级事件队列用。但因为系统能排队的实时信号数量有限制，过量发送照样会丢，不能指望它来做大流量通信。

5.5 core dump 不是免费午餐

看到SIGSEGV就以为一定有core文件，这是误会。core dump是否产生，取决于进程的rlimit，ulimit -c如果为0，SIGSEGV只会默默终止进程。排查崩溃问题时，很多人第一句话就是“没有core，怎么办”，其实第一步应该检查ulimit -c unlimited，再看/proc/sys/kernel/core_pattern指向哪里。我见过某公司统一把core_pattern指向一个带PID和时间的路径，配合自动收集系统，排查效率提升很多。

但还有一点可能比core设计更重要：进程收到SIGSEGV时，真正有价值的是现场，而不是处理函数。你可以在handler里用sigaction注册SIGSEGV/SIGABRT的handler，利用siginfo_t的si_addr拿到出错地址，再调用backtrace()打印调用栈，然后_exit()。这种做法的本质是把崩溃变成可控的“临终日志”。注意，这个handler里你只能调用async-signal-safe函数——backtrace函数族是否安全在不同平台上有争议，团队里要测试后再落地。

5.6 信号与IO多路复用的协作：别用SIGALRM做精确计时

我在某项目里看到过一个比较惨痛的教训：用alarm(1)做周期性任务触发，但因为系统负载高、调度不确定，SIGALRM经常丢失（非实时信号不排队），导致周期任务不定期“漏跑”。后来改成timer_create加SIGEV_THREAD（信号通过线程回调函数投递），才算稳定。原因很简单：SIGALRM是标准非实时信号，背着位图模型不可靠的包袱，根本不适合对可靠性敏感的定时任务。

更合理的方式：如果主循环已经基于epoll/select，推荐使用timerfd_create创建定时器文件描述符，把它加入epoll事件集，定时器到期就以可读事件的形式出现在IO多路复用里，完全绕开信号机制。这简直是服务端程序处理定时任务的最优解：没有信号中断、没有EINTR、没有异步handler限制，只当普通fd来读就行。

所以我的个人倾向是：能用IO事件解决的尽量不用信号；能用同步sigwait处理的尽量不用异步handler；实在要用异步handler，handler里绝对只做标志位标记。

6. 最后再分享一点实战心得：信号是个好东西，但要用得克制

我自己用过一段时间信号做进程间控制，积累了这么个习惯：把所有信号处理逻辑收拢到一个独立的模块里，不散落在业务各处。这个模块统一负责注册handler、统一管理信号屏蔽字、统一提供“设置退出标志”“请求重载配置”等语义接口。业务代码只调接口，不直接接触signal。

还有一个小技巧值得分享：在测试信号处理流程时，不要只发一次信号，要连续快速发多个同类信号，观察有没有丢失、有没有行为不一致。很多时序问题，单次信号根本暴露不出来，只有压着发才能看出handler是否可重入、标志位是否被正确处理。调试时可以用sigqueue给信号附带不同整数值，然后通过siginfo_t.si_value区分不同指令，这比单纯用USR1/USR2两个信号能表达的语义丰富太多。

如果你维护的是长期运行的守护进程，我还建议你做一个“信号处理自检”：启动时打印一份当前注册了哪些信号、哪些信号被阻塞、哪些走默认动作的报告。这个报告平时不起眼，真正排障的时候能省下大量猜测时间。我现在每接手一个陌生服务，第一件事就是看/proc/<pid>/status里的SigCgt和SigBlk字段，这两行能直接告诉我这个进程对哪些信号做了拦截、哪些被屏蔽了，很多时候问题答案就藏在里面。

信号就是这样一种存在：它足够底层、足够强大，但也足够粗糙。你可以在一个几十行的C程序里用它实现进程控制，也可以在几千线程的大系统里靠它优雅退出。关键是理解它的异步本质和位图式语义，然后规规矩矩地按它的脾气来写代码。上面的坑我基本都踩过一遍，写出来供各位参考，希望你们的进程都能收到愿意处理的信号。