Linux信号捕捉全解析：用户态与内核态切换实战指南

做Linux服务端开发、嵌入式开发或者系统编程，进程信号（Signal）迟早要正面刚。很多人对信号捕捉的理解停留在“用signal()注册一个函数，信号来了就调一下”，但对背后内核态和用户态的切换过程完全没概念。结果就是：信号处理函数里写了printf，跑了几天进程莫名其妙崩了；注册了SIGCHLD却收不到子进程状态；用gdb调试时信号处理函数的执行顺序跟想象完全不一样。这篇文章想把Linux下进程信号的捕捉过程，以及信号处理过程中用户态和内核态的切换关系讲透，给正在搞系统编程的朋友一份可以直接参考的实操笔记。

从“会用到信号”到“真正理解信号”，中间隔着的正是那个完整生命周期：产生、注册、递达、处理，以及围绕它发生的多次状态切换。把这块啃下来，很多线上疑难杂症都能少踩一半。

1. 先从基础说起：信号到底是什么

1.1 信号的本质与分类

信号是操作系统提供的一种软件中断机制，用来异步通知进程发生了某个事件。它不携带数据，只携带一个编号，每个编号代表一种事件。进程收到信号后，可以选择执行默认动作，也可以忽略，还可以调用自定义的处理函数。

在Linux里，信号分为两大阵营：标准信号（编号1到31）和实时信号（编号32到64）。标准信号是传统 Unix 就有的，它们不排队，也就是说，如果同一个标准信号在未决期间反复产生，进程最终只会收到一次。实时信号是POSIX后来补充的，支持排队，支持附带数据，适合需要精确事件计数的场景。

常用信号需要背下来几个：

有两个信号比较特殊：SIGKILL和SIGSTOP，它们既不能被阻塞，也不能被捕获，内核直接执行默认动作。这是系统的最后防线，防止有人写个处理函数把kill -9都拦下来，那就真没法关机了。

1.2 信号的一生：产生、注册、递达、处理

理解信号捕捉之前，得先过一遍信号的完整生命周期。一个信号从产生到被处理，通常经过四个阶段。

第一阶段是“产生”。来源很多，比如用户按下Ctrl+C会产生SIGINT，子进程退出会给父进程发SIGCHLD，进程自己访问了非法内存会产生SIGSEGV，还可以用kill()系统调用主动向进程发信号。

第二阶段是“注册”，在Linux里更准确地叫“记录未决”。内核收到信号后，并不会立刻去处理，只是在该进程的task_struct里把对应的pending位图置位。这个位图就是信号的“待办清单”，标记哪些信号已经到达但没有处理。如果信号被进程设置了阻塞，那么它就会一直停留在pending状态，直到解除阻塞。

第三阶段是“递达”，也就是内核决定把信号真正交给进程处理。递达的时机很关键，它并不是信号一产生就立刻递达，而是发生在进程从内核态返回用户态之前。什么情况下会从内核态返回用户态？典型就是系统调用返回、中断处理返回、异常处理返回。换句话说，信号递达是挂在“内核准备回用户空间”这个检查点上的。

第四阶段是“处理”。如果这个信号没有被捕获，就执行默认动作，比如终止进程、停止进程。如果被捕获了，就切换到用户态执行我们注册的信号处理函数。

为什么信号处理要放到用户态去执行？这是核心中的核心，后面专门讲。

2. 信号捕捉：应用程序该怎么做

2.1 signal() 与 sigaction() 怎么选

应用程序注册信号处理函数，最原始的方式是调用signal()。它的原型很简单：

c复制#include <signal.h>

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

一个典型的用法是这样：

c复制#include <stdio.h>
#include <signal.h>
#include <unistd.h>

static void handler(int sig) {
    // 注意：这里只做最简单的操作
    char msg[] = "catch SIGINT\n";
    write(STDOUT_FILENO, msg, sizeof(msg) - 1);
}

