优雅关闭数据库连接线程的关键是协作式退出：监听sigterm/sigint信号设置原子退出标志，主循环检查并停止新任务、处理完当前请求后关闭连接、回滚事务、释放资源，主线程等待子线程完成清理。
优雅关闭数据库连接线程，核心不是“关线程”，而是让线程主动感知终止信号、停止新任务、处理完正在执行的请求、再安全释放连接。Linux信号机制在这里起的是“通知开关”作用，而不是直接杀掉线程。
注册 SIGTERM 和 SIGINT 处理器
数据库连接线程通常运行在长期服务进程中（如后台服务、Web 应用 worker）。必须显式监听可捕获的终止信号，最常用的是 SIGTERM（kill -15）和 SIGINT（Ctrl+C）。这两个信号可被程序拦截并自定义响应逻辑。
- 避免只依赖
SIGKILL（kill -9）：它不可捕获、不可忽略，会跳过所有清理步骤，导致连接未关闭、事务未回滚、临时资源残留 - C 语言中用
signal()或更安全的sigaction()注册处理器；Go/Python/Java 等语言有对应 signal 包或 Runtime Hook - 处理函数里不建议做复杂操作（如网络调用、锁竞争），只需设置一个全局原子标志（如
atomic_bool shutdown_requested = false）
线程主循环检查退出标志
数据库工作线程（比如负责执行 SQL 查询、维护连接池、轮询任务队列）应采用“协作式退出”模式，而非等待被强制中断。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 在主循环头部或关键检查点读取退出标志，例如：
while (!atomic_load(&shutdown_requested)) { ... } - 若检测到退出请求，立即停止接收新请求，但继续处理已入队/已开始的任务
- 对数据库连接，应调用
close()或disconnect()，并确保事务回滚（如未提交）、连接归还池中或彻底释放
阻塞系统调用需配合重启或超时机制
很多数据库客户端在执行查询时会阻塞在 read()、poll() 或 epoll_wait() 上，此时即使设置了退出标志，线程也无法及时响应信号。
- 使用带超时的系统调用（如
poll(fd, 1, 100)），定期跳出检查退出标志 - 对阻塞 socket，可设为非阻塞 + 循环重试，或使用
signalfd()将信号转为文件描述符参与 epoll - 某些库支持中断语义（如 libpq 的
PQcancel()），可在收到信号后主动取消挂起查询
确保主线程等待子线程完成清理
主进程收到 SIGTERM 后，不能立刻退出，必须等待数据库线程真正结束——否则内核回收进程时，线程可能还在用已释放的内存或句柄。
- 用
pthread_join()（C/C++）、thread.join()（Go/Python）同步等待 - 设置合理超时（如 30 秒），超时后记录告警，再考虑是否强制终止（此时已属兜底策略）
- Kubernetes/Docker 环境下，需配置
terminationGracePeriodSeconds或--stop-timeout，与代码中的等待逻辑对齐
信号本身不传递数据、不保证顺序、也不替代线程协调逻辑。它只是轻量级的“发令枪”。真正的优雅，在于线程内部的协作设计和资源生命周期管理。
