Golang捕获信号实现服务优雅关闭

本文深入剖析了Go语言Web服务在生产环境中实现真正优雅关闭的关键要点：必须同时监听SIGTERM和SIGINT信号以适配容器化（如Kubernetes）和系统服务管理器（如systemd）的终止机制；Shutdown前务必显式关闭listener，避免新连接涌入导致状态混乱；shutdown context超时时间需严格小于平台终止宽限期并预留缓冲，防止被SIGKILL强制终结；而最易被忽视却最致命的隐患是goroutine泄漏——中间件、后台任务、外部依赖中那些未响应退出信号的长期运行协程，往往让Shutdown无限阻塞，因此需系统性排查并为所有异步逻辑注入可取消的context控制。

为什么 signal.Notify 不能只监听 SIGINT 就收工

生产环境里，SIGINT（Ctrl+C）只是个开发调试信号；真正上线后，进程大概率被 SIGTERM 终止（比如 systemd、K8s 的 kill -15）。只监听 SIGINT 会导致服务在容器或 systemd 下无法优雅退出，直接被强制杀掉。

实操建议：

• 必须同时监听 SIGTERM 和 SIGINT，两者行为一致，都走优雅关闭流程
• 避免监听 SIGHUP 或 SIGUSR1 等非标准终止信号，除非你明确要支持热重载等扩展行为
• 不要用 signal.Ignore 屏蔽其他信号——它可能干扰 runtime 内部信号处理（如 SIGQUIT 用于 panic trace）

http.Server.Shutdown 调用前必须先关掉 listener

http.Server.Shutdown 是阻塞的，但它不会自动停掉底层 listener。如果 listener 还开着，新连接仍可能被 accept 进来，而此时 handler 已开始拒绝请求，导致连接半开、超时或 503 混乱。

实操建议：

• 调用 srv.Shutdown 前，先执行 ln.Close()（其中 ln 是你传给 srv.Serve 的 net.Listener）
• 推荐用 net.Listen 显式创建 listener，而不是直接传地址给 http.ListenAndServe，否则拿不到 ln 实例
• 注意：srv.Close() 是粗暴关闭（立即断连），不是优雅关闭，别误用

Context 超时时间必须短于系统级 kill timeout

很多部署环境（如 Kubernetes、systemd）会在发 SIGTERM 后等待固定时间（如 30s），超时就发 SIGKILL 强制终止。如果你设的 context.WithTimeout 是 60s，服务大概率被硬杀，根本来不及完成 Shutdown。

实操建议：

• 设置 shutdown context 超时值 = 部署平台的 terminationGracePeriodSeconds − 5s（留出缓冲）
• 例如 K8s 设了 terminationGracePeriodSeconds: 30，代码里就用 context.WithTimeout(ctx, 25*time.Second)
• 不要依赖 http.Server.IdleTimeout 替代 shutdown 超时——它只管空闲连接，不管正在处理的请求

goroutine 泄漏常藏在中间件或后台任务里

优雅关闭失败，十次有八次不是 Shutdown 本身的问题，而是某个 goroutine 卡在 I/O、channel receive 或无休止 for-select 循环里，导致 Shutdown 一直阻塞不返回。

实操建议：

• 检查所有注册的中间件：是否启动了长生命周期 goroutine（如轮询、定时器）？它们是否接收并响应 shutdown 信号？
• 数据库连接池、消息队列消费者等外部依赖，必须显式调用其 Close 方法，并确保它们也带 context 控制
• 用 runtime.NumGoroutine() 在 shutdown 前后打日志，快速定位泄漏点

最麻烦的从来不是怎么写 shutdown 逻辑，而是得把所有“悄悄跑起来”的 goroutine 全揪出来，挨个加退出机制。没人替你记着那些匿名 go func 里有没有 select

以上就是《Golang捕获信号实现服务优雅关闭》的详细内容，更多关于的资料请关注golang学习网公众号！