int main(void) {
    signal(SIGINT, handler);
    while (1) {
        pause();
    }
    return 0;
}

但signal()有一个很大的问题：它在不同Unix系统上语义不一样。在System V上，信号处理函数执行完后，该信号的处理方式会被重置为默认行为，而且处理期间不会阻塞同类信号，容易导致信号丢失或反复重入。Linux的glibc实现为了兼容性，对signal()做了优化，只是让它更像BSD语义，但行为仍受历史包袱影响。

真正可靠的做法是用sigaction()：

c复制#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <string.h>

static void handler(int sig) {
    char msg[] = "catch signal\n";
    write(STDOUT_FILENO, msg, sizeof(msg) - 1);
}

int main(void) {
    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);

    while (1) {
        pause();
    }
    return 0;
}

sigaction()比signal()多了三个关键能力：

第一，sa_mask可以指定在信号处理函数执行期间，额外阻塞哪些信号。比如你希望处理SIGINT的时候，同时把SIGTERM也挡在外面，那就在sa_mask里加上SIGTERM。

第二，sa_flags提供了很多控制选项。SA_RESTART让内核在信号处理完后自动重启某些慢速系统调用，避免返回EINTR。SA_SIGINFO允许使用sa_sigaction回调，并获得siginfo_t结构体，里面包含信号发送者的PID、UID、信号产生的详细原因等。

第三，sigaction()不会在触发后被重置，行为稳定统一。

我个人的建议是：新代码一律用sigaction()，不要用signal()。省一次字符，后面省十次排查事故的时间。

2.2 可重入函数与异步信号安全

这是信号处理里最坑、也最容易被忽视的地方。信号处理函数可能在进程执行的任意一条指令处闯入，也就是说，它和主流程是异步并发的。这种并发不是多线程那样的并行，而是“随时打断”。

想在信号处理函数里用printf打印日志？想调用malloc分配内存？想调用pthread_mutex_lock加锁？这些操作全都可能出问题，因为printf内部有全局缓冲区、malloc内部有堆管理锁，如果主流程刚好也在执行同样的函数，信号处理函数再次进入，就造成了重入，轻则数据错乱，重则直接死锁。

用一个生活化的类比：你在厨房切菜，突然电话响了（信号）。你接电话的同时，那只手还在拿刀继续切菜（重入）。如果这时候菜刀只有一把，你两只手抢同一把刀，肯定出事。

POSIX标准维护了一份“异步信号安全函数”列表，只有在列表里的函数才能放心在信号处理函数里调用。常见的包括：

• write、read、open、close
• _exit
• kill
• sigaction、sigprocmask
• waitpid

不在列表里的，比如printf、malloc、free、fprintf、pthread_*系列、getpid等，都严格说明：在信号处理函数里调用是undefined behavior。

所以工程实践有一个铁律：信号处理函数只做最小化操作，典型的三种模式：

• 设置一个volatile sig_atomic_t标志位，主循环检测到后再处理。
• 用write直接向日志文件描述符写入预格式化好的固定字符串。
• 调用sigaction、sigprocmask等信号管理函数自身。

复杂的业务逻辑全部放到主流程里做。这是无数线上事故换来的经验。

3. 内核态与用户态：理解信号处理的底层舞台

3.1 用户态与内核态到底差在哪

要理解信号捕捉，光会API不够，必须搞清楚用户态和内核态的关系。

操作系统把CPU的运行级别分为特权级别，Linux主要使用两个级别：内核态（特权模式）和用户态（非特权模式）。内核态能执行特权指令，能直接访问物理内存、设备寄存器、内核数据结构；用户态则受到严格限制，很多操作必须通过系统调用让内核帮忙完成。

每个进程都有两个栈：用户栈和内核栈。用户栈跑用户空间的函数调用，内核栈跑系统调用、中断处理等内核路径。进程执行用户代码时，处于用户态；一旦发起系统调用、触发中断或者出现异常，CPU就切换到内核态，同时使用该进程的内核栈。

