聊到“异步通信”搞服务端的人第一反应往往是消息队列、事件循环、epoll、回调函数搞嵌入式的人第一反应可能是中断、定时器、信号量。但不管在哪条技术线里都藏着一个最底层、也最容易被忽略的异步通信机制——信号signal。它不是管道那种按字节流搬运数据的通道它更像一封“只有动作、没有正文”的加急通知子进程退出了、定时器到点了、用户敲了 CtrlC内核都会主动把这个通知塞给进程进程可以选择忽略、捕获或者按默认方式处理。如果你写过常驻后端服务、做过进程管理、搞过嵌入式程序或者单纯想弄明白操作系统到底怎么“通知”进程这篇内容值得看完。我会把信号从生成、屏蔽到处理的完整链路拆开再附上可以直接抄作业的代码和这些年踩过的坑。信号用好了是解耦利器用不好就是随机崩溃发生器问题差别往往只在几个细节上。1. 信号到底解决什么问题1.1 从“闹钟模型”理解异步通信想象你在写代码手机突然响了。你不用每隔几秒就拿起手机看有没有消息而是让手机在你耳边振铃你被打断、接电话、处理完再回到写代码的状态。这就是异步通知事件发生的时刻不确定但发生后接收方会被主动打断并得到通知。信号就是操作系统层面的“手机振铃”。进程注册好信号处理函数后内核在对应事件发生时比如硬件异常、定时器到期、另一个进程调用 kill、子进程退出都会主动把信号送过来。发起方不需要知道接收方现在在干什么接收方也不需要轮询等待这是信号作为异步通信方式的核心价值。1.2 为什么需要信号而不是轮询可能有人会问我写一个 while 循环每秒检查一次标志位不也能实现“通知”吗能但要付出代价。首先是 CPU 浪费。轮询意味着大量无意义的检查哪怕事件一小时才发生一次你也得每几毫秒醒来看一眼。其次是延迟不可控。如果你把检查间隔调到 10 毫秒那事件发生到你发现它最坏要等 10 毫秒。信号则不同内核在事件发生的那一瞬间就会设置标记并在合适的时机执行处理函数不需要接收方主动参与。举个例子父进程创建了 10 个子进程子进程什么时候退出完全由外部任务决定。如果父进程轮询waitpid(-1, status, WNOHANG)空转的时间无法估量而你只要注册SIGCHLD处理内核会在子进程状态变化时自动通知父进程。1.3 信号不是用来传数据的这是很多新手最容易误解的地方。信号传递的全部信息基本就是“信号编号”本身比如SIGINT、SIGTERM、SIGCHLD它不带业务数据。实时信号借助sigqueue可以携带一个整型值或指针但绝大多数场景下信号的定位是“通知某个事件发生了”而不是“把完整的事件内容送过去”。数据传输还是要靠管道、消息队列、共享内存。我经常把信号理解成“门铃”门铃告诉你“有人来了”但来的人是谁、来干什么你得开门后自己看。门铃本身不承担这部分信息。2. 信号从触发到处理的完整链路2.1 信号从哪里来信号的来源大致可以分四类硬件异常除零产生SIGFPE非法内存访问产生SIGSEGV非法指令产生SIGILL。终端按键用户按 CtrlC 产生SIGINTCtrlZ 产生SIGTSTPCtrl\ 产生SIGQUIT。软件通知alarm()到期产生SIGALRM子进程退出产生SIGCHLD管道写端已关闭时写数据产生SIGPIPE。显式发送任意用户态程序调用kill(pid, sig)、raise(sig)、sigqueue()。注意kill这个名字很有迷惑性它并不是“杀死进程”而是“发送信号”。kill -TERM 1234的意思是给 pid 为 1234 的进程发送SIGTERM至于收到后是退出还是忽略由接收方决定。kill -l可以列出当前系统支持的所有信号编号日常开发里很多“诡异问题”根源就是有人发了错误的信号。2.2 默认动作不是只有“杀死”大多数信号默认动作都是终止进程但并不是全部。我整理了一个常用信号默认动作表信号默认动作常见触发场景SIGINTTerm终端 CtrlCSIGQUITCore终端 Ctrl\SIGKILLTermkill -9不可捕获SIGSTOPStop停止进程不可捕获SIGTSTPStop终端 CtrlZSIGCHLDIgn子进程停止或退出SIGALRMTermalarm 定时器到期SIGPIPETerm向无读端的管道写数据SIGSEGVCore非法内存访问SIGTERMTermkill 默认信号优雅终止常用Term 表示终止进程Core 表示终止并生成 core dumpStop 表示暂停进程Ign 表示忽略。其中SIGKILL和SIGSTOP不能被捕获、不能被屏蔽这是内核最后的强制手段。剩下大部分信号都可以被进程重新定义行为。2.3 屏蔽、未决、递达三个容易绕晕的状态一个信号从产生到被处理会经历几个状态理解了它们很多“信号丢失”“信号不执行”的问题就能想通。生成信号被内核或用户态程序创建出来。未决pending信号已经生成但还没有被进程处理。递达delivered信号真正到达进程执行默认动作或处理函数。进程可以通过sigprocmask或pthread_sigmask维护一个信号屏蔽字。被屏蔽的信号会一直停留在未决状态直到解除屏蔽才会递达。这里有个重点对于标准信号如果在未决期间又连续来了多次同类信号内核只会记录一次也就是说标准信号不排队。比如进程屏蔽了SIGCHLD期间 10 个子进程全部退出解除屏蔽后进程也只会收到一个SIGCHLD。这正是很多回收子进程代码有 bug 的根源。2.4 进程什么时候真正处理信号时机比你想的晚信号并不是“产生后立即执行”。对于普通进程信号处理函数通常是在进程从内核态返回用户态的那个检查点上执行的。也就是说如果进程一直停留在用户态死循环并且不触发系统调用、不产生中断信号可能迟迟不会被处理。这也是为什么长期运行的交互式程序几乎都有系统调用或事件等待一旦收到信号内核就会在合适的时机切入用户态处理函数。另一个连带问题慢速系统调用比如阻塞在read、accept上被信号中断后可能返回-1并把errno设置为EINTR。后面我会专门讲怎么处理。3. 信号处理函数怎么写才安全3.1 signal() 为什么被嫌弃很多教科书和入门文章还习惯用signal(SIGINT, handler)注册信号处理函数。但在生产环境里我建议尽量别用signal()原因有两个不同 Unix 系统对signal()的行为定义不一致有的系统在信号处理函数执行后会把信号处理重置为默认动作导致下一次信号直接杀死进程。它对中断系统调用的处理也不统一。更干净的替代方案是用sigaction()它把信号处理、屏蔽字、重启行为都拆成显式配置行为可预测。虽然代码多几行但值得。3.2 sigaction 才是正确姿势一个标准的sigaction注册流程大致是这样#include signal.h #include string.h #include errno.h #include unistd.h static volatile sig_atomic_t got_term 0; static void on_term(int sig) { int old_errno errno; got_term 1; errno old_errno; } int main(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler on_term; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; if (sigaction(SIGTERM, sa, NULL) -1) { perror(sigaction); return 1; } while (!got_term) { pause(); } return 0; }关键点有三个注册前先memset然后sigemptyset(sa.sa_mask)不要直接写sa.sa_mask 0因为sigset_t在不同平台实现不一样。sa_flags里的SA_RESTART表示被信号中断的系统调用自动重启能省掉大量EINTR处理。处理函数里的普通标志位要声明成volatile sig_atomic_t这是 C 标准里保证对信号处理安全的整数类型。3.3 信号处理函数里的“雷区”异步信号安全与 errno信号处理函数的执行是异步的可能发生在主流程的任何一个指令中间。这就意味着处理函数里不能调用任何非异步信号安全函数。最典型的例子是printf它内部会加锁还会分配内存。如果主流程正在调用printf或malloc时被信号打断处理函数里又调用同一个库函数就可能死锁或者把堆内部状态改坏。我见过太多“程序随机卡死、随机崩溃、core dump 出现在诡异位置”的线上事故最后定位出来的原因都是处理函数里写了printf。可以参考 POSIX 的 async-signal-safe 函数列表日常最常用的是write、read、open、close、dup、fcntlwait、waitpidsigaction、sigprocmask_exit而printf、malloc、free、fopen、pthread_mutex_lock、strtok这类函数都不要在信号处理函数里用。还有一个很容易被忽视的细节信号处理函数会改变全局变量errno。假设主流程刚执行一个调用准备读取errno结果被信号打断处理函数里又产生了新的errno主流程拿到的就是错误的值。所以规范做法是在处理函数开头保存errno结束前恢复。上面的示例代码已经写了这个习惯。3.4 把信号变成事件self-pipe 与 signalfd处理函数里什么都不能干那业务信息怎么传给主流程常见的办法是“self-pipe trick”信号处理函数里只向一个管道写入一个字节或信号编号主流程阻塞在read或epoll上收到管道可读事件后再从容地处理信号。#include errno.h #include fcntl.h #include signal.h #include string.h #include unistd.h static int pipefd[2]; static void handler(int sig) { int old_errno errno; unsigned char ch (unsigned char)sig; if (write(pipefd[1], ch, 1) 0) { // 忽略 EINTR 或 EAGAIN避免在处理函数里做复杂处理 } errno old_errno; } int main(void) { if (pipe(pipefd) -1) { perror(pipe); return 1; } int flags fcntl(pipefd[1], F_GETFL, 0); fcntl(pipefd[1], F_SETFL, flags | O_NONBLOCK); struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handler; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; sigaction(SIGINT, sa, NULL); unsigned char buf[64]; while (read(pipefd[0], buf, sizeof(buf)) 0) { write(STDOUT_FILENO, got signal\n, 11); } return 0; }如果是在 Linux 上还有一个更现代的方案用signalfd()把信号变成文件描述符。先把信号通过sigprocmask屏蔽掉再创建signalfd之后就可以统一放到poll、select、epoll里监听信号和普通 IO 事件共用一套事件循环代码干净很多。#include poll.h #include signal.h #include sys/signalfd.h #include unistd.h int main(void) { sigset_t set; sigemptyset(set); sigaddset(set, SIGINT); sigaddset(set, SIGTERM); sigprocmask(SIG_BLOCK, set, NULL); int sfd signalfd(-1, set, SFD_NONBLOCK); if (sfd -1) { perror(signalfd); return 1; } struct pollfd fds { .fd sfd, .events POLLIN }; if (poll(fds, 1, -1) 0) { struct signalfd_siginfo si; if (read(sfd, si, sizeof(si)) sizeof(si)) { // si.ssi_signo 就是信号编号 } } return 0; }注意使用signalfd的前提是必须先把这些信号屏蔽掉否则内核会在事件发生时走默认处理或普通 handlersignalfd收不到。4. 实战用 SIGCHLD 管好子进程生命周期4.1 僵尸进程到底怎么来的在 Unix 系统里子进程退出后内核并不会马上把它的进程描述符全部回收而是保留一部分信息包括退出码、资源使用统计等着父进程来“认领”。如果父进程没有调用wait或waitpid这个进程就变成僵尸进程状态 Z。僵尸进程不占多少内存但如果一直没人回收进程表里就会堆满僵尸达到上限后新进程就创建不了了。最常见的错误是父进程只创建子进程不管子进程何时退出。子进程跑完就变僵尸而且父进程毫不知情。这时SIGCHLD就是最佳通知工具。4.2 正确姿势handler 里循环 waitpid前面说过标准信号不排队。你同时创建了 5 个子进程它们几乎同时退出内核可能只向父进程投递了一个SIGCHLD。如果处理函数里只waitpid(-1, status, WNOHANG)一次只能回收一个子进程剩下四个仍然是僵尸。正确做法是在处理函数里用while循环不断回收直到返回0没有已退出的子进程了或-1没有子进程了。注意要加WNOHANG避免处理函数被阻塞在那里。4.3 一个可以直接用的 SIGCHLD 处理模板#include errno.h #include signal.h #include sys/wait.h #include unistd.h static void handle_sigchld(int sig) { int saved_errno errno; pid_t pid; int status; while ((pid waitpid(-1, status, WNOHANG)) 0) { // 这里可以记录 pid 和 status但不要调用 printf // 可以写入全局数组或者用 self-pipe 通知主循环 } errno saved_errno; } int main(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handle_sigchld; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; sigaction(SIGCHLD, sa, NULL); // 之后正常 fork 子进程即可 return 0; }不要小看saved_errno这一行。waitpid返回-1时会把errno改成ECHILD如果不恢复主流程里下一个出错判断可能拿到完全错误的错误码。4.4 更加解耦的方式信号只负责“敲门”如果回收完子进程后还需要根据退出码做后续业务比如把失败任务重新入队那在SIGCHLD的 handler 里做这些逻辑并不可控。更稳妥的设计是handler 里只写一个自管道主循环在可读事件里真正做waitpid和业务处理。这样信号处理函数永远只是“敲个门”业务逻辑全部收敛在事件循环里调试起来清晰很多。5. 多线程下的信号比你想的更麻烦5.1 信号发给进程还是线程这是多线程编程里最容易被搞混的点。标准kill()发送给的是一个进程而进程内如果有多个线程到底哪个线程执行信号处理函数内核会从当前没有屏蔽该信号的线程里挑一个这个选择对用户来说基本不可预测。所以如果你在多线程程序里直接用signal()或sigaction()注册处理函数又希望信号一定能触发某个固定逻辑大概率会遇到随机性。pthread_kill()可以发送给指定线程但业务上通常不希望把线程 id 暴露给所有发送方。5.2 在线程创建前统一屏蔽可靠做法是“反向操作”先屏蔽掉所有需要统一处理的信号再创建线程。这样每个新线程都会继承当前线程的信号屏蔽字等于所有线程都默认不响应这些信号。然后专门创建一个信号处理线程用sigwait()等待这些信号拿到信号编号后在普通线程上下文里处理逻辑完全不用再受“异步安全”限制。#include pthread.h #include signal.h static void *sig_thread(void *arg) { sigset_t *set (sigset_t *)arg; int sig; while (1) { int rc sigwait(set, sig); if (rc 0) { // 在这里可以调用普通库函数 } } return NULL; } int main(void) { sigset_t set; sigemptyset(set); sigaddset(set, SIGINT); sigaddset(set, SIGTERM); // 在所有线程创建之前屏蔽 pthread_sigmask(SIG_BLOCK, set, NULL); pthread_t tid; pthread_create(tid, NULL, sig_thread, set); // 其他工作线程照常创建 return 0; }这里的关键是pthread_sigmask必须在任何工作线程创建之前调用否则信号可能在某个线程创建时就已经有了被投递的目标。5.3 用专用线程配合 sigwait 统一处理sigwait()和信号处理函数不一样它不是“打断某个线程”而是像一个普通接收函数一样等待信号。这样处理信号的那个线程本身是普通线程可以在里面安全地使用锁、容器、日志库不需要遵守异步信号安全规则。这个模式特别适合常驻后台服务SIGTERM、SIGINT、SIGHUP统一在信号线程里处理工作线程完全不受打扰。比起在信号处理函数里“什么都不敢干”这个方案在实际工程里好维护得多。5.4 信号处理代码里别碰互斥锁即使你用了专用线程加sigwait如果某个线程还是用了传统的信号处理函数那处理函数里绝对不要碰pthread_mutex_lock。原因很简单如果信号打断了持有同一把锁的线程处理函数里再去抢锁就是自死锁。遇到需要在信号中唤醒其他线程的场景优先考虑 self-pipe 或者 signalfd让信号处理函数只做最基本的write真正干活的地方放在事件循环线程里。6. 我踩过的信号坑问题排查实录6.1 handler 里调 printf随机死锁有一回做数据采集程序进程频繁收到外部触发信号处理函数里加了句printf(signal received)。看起来一点问题没有但程序隔一段时间就卡住gdb attach 上去所有线程都停在printf内部的锁上。原因不难理解主流程可能正在调用printf持有了内部锁此时信号打断它处理函数里再调printf同一个锁再次被同一线程申请直接死锁。类似的还有在 handler 里malloc、free、fopen都可能触发堆状态损坏。从那以后我的规矩就是信号处理函数里只允许做write、_exit之类的安全操作任何“看起来干净”的库函数都要先在异步信号安全列表里查一遍。6.2 进程收到 SIGTERM 却没反应另一类经典问题是程序部署到服务器上运维执行kill -TERM pid结果进程纹丝不动。一开始以为是信号没发出去最后排查发现是启动代码里某个逻辑调用了pthread_sigmask(SIG_BLOCK, set, NULL)把SIGTERM连同其他信号一起屏蔽了而且没有在任何线程里解除屏蔽。Linux 下可以查看/proc/pid/status里的信号相关字段比如SigBlk、SigCgt、SigIgn它们是以十六进制表示的信号位图。通过它你能快速确认某个信号是否被屏蔽、是否有捕获处理函数。二进制的第 N 位对应信号编号 N排查时照着信号编号换算一下就行。6.3 SIGCHLD 丢失僵尸进程越来越多监控脚本发现服务器上僵尸进程数量不断上涨。最初的处理函数是这样写的void on_sigchld(int sig) { pid_t pid waitpid(-1, NULL, WNOHANG); }每次只回收一个子进程而同一时刻可能有多个子进程退出信号被合并成一次。于是大量子进程没人回收。后来改成while循环回收僵尸问题立刻消失。这也是我反复强调“标准信号不排队”的原因任何基于 SIGCHLD 的回收逻辑都必须默认“一个信号可能对应多个子进程退出”。6.4 系统调用被信号打断read 返回 EINTR服务端程序在accept()上等待新连接收到一个普通信号后accept()返回-1errno是EINTR。如果代码没有处理这个分支会误以为连接失败直接退出或者打印错误。解决办法有两种。一是注册信号时设置sa_flags | SA_RESTART内核会自动重启大多数慢速系统调用。二是在调用处显式重试do { n read(fd, buf, sizeof(buf)); } while (n 0 errno EINTR);后者更稳妥因为有些系统调用即使设置SA_RESTART也不会重启。凡是可能被信号打断的系统调用我都建议保留重试逻辑。6.5 信号问题速查表问题典型表现主要原因对策随机死锁程序卡住不动handler 里调用非异步安全函数只用write/_exit或 self-pipe收不到 SIGTERMkill 后无反应信号被屏蔽检查SigBlk取消屏蔽僵尸进程累积进程表占满只 wait 一次while (waitpid(-1, ..., WNOHANG) 0)read 返回 -1调用报错信号中断慢速系统调用SA_RESTART或对EINTR重试handler 改 errno主流程错误码错乱处理函数改变了 errno保存和恢复 errno信号处理随机线程日志/状态不连续进程信号投递到随机线程统一屏蔽专用线程 sigwait7. 信号与常见异步通信机制的横向对比7.1 各自的分工信号、管道、eventfd 与 signalfd机制数据承载典型用途注意点信号只能带编号实时信号可带整数/指针事件通知、异常中断、子进程回调处理函数受限标准信号不排队管道字节流父子进程之间传普通数据缓存区满会阻塞消息队列结构化消息进程间可靠传递业务数据需考虑消息大小和权限eventfd计数器64 位事件计数、线程间唤醒不能传递业务内容signalfd信号信息结构体把信号融入 epoll 事件循环需先屏蔽对应信号管道和消息队列解决的是“传内容”信号解决的是“通知动作”。如果你需要对方知道“发生了 A 事件”信号够了如果你需要对方知道“A 事件对应的数据是 xxx”那就得配合管道、共享内存或消息队列。7.2 我的选型建议进程管理场景优先用SIGCHLD配合循环waitpid。单线程事件循环程序推荐signalfd信号和网络事件统一走epoll。多线程服务程序推荐“统一屏蔽 专用线程sigwait”把信号降级成普通业务消息。嵌入式或非常依赖可移植性的代码self-pipe trick 是最通用的方案几乎任何 Unix 系都支持。8. 排查信号问题时我用到的调试小工具信号问题最大的特点是“偶发性”。为了定位我给自己定了几个固定动作一是用kill -l先确认信号编号避免把SIGTERM和SIGINT记混。二是用cat /proc/pid/status查看SigBlk、SigCgt、SigIgn直接判断信号的屏蔽和捕获状态。三是在 gdb 里设置handle SIGCHLD nostop noprint pass避免调试多进程时被子进程的信号反复打断。四是必要时用strace -f -e tracesignal跟踪所有信号相关系统调用能快速看到信号发给谁、在哪个时刻产生。如果某个信号导致 core dump别急着删 core 文件先用gdb 程序 core文件看崩溃时的调用栈检查是否在处理函数里调用了危险函数。很多看似奇特的卡死最后都会落到“信号打断了某个临界区”这个结论上。我现在遇到诡异现象第一反应就是去查进程的信号屏蔽字和 handler 注册处大部分问题都能在那里找到答案。信号这门技术不难难的是把“异步”这件事的边界想清楚守好处理函数的安全红线它就能成为非常可靠的通信工具。