大家好，我是一个爱分享的牛马程序员，工作中碰到，加上自己理解，很高兴给大家分享。
-begin-
题目：为何用kill函数向进程发送多次SIGUSR1信号，进程却只收到一次？如何保证信号在进程间通信时不丢失？
分析流程：
1.现象解析：很多开发者在使用信号进行进程间通信时，会遇到“信号丢失”的问题——比如进程A连续向进程B发送3次SIGUSR1，但进程B的信号处理函数只执行一次。这并非信号传递失败，而是对信号的“非排队特性”理解不足导致的。
2.深层原因：
Linux信号本质是“软件中断”，设计初衷是处理紧急事件，而非传递大量数据。信号丢失的核心原因在于其“未决信号不排队”的特性：
可以结合生活常识理解：信号就像“快递通知短信”，如果快递员连续发3条“快递到了”的短信，而你没及时查看，最终只会看到一条未读短信——不是前面的短信没发，而是被合并了。
我之前开发一个数据采集系统时，就踩过信号丢失的坑：采集进程每收到一个数据就发SIGUSR1通知处理进程，结果高频率采集时，处理进程经常漏数据。后来用strace跟踪发现，每秒发送的10次信号，处理函数只执行3-4次——这就是忽视信号非排队特性的教训。
◦未决信号队列的覆盖性：当同一信号（如SIGUSR1）多次发送，而进程尚未处理时，内核只会保留一个“未决”状态，后续信号会被直接丢弃，不会累计；
◦信号处理的延迟性：若进程正在执行信号处理函数（处于“信号屏蔽”状态），新的同类型信号会被标记为未决，但不会触发新的处理，直到屏蔽解除；
◦信号优先级的影响：高优先级信号（如SIGKILL）会中断低优先级信号的处理，若此时低优先级信号再次发送，可能因未决状态被覆盖而丢失；
◦缓冲区溢出的隐性丢失：部分开发者通过“信号+全局变量”传递数据（如用SIGUSR1表示“数据就绪”），若数据生成速度快于处理速度，全局变量会被覆盖，造成逻辑上的“信号丢失”。
3.避免信号丢失的核心方法：
◦使用“信号+管道”组合：将信号作为“唤醒通知”，实际数据通过管道传递（管道具有FIFO特性，可缓存数据），避免信号直接承载数据：
// 进程A（发送方） int pipefd[2]; pipe(pipefd); // 创建管道 // 发送数据到管道，再发信号通知 write(pipefd[1], data, len); kill(pid_b, SIGUSR1); // 仅用于唤醒 // 进程B（接收方） void sig_handler(int sig) { char buf[1024]; read(pipefd[0], buf, sizeof(buf)); // 从管道读数据 } signal(SIGUSR1, sig_handler); |
◦采用实时信号（RT信号）：Linux的实时信号（SIGRTMIN到SIGRTMAX，编号34-64）支持排队，多次发送的同类型实时信号会按顺序处理，不会丢失：
// 发送实时信号（带数据） union sigval val; val.sival_int = data; // 传递整数数据 // 发送实时信号，支持排队 sigqueue(pid_b, SIGRTMIN + 1, val); // 接收实时信号 struct sigaction act; act.sa_sigaction = rt_sig_handler; act.sa_flags = SA_SIGINFO; // 启用带数据的处理函数 sigaction(SIGRTMIN + 1, &act, NULL); void rt_sig_handler(int sig, siginfo_t *info, void *ctx) { int data = info->si_value.sival_int; // 获取传递的数据 } |
◦添加确认机制：每次信号处理完成后，由接收方向发送方返回“确认信号”，发送方收到确认后再发送下一个信号，通过“一问一答”避免丢失：
// 发送方逻辑 void send_data(pid_t pid, int data) { global_data = data; kill(pid, SIGUSR1); // 发送数据信号 pause(); // 等待确认信号 } // 接收方逻辑 void sig_handler(int sig) { process_data(global_data); // 处理数据 kill(sender_pid, SIGUSR2); // 发送确认信号 } |
信号通信的最佳实践：
•普通信号（如SIGUSR1）仅用于“通知事件”（如状态变化），不传递具体数据；
•需传递数据或保证不丢失时，优先使用实时信号（SIGRTMIN系列），并通过sigqueue和sa_sigaction传递数据；
•高频率通信场景下，用管道、消息队列（msgget）或共享内存替代信号，这些机制原生支持数据排队；
•信号处理函数应尽量简短，避免在处理函数中调用可能阻塞的函数（如printf、read），防止信号嵌套导致的逻辑混乱。
常见误区：
•认为“信号次数与处理次数一定相等”：普通信号不排队，多次发送可能只处理一次；
•用信号传递大量数据：信号的sigval字段容量有限（通常4字节），不适合传递长数据；
•忽视信号屏蔽的影响：在sigaction中未正确设置sa_mask，可能导致信号在处理期间被意外屏蔽而丢失；
•依赖信号实现同步：信号的异步特性可能导致“竞态条件”，同步场景应使用互斥锁或条件变量。
结论：信号是进程间通信的“轻量级工具”，但并非“万能工具”。其设计特性决定了普通信号不适合需要可靠传输的场景，而实时信号或“信号+其他IPC”的组合，才能在保证效率的同时避免丢失。记住：就像用扳手拧螺丝，合适的工具（通信方式）才能解决对应的问题，强行使用不匹配的工具只会导致麻烦。
-end-
如果文章对你有提升，帮忙点赞，分享，关注。十分感谢