这里有个容易被误解的点：内核态并不是“另一个进程在内核里跑”，而是当前进程在陷入内核后，以更高权限执行内核代码。所以，进程的上下文在内核态和用户态之间切换时，需要保存和恢复非常多的状态，包括通用寄存器、程序计数器、栈指针、信号掩码等。

系统调用入口是用户态进入内核态最典型的路径，比如read()、write()、kill()。中断是另一条路径，比如网卡收到数据包、定时器触发。异常则是第三条路径，比如缺页、除零、非法指令。这三条路径都会导致用户态转向内核态。

3.2 信号处理中的状态切换总览

信号递达和处理，恰恰就是用户态和内核态切换最典型的演示场景。

进程在用户态正常执行代码，突然来了一个信号。内核第一步要做的是把这个信号记录到进程的pending位图里。但这一步不是立刻发生的——硬件中断、系统调用、异常，任何一条路径都可能触发信号产生的逻辑。比如用户在终端按下Ctrl+C，终端驱动会让内核给前台进程组的每个进程发送SIGINT。

接下来的关键时间是：进程在合适的时机从内核态返回用户态。这个“返回”不是简单地跳回去，内核在恢复用户态之前会检查进程的pending位图和blocked位图，如果发现有信号要递达，就处理它。

如果信号处理方式是默认动作，内核直接处置，也许进程就终止了，根本回不到用户态。如果信号被捕获，内核就要安排用户态去执行我们注册的handler。

整个切换序列可以这样理解：

text复制用户态执行主流程
    -> 中断/异常/系统调用陷入内核态
    -> 内核处理完准备返回用户态
    -> 检查到未决信号且被捕获
    -> 内核修改用户栈，构造signal frame
    -> 修改用户态入口为handler地址
    -> 返回用户态执行handler
    -> handler执行完调用sigreturn
    -> 再次陷入内核态
    -> 内核恢复原用户态上下文
    -> 返回用户态继续主流程

也就是说，一次完整的信号捕捉，会经历：用户态到内核态、内核态回用户态（执行handler）、用户态再进内核态（sigreturn）、内核态再回用户态（恢复主流程），总共四次状态切换，两次进入内核、两次返回用户态。这正是标题里“内核态和用户态”的核心关系。

4. 信号捕捉的完整流程拆解

4.1 从进程收到信号到处理函数执行

为了让你彻底搞懂，我把流程再放大，按步骤拆开讲。

第一步，进程正在用户态执行一条普通指令，比如一个循环赋值。此时用户按下了Ctrl+C，产生SIGINT。这个中断信号被CPU捕获，处理器从用户态切换到内核态，开始执行内核的中断处理程序。

第二步，中断处理程序识别出这是Ctrl+C，于是向前台进程组的每个进程发送SIGINT。内核找到目标进程的task_struct，把SIGINT这个bit在pending位图上置位。注意，这里只是“记账”，还没有真正处理。

第三步，中断处理完成后，内核准备返回用户态继续执行刚才的循环。但在恢复现场之前，内核执行“信号检查”逻辑。它会检查pending位图和blocked位图，如果发现有未阻塞且需要递达的信号，就进入递达流程。

第四步，递达流程判断该信号是否注册了用户态handler。如果注册了，内核开始布置用户态执行环境。它会做三件事：

• 保存当前用户态上下文（寄存器、程序计数器等），这些信息会被保存到内核栈上。
• 在用户栈上构造一个signal frame，里面记录了信号编号、被中断前的上下文、信号掩码、以及返回时需要的特殊指令地址。
• 修改用户态的程序计数器，让CPU返回到用户态时，直接跳到handler入口地址。

第五步，内核恢复现场并返回用户态。CPU按修改后的程序计数器执行，也就是进入了我们写的handler函数。

这一步的设计很巧妙：从用户态视角看，handler好像是被“突然调用”的，但实际上内核只是把用户态程序计数器的值改成了handler的地址，并在用户栈上伪造了一个“被信号打断”的函数调用现场。说到底，handler本身是用户态的普通函数，内核只是做了一次跳板。

4.2 处理完信号后如何返回：sigreturn 与上下文恢复

handler执行完毕之后，故事还没结束。关键问题来了：handler怎么回去继续执行原来被中断的主流程？

答案是：handler最后不会像普通函数一样直接return到调用者，因为它的“调用者”其实是被中断的主流程，而主流程的上下文已经被内核保存了，并没有一个正常的调用栈关系。所以内核提供了一种特殊机制，让handler在结束时发起一个系统调用，名为sigreturn（实际更常见的是rt_sigreturn）。

我们的C代码里通常不会显式调用sigreturn，这是glibc在实现信号处理函数入口时自动注入的。当你编译包含handler的程序时，编译器会把handler包装一下，在末尾自动调用rt_sigreturn。从用户视角看，handler就是普通函数，但底层其实多了一层胶水。

rt_sigreturn系统调用触发后，CPU再次从用户态陷入内核态。内核此时从用户栈上取回之前构造的signal frame，恢复被中断那一刻的寄存器、程序计数器、栈指针，同时恢复原来的信号掩码——注意，handler执行期间，内核会自动阻塞当前信号（或者根据sa_mask阻塞其他信号），必须在sigreturn时还原，否则后续信号处理会乱套。

恢复完成后，内核再次返回用户态，进程从被中断的那条指令继续执行。整个过程对于主流程来说，就像只愣了一下神，信号事件已经悄无声息地处理完了。

理解了这个流程，你就会明白为什么handler里不能乱调用函数：handler不是普通函数调用，它和主流程共享同一个用户栈，中间还夹着一次内核态切换，任何破坏栈结构或依赖非可重入库函数的行为，都可能让sigreturn时取回来的上下文变得无效。

4.3 系统调用被信号打断的问题

信号捕捉过程中，还有一个高频率踩坑点：慢速系统调用被信号中断，返回EINTR。

所谓慢速系统调用，是指那些可能长时间阻塞的系统调用，比如read一个慢速设备（终端、管道、socket）、wait等待子进程、pause睡眠、select/poll/epoll_wait等待事件。当进程阻塞在这些调用里时，如果来了一个被捕获的信号，内核会先递达信号并执行handler，但被阻塞的系统调用并不会自动恢复执行，而是直接返回错误码EINTR，告诉你“我被信号打断了，什么都没干”。

处理EINTR有三种常见手段。

第一种，循环重试。看到EINTR就再调用一次，直到成功：

c复制ssize_t ret;
do {
    ret = read(fd, buf, sizeof(buf));
} while (ret == -1 && errno == EINTR);

第二种，使用sigaction的SA_RESTART标志。设置了SA_RESTART后，内核会在信号处理完自动重启某些系统调用，比如read、write、waitpid等。但注意，不是所有系统调用都支持自动重启，像select、poll、epoll_wait、nanosleep这些，即使设置了SA_RESTART也可能直接返回EINTR。所以最稳妥的姿势是：无论设不设SA_RESTART，调用慢速系统调用时都做好EINTR重试。

第三种，采用特殊的信号机制。比如使用signalfd + epoll，把信号变成文件描述符事件，这样epoll_wait就统一处理了，不需要纠结EINTR。

还有两个相关的经典问题需要分辨清楚：SA_RESTART只对慢速系统调用有效，普通函数不受影响；EINTR不是错误，不代表系统调用失败，只是被中断了，重试或者换个等待策略就行。

5. 常见问题与排查技巧实录

5.1 常见问题速查表

下面这个表是我用真金白银踩出来的，基本覆盖了日常开发中信号相关的坑。

