优雅关闭服务：深入理解 SIGINT / SIGTERM 信号处理机制
目录
为什么需要优雅关闭？
什么是 SIGINT 和 SIGTERM？
如何实现优雅关闭（以 C++ 为例）
示例代码（gRPC 服务 + Boost 信号监听）：
优雅关闭时的清理内容通常包括：
与 SIGKILL 的区别？
总结
在构建后端服务、微服务或守护进程时，“优雅关闭（Graceful Shutdown）” 是一个经常被忽视但极其重要的实践。本文将从原理、实际应用、最佳实践等角度，详细介绍优雅关闭的实现方式，尤其是如何使用 SIGINT / SIGTERM 信号来实现它。
为什么需要优雅关闭？
在实际部署中，一个服务可能随时会被下达“关机”命令，比如：
-
手动
Ctrl + C（开发调试时常见）； -
使用
kill命令终止服务； -
容器环境下被 Kubernetes 调用
SIGTERM优雅终止； -
自动部署时滚动重启、蓝绿部署等。
如果不处理关闭逻辑，可能会发生：
-
数据丢失（写入尚未完成）；
-
客户端连接被强制中断；
-
文件或资源句柄未释放；
-
线程或协程未清理，内存泄漏；
-
日志未刷盘；
什么是 SIGINT 和 SIGTERM？
-
SIGINT：中断信号，通常是用户按下Ctrl + C发出的； -
SIGTERM：终止信号，默认kill命令发送（非kill -9）； -
这些信号是可以被捕获、处理或忽略的，适合用于执行清理操作。
如何实现优雅关闭（以 C++ 为例）
这里我们用 C++ 结合 Boost.Asio 来实现监听信号并优雅关闭：
示例代码（gRPC 服务 + Boost 信号监听）：
boost::asio::io_context io_context;
boost::asio::signal_set signals(io_context, SIGINT, SIGTERM);// 绑定信号处理回调
signals.async_wait([&server](const boost::system::error_code& error, int signal_number) {if (!error) {std::cout << "Received signal: " << signal_number << ". Shutting down server..." << std::endl;server->Shutdown(); // 调用 gRPC 的 Shutdown 方法优雅关闭服务}
});// 将 io_context 放入后台线程中监听信号
std::thread([&io_context]() {io_context.run();
}).detach();
优雅关闭时的清理内容通常包括：
| 项目 | 清理操作 |
|---|---|
| 数据库连接池 | 关闭连接 / 归还连接 |
| 文件 | 刷新缓存并关闭句柄 |
| 日志 | 将缓存日志写入磁盘 |
| gRPC/HTTP 服务器 | 等待当前请求处理完成，优雅关闭监听 |
| 线程池 / 协程池 | 通知停止任务、等待处理完毕 |
| 消息队列消费者 | 停止订阅、确认已处理消息 |
| 临时文件或资源 | 删除、释放锁等 |
与 SIGKILL 的区别？
| 信号 | 可处理？ | 用途 |
|---|---|---|
SIGTERM (15) | ✅ 可拦截 | 默认 kill 信号，推荐用于优雅终止 |
SIGINT (2) | ✅ 可拦截 | Ctrl+C，用户触发 |
SIGKILL (9) | ❌ 无法拦截 | 强制终止，立即结束，无机会清理资源 |
总结
-
用
signal()或更安全的boost::asio::signal_set监听信号 -
处理 SIGINT 和 SIGTERM，避免只处理一个
-
服务必须支持异步关闭机制（gRPC 的
Shutdown()、HTTP 的stop()） -
保留资源清理接口（连接池、日志等）
-
结合主线程
wait()和后台信号监听线程工作