信号产生：三种触发方式深度解析
信号是怎么来的？说白了，就是三种途径：用户按键盘、程序自己出问题、或者软件主动设置闹钟。我做了这么多年系统编程，发现很多新手搞不清这三种方式的区别，尤其是硬件异常那块，踩坑的人特别多。
一、终端按键产生信号
这是最直观的方式。你在终端里跑一个程序，按 Ctrl+C，程序就停了。按 Ctrl+Z，程序挂起了。为什么？因为终端驱动帮你发了信号。
核心机制：终端驱动检测到特殊按键组合，向前台进程组发送对应信号。
| 按键组合 | 信号 | 默认行为 | 典型场景 |
|---|---|---|---|
| Ctrl+C | SIGINT (2) | 终止进程 | 强制停止前台程序 |
| Ctrl+Z | SIGTSTP (20) | 暂停进程 | 挂起程序，切回shell |
| Ctrl+\ | SIGQUIT (3) | 终止+生成core | 调试时抓core dump |
嗯，这里要注意：Ctrl+C 发的是 SIGINT，不是 SIGTERM。我见过有人写代码时搞混这两个信号，结果程序怎么都杀不死。你想想看，SIGTERM 是 kill 命令默认发的，而 SIGINT 是终端中断，两者虽然都能终止进程，但语义完全不同。
个人经验：我在写守护进程时，习惯把 SIGINT 也捕获做优雅退出。因为有些运维同事就爱按 Ctrl+C，你总不能指望每个人都记得用 kill 命令吧？
二、硬件异常产生信号
这部分是重灾区。程序崩溃，十有八九是硬件异常导致的信号。我刚开始做C开发时，段错误简直是我的噩梦。
2.1 段错误（SIGSEGV）
段错误，信号编号11。什么时候触发？访问了不属于你的内存。比如：
// 经典段错误示例
int *p = NULL;
*p = 42; // 向地址0写入数据，触发SIGSEGV
// 另一个常见场景：缓冲区溢出
char buf[10];
strcpy(buf, "这段文字太长了，缓冲区装不下"); // 栈被破坏，可能触发SIGSEGV为什么会这样？因为MMU（内存管理单元）发现你访问的虚拟地址没有对应的物理页，或者权限不对，CPU就抛出一个异常。内核收到这个异常，查一下进程的地址空间，发现确实非法访问，于是发送 SIGSEGV。
避坑指南：我曾经在项目中遇到一个诡异的段错误——不是每次都崩，压力测试时才崩。查了两天才发现是栈溢出导致的。线程默认栈大小只有8MB，递归调用太深就把栈撑爆了。解决方案？要么加大栈空间，要么把递归改成迭代。
2.2 浮点异常（SIGFPE）
浮点异常，信号编号8。注意，名字叫"浮点"，但整数运算也会触发。最常见的场景：
int a = 1, b = 0;
int c = a / b; // 整数除零，触发SIGFPE
// 浮点除零其实不会崩溃，会得到inf或nan
double x = 1.0, y = 0.0;
double z = x / y; // z = inf，不会触发信号这里有个坑：整数除零和浮点除零的行为完全不同。整数除零直接发信号，浮点除零返回一个特殊值。为什么？因为IEEE 754标准规定了浮点数的异常处理方式，而整数没有这个标准。
三、软件条件产生信号
这部分是我们主动"制造"信号，用于定时、超时等场景。我个人觉得这是最可控的信号产生方式。
3.1 alarm 函数
alarm() 是POSIX标准的老牌定时器。设置后，内核会在指定秒数后发送 SIGALRM。
#include <unistd.h>
#include <signal.h>
void handler(int sig) {
// 注意：信号处理函数中只能调用异步信号安全的函数
write(STDOUT_FILENO, "时间到！\n", 10);
}
int main() {
signal(SIGALRM, handler);
alarm(5); // 5秒后触发SIGALRM
// 干点别的事...
pause(); // 挂起等待信号
return 0;
}嗯，这里要注意：alarm() 只能精确到秒级。而且每个进程只有一个 SIGALRM 定时器，后设置的会覆盖前一个。我早期做网络超时检测时就踩过这个坑——两个模块同时用 alarm()，结果互相覆盖，超时逻辑全乱了。
3.2 setitimer 函数
setitimer() 是 alarm() 的升级版，支持微秒级精度，而且有三种模式：
| 模式 | 信号 | 行为 | 适用场景 |
|---|---|---|---|
| ITIMER_REAL | SIGALRM | 真实时间倒计时 | 绝对超时控制 |
| ITIMER_VIRTUAL | SIGVTALRM | 用户态CPU时间 | 用户态执行时间限制 |
| ITIMER_PROF | SIGPROF | 用户态+内核态CPU时间 | 性能分析、profiling |
#include <sys/time.h>
#include <signal.h>
void timer_handler(int sig) {
write(STDOUT_FILENO, "定时器触发\n", 12);
}
int main() {
struct itimerval timer;
// 初始间隔：2秒
timer.it_value.tv_sec = 2;
timer.it_value.tv_usec = 0;
// 重复间隔：1秒
timer.it_interval.tv_sec = 1;
timer.it_interval.tv_usec = 0;
signal(SIGALRM, timer_handler);
setitimer(ITIMER_REAL, &timer, NULL);
// 程序继续运行...
while(1) pause();
return 0;
}个人经验：我在做游戏服务器时，用 setitimer 的 ITIMER_REAL 模式做心跳检测。每100毫秒触发一次，检查客户端是否超时。但要注意，信号处理函数里不能做复杂操作，我一般只设置一个标志位，主循环里检查这个标志。
四、三种信号产生方式的对比
为了让你更直观地理解，我画了一张图：
这张图很清楚地展示了：无论信号从哪里来，最终都汇聚到目标进程。内核负责转发，进程负责处理（或者被默认行为干掉）。
五、实战中的避坑指南
最后，我总结几个实战中容易踩的坑：
- alarm 和 setitimer 冲突：两者都用
SIGALRM，混用会导致不可预期的行为。我建议只用setitimer，它更灵活。 - 信号处理函数要轻量：不要在信号处理函数里调用
printf、malloc等非异步信号安全的函数。我一般只设置一个volatile sig_atomic_t标志。 - 硬件异常信号不可忽略：
SIGSEGV、SIGFPE等硬件异常信号，即使你捕获了，处理完返回后可能还会再次触发。我曾经试图在SIGSEGV处理函数里修复内存错误，结果陷入了无限循环。 - 终端信号只发给前台进程组：后台进程按
Ctrl+C是没用的。如果你想让后台进程也能响应，需要用kill命令或者自己实现信号机制。
核心要点：信号产生的三种方式，本质上是"谁触发了信号"的区别。终端按键是用户主动干预，硬件异常是程序自身问题，软件条件是开发者主动控制。理解了这个，你就能根据场景选择合适的信号产生方式。
好了，关于信号产生就讲到这里。记住，信号是Linux进程间通信的基础，也是异常处理的核心机制。多写代码，多踩坑，自然就熟练了。