5.2 排查工具与调试经验

遇到信号相关的问题，不要瞎猜，直接用工具看现场。

strace是定位信号问题的第一利器。用strace挂到进程上，可以清楚看到进程收到了哪些信号，以及内核为信号做了哪些系统调用。如果你看到rt_sigaction、rt_sigreturn、kill、tgkill这些调用，就知道信号系统在正常工作；如果看到SIGSEGV反复出现然后进程挂掉，那基本就是内存错误。

gdb调试信号处理函数时，有几个要点。默认情况下，gdb会拦截进程收到的信号，比如SIGINT会让程序停在信号处理前，而不是执行handler。这时候你用handle SIGINT stop print nopass可以控制信号的传递。如果你想在handler入口打断点，直接break handler函数名就行，gdb支持。

还有一个很有用的查看入口是proc文件系统。查看/proc//status，里面有几个信号相关字段：

• SigPnd：线程级的未决信号位图
• ShdPnd：进程级的未决信号位图
• SigBlk：当前阻塞的信号位图
• SigIgn：被忽略的信号位图
• SigCgt：被捕获的信号位图

这些位图以十六进制显示，把每个bit拆出来对照信号编号，就能快速知道进程当前对每个信号的处理状态。排查“明明注册了信号为什么没收到”的问题时非常有用。

5.3 实操心得与避坑技巧

最后分享几个我平时写代码时坚持的规矩，这些不是教科书上的，全是经验。

第一，信号处理函数只置标志位，不做任何业务逻辑。这是最安全的模式。主循环里用一个volatile sig_atomic_t变量接收信号，然后统一处理。

c复制static volatile sig_atomic_t g_flag = 0;

static void handler(int sig) {
    g_flag = sig;
}

int main(void) {
    struct sigaction sa;
    sa.sa_handler = handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGINT, &sa, NULL);

    while (1) {
        if (g_flag != 0) {
            // 这里再做真正的业务处理
            g_flag = 0;
        }
        // 其他工作
    }
}

第二，善用sigaction的sa_mask。默认情况下，在处理SIGINT时，内核会把SIGINT自动加入阻塞集，防止同类信号重入。但如果你想在处理SIGINT时不希望被SIGTERM打断，就把SIGTERM加到sa_mask里。别在handler里自己调用sigprocmask来改掩码，那样麻烦且容易出错。

第三，多线程程序里信号处理要换思路。信号是发给整个进程的，进程内任何没有阻塞该信号的线程都可能被选中来执行handler，这就产生了不确定性。工程上常见的做法是：主线程启动前用pthread_sigmask阻塞所有信号，然后专门开一个线程用sigwait或signalfd统一接收和处理信号。这样信号处理逻辑就从异步打断变成了同步等待，心态一下子就稳了。

第四，kill -9解决不了的问题，大部分时候是因为没找到真正的信号源头。别一上来就kill -9，先用strace挂上去看哪个系统调用、哪个中断触发了信号，再对症下药。

第五，不要试图在信号处理函数里做除零之外的复杂算术、不要调用longjmp跳出信号处理函数。虽然POSIX在某些条件下允许longjmp，但它会把信号掩码、栈状态搞得一团糟，尤其是在处理SIGSEGV这类异常信号时，很容易引发二次崩溃。我见过好几个同事在SIGSEGV的handler里用longjmp想“救回来”，最后都是直接起不来。

我个人做后台开发这几年，信号相关的坑踩了不少，最深刻的体会就是一句话：信号处理函数的舒适区就是置个标志位、唤醒一下、记个痕迹，任何超过这个范围的操作都是在给自己埋雷。而当你真正理解了进程信号的捕捉过程、理解了handler执行前前后后的用户态和内核态切换之后，再看那些“诡异”的问题，都会觉得理所当然。这份笔记如果能帮你在Linux系统编程这条路上少踩几个坑，那就算没白写。