在开发需要长期运行的服务程序或命令行工具时，优雅退出是基本需求。Linux和macOS遵循POSIX标准，进程通过接收SIGINT信号响应终端的中断指令；Windows没有SIGINT概念，而是以控制台事件机制通知应用程序，典型的是Ctrl+C触发的CTRL_C_EVENT。如果直接用系统原生API写，代码会被拆成两套互不相通的分支。合理的做法是抽象出统一接口，把差异封进实现文件里。
一、POSIX平台的SIGINT处理
在类Unix系统中，signal是最早的信号接口，但行为在不同版本glibc上不完全一致，也不支持掩码控制。更推荐用sigaction，它能明确指定处理函数、信号掩码和标志，避免传统signal的重置问题。我们通常会用一个全局的原子布尔变量记录退出请求，信号处理函数只做最少的事情：置位变量，不调用不可重入函数。
下面代码演示了如何用sigaction安装SIGINT处理器。注意处理函数内部不能调用printf等可能加锁的函数，否则在信号上下文中可能造成死锁。通过std::atomic
#include <signal.h>
#include <atomic>
#include <iostream>
std::atomic<bool> g_should_exit(false);
void handle_sigint(int sig) {
// 只做原子写，不调用不可重入函数
g_should_exit.store(true);
}
int main() {
struct sigaction sa;
sa.sa_handler = handle_sigint;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
sigaction(SIGINT, &sa, nullptr);
while (!g_should_exit.load()) {
// 主循环业务逻辑
}
std::cout << "POSIX进程已优雅退出" << std::endl;
return 0;
}
这种方式的优点是跨所有Unix-like系统一致，缺陷是信号是进程级全局的，如果程序里还用了第三方库也改了SIGINT，就可能互相覆盖。因此封装层最好提供显式的初始化与还原，在析构时恢复旧处理函数。
二、Windows平台的SetConsoleCtrlHandler
Windows没有SIGINT，当用户在控制台按Ctrl+C或关闭窗口时，系统会向进程的控制台回调函数发送CTRL_C_EVENT或CTRL_CLOSE_EVENT。程序必须调用SetConsoleCtrlHandler注册一个返回BOOL的回调，在里面判断事件类型并做清理。和信号不同，这个回调运行在独立线程中，因此主线程退出逻辑可以用事件对象或原子变量来同步。
下面示例展示了如何注册处理器并在回调中识别CTRL_C_EVENT。由于回调线程和主线程并发，直接调用C++标准库IO不一定安全，但比起Unix信号上下文已经宽松很多。我们依旧使用原子变量通知主循环。
#include <windows.h>
#include <atomic>
#include <iostream>
std::atomic<bool> g_should_exit(false);
BOOL WINAPI console_ctrl_handler(DWORD ctrl_type) {
if (ctrl_type == CTRL_C_EVENT) {
g_should_exit.store(true);
return TRUE; // 表示已处理
}
return FALSE; // 其他事件交给系统默认处理
}
int main() {
SetConsoleCtrlHandler(console_ctrl_handler, TRUE);
while (!g_should_exit.load()) {
// 主循环业务逻辑
}
std::cout << "Windows进程已优雅退出" << std::endl;
return 0;
}
需要注意，若程序不是控制台应用或是以服务方式运行，SetConsoleCtrlHandler可能无效。另外，CTRL_CLOSE_EVENT发生时系统只给有限时间退出，复杂清理要提前在CTRL_C_EVENT里完成。用原子变量配合主循环轮询，是兼顾简单与稳定的做法。
三、统一封装跨平台接口
为了让业务代码不关心平台，我们可以提供一个signal_handler.h，内部用条件编译分别包含上面两套实现，对外只暴露install_interrupt_handler和is_exit_requested两个函数。这样在Linux和Windows下主函数写法完全一致。
以下头文件与实现结构演示了封装思路。业务侧只需包含该头文件，调用安装函数并在循环中检查退出标志，不需要写任何#ifdef。
// signal_handler.h
#pragma once
#include <atomic>
void install_interrupt_handler();
bool is_exit_requested();
// signal_handler.cpp
#include "signal_handler.h"
std::atomic<bool> g_exit_flag(false);
#if defined(_WIN32)
#include <windows.h>
BOOL WINAPI ctrl_handler(DWORD t) {
if (t == CTRL_C_EVENT) { g_exit_flag.store(true); return TRUE; }
return FALSE;
}
void install_interrupt_handler() {
SetConsoleCtrlHandler(ctrl_handler, TRUE);
}
#else
#include <signal.h>
void sig_handler(int) { g_exit_flag.store(true); }
void install_interrupt_handler() {
struct sigaction sa;
sa.sa_handler = sig_handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
sigaction(SIGINT, &sa, nullptr);
}
#endif
bool is_exit_requested() { return g_exit_flag.load(); }
这种封装把平台差异收敛到单一编译单元，便于测试与维护。如果将来要支持更多信号如SIGTERM，只需在Unix分支扩展，Windows侧可映射服务停止事件，不影响调用方。对于中小型跨平台工具，该模式在代码量与可靠性之间取得了良好平衡。
四、常见误区与注意事项
一个常见错误是在信号处理函数里直接调用exit或做资源释放。Unix信号上下文极其脆弱，exit可能触发全局析构与IO，导致未定义行为；Windows回调虽在普通线程，但关闭事件有超时限制。正确做法是只设标志，主循环检测到后统一释放。
另一个误区是以为SetConsoleCtrlHandler能捕获所有终止方式。实际上任务管理器强杀、TerminateProcess都不会触发回调，因此关键数据应周期落盘，不能依赖退出信号做唯一保护。理解两套机制的边界，才能写出真正健壮的跨平台C++程序。
C++信号处理SetConsoleCtrlHandler修改时间：2026-08-05 02:57:29