信号处理安全：可重入性、禁区与 volatile sig_atomic_t
信号处理，说白了就是程序在运行时被“打断”一下，去执行一个紧急的小任务。这个小任务就是信号处理函数。听起来简单，但这里面的坑，我踩过不止一次。今天咱们就聊聊信号处理函数里的三个核心问题：可重入性、哪些函数绝对不能调，以及那个神奇的 volatile sig_atomic_t。
一、可重入性：信号处理函数的“金科玉律”
什么是可重入性？我个人的理解是：一个函数在被调用执行的过程中，如果再次被调用（比如被信号处理函数打断），还能正确执行，不会把数据搞乱，那它就是可重入的。
你想想看，信号处理函数是异步执行的。主程序正跑到一半，信号来了，CPU 直接跳去执行信号处理函数。如果信号处理函数里调用了不可重入的函数，比如 malloc，而主程序刚好也在 malloc 里操作堆内存……嗯，那后果就是堆内存的数据结构被破坏，轻则内存泄漏，重则直接崩溃。
核心原则：信号处理函数中，只能调用可重入函数，或者干脆只做最简单的操作。
我在项目中遇到过这样一个案例：一个后台服务程序，信号处理函数里调用了 printf 来打印日志。平时跑得好好的，但一旦高并发下信号频繁触发，程序就随机崩溃。查了两天才发现，printf 内部使用了全局锁，信号处理函数和主程序同时调用 printf 就死锁了。从那以后，我对信号处理函数里的函数调用就格外小心。
二、不可调用函数列表：信号处理函数的“禁区”
POSIX 标准明确规定了信号处理函数中哪些函数是安全的（async-signal-safe），哪些不是。说白了，就是一张“黑名单”。我把它整理成了一张表，方便你对照。
| 类别 | 不可调用的函数举例 | 原因 |
|---|---|---|
| 内存管理 | malloc, free, realloc, calloc |
内部使用全局锁，不可重入 |
| 标准 I/O | printf, fprintf, sprintf, fread, fwrite |
内部使用缓冲区及锁，不可重入 |
| 锁相关 | pthread_mutex_lock, pthread_mutex_unlock |
如果持有锁时被信号打断，再尝试加锁会导致死锁 |
| 系统调用（部分） | system, wait, waitpid |
可能改变全局状态或阻塞 |
| 时间/环境 | getenv, setenv, time（某些实现） |
内部使用静态缓冲区或全局变量 |
警告：即使某些函数在特定实现上是安全的，也不要依赖。跨平台代码中，只调用 POSIX 明确列出的 async-signal-safe 函数。
我曾经在一个嵌入式项目中，看到同事在信号处理函数里调用了 sprintf 来格式化错误信息。结果程序在压力测试下频繁崩溃。后来改成用 write 系统调用直接写文件描述符，问题才解决。记住，信号处理函数里，越简单越好。
三、volatile sig_atomic_t：信号安全的“原子”通信
既然信号处理函数里不能随便调函数，那怎么和主程序通信呢？最常用的方式就是通过全局变量。但这里有个坑：编译器的优化。
你想想看，主程序里有一个全局变量 flag，信号处理函数里把它设为 1。但编译器可能把 flag 优化到寄存器里，主程序根本看不到信号处理函数对内存的修改。或者，flag 的赋值不是原子的，比如在 32 位系统上写一个 64 位的变量，可能写到一半被信号打断，主程序读到的是个“半成品”。
解决方案就是 volatile sig_atomic_t。
- volatile：告诉编译器，这个变量可能被“外部”修改（比如信号处理函数），不要优化到寄存器里，每次读写都从内存操作。
- sig_atomic_t：这是一个整数类型，保证读写操作是原子的。在大多数平台上，它就是
int或char，但标准保证它的读写不会被中断。
来看一个标准用法：
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
volatile sig_atomic_t g_flag = 0;
void signal_handler(int sig) {
// 信号处理函数中，只做最简单的操作
g_flag = 1;
}
int main() {
signal(SIGINT, signal_handler);
while (1) {
if (g_flag) {
// 主程序检测到信号
printf("收到 SIGINT，准备退出...\n");
break;
}
// 做其他工作
sleep(1);
}
return 0;
}
提示：我个人习惯在信号处理函数中只设置一个或多个 volatile sig_atomic_t 标志位，然后在主程序的主循环中检查这些标志位，再做实际处理。这样既安全又清晰。
为什么不用 int 加 volatile？因为 int 的原子性在不同平台上没有保证。而 sig_atomic_t 是标准明确保证的。你想想看，如果代码要跨平台，用 sig_atomic_t 是最稳妥的。
四、知识体系结构图
下面这张图总结了信号处理安全的核心逻辑，我建议你保存下来，写代码时对照着看。
五、避坑指南与最佳实践
最后，我结合自己的经验，给你几条实用的建议：
- 信号处理函数里只做一件事：设置标志位。 别想着在里面做复杂逻辑，哪怕只是打印一行日志，都可能出问题。
- 标志位用
volatile sig_atomic_t。 别偷懒用普通的int，跨平台时你会感谢这个选择的。 - 主程序的主循环里检查标志位。 信号处理函数设置标志，主程序检测到标志后，再去做实际的处理，比如清理资源、退出等。
- 避免在信号处理函数中调用任何非 async-signal-safe 的函数。 如果不确定，查 POSIX 标准或 man 手册。
我曾经踩过的坑：在一个网络服务器中，信号处理函数里调用了 close 来关闭 socket 文件描述符。但 close 在某些实现中不是 async-signal-safe 的，导致在高并发下文件描述符被重复关闭，程序崩溃。后来改成在信号处理函数中只设置标志位，在主循环中统一处理关闭操作，问题才解决。
嗯，信号处理安全这块，说白了就是“别在信号处理函数里干太多活”。你把它想象成一个紧急电话亭——你只能快速说一句话（设置标志位），然后挂断。所有复杂的讨论（实际处理），都等到主程序有空了再说。这样，你的程序才能在各种信号冲击下稳如泰山。