Golang信号处理与优雅退出技巧

本文深入解析了Go程序在接收到SIGINT或SIGTERM信号时频繁出现“interrupted system call”错误的根本原因——并非崩溃，而是标准库中如http.Server.Shutdown、os.Stdin.Read等函数在被中断时主动返回context.Canceled或syscall.EINTR错误；文章强调必须主动捕获信号、启动优雅关闭流程并等待资源清理完成，尤其指出signal.Notify需通过for循环持续监听而非单次读取，以防丢失关键信号，并提醒避免在信号处理中执行阻塞操作，为构建高可靠、生产级Go服务提供了清晰、实用的退出机制实践指南。

Go 程序收到 SIGINT 或 SIGTERM 后为什么常出现 interrupt 错误？

因为 Go 的标准库（比如 net/http.Server.Shutdown、os.Stdin.Read、time.Sleep）在被信号中断时，会主动返回 context.Canceled 或 syscall.EINTR 包装的错误，常见表现为：accept: interrupted system call 或 read: interrupted system call。这不是 panic，而是正常行为——但若不处理，会导致服务“卡住”或连接未清理就退出。

关键点在于：Go 不自动重试被中断的系统调用，也不自动关闭监听器；你得自己捕获信号、触发优雅关闭流程，并等待正在运行的操作完成。

用 signal.Notify 捕获信号时，为什么不能只监听一次？

信号是异步事件，只调用一次 signal.Notify 并读取一次通道，很可能错过后续信号（比如用户连按两次 Ctrl+C）。必须持续监听，直到程序真正退出。

• 用 for 循环持续从信号通道读取，而非单次 select
• 监听 os.Interrupt（对应 SIGINT）和 syscall.SIGTERM（Kubernetes 停止容器常用）
• 避免在信号处理函数里做耗时操作（如写日志到磁盘），应只发通知、设标志或关 channel

sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)
go func() {
    
http.Server.Shutdown 调用后为什么还会报错？
Shutdown 是非阻塞的：它立即关闭 listener，拒绝新连接，但不会等已有请求结束。如果直接退出，正在处理的 HTTP 请求可能被强制中断，导致客户端收不到响应、中间件（如日志、metric）状态错乱。

• 必须传入带超时的 context.Context，例如 context.WithTimeout(context.Background(), 10*time.Second)
• 调用 Shutdown 后要 wait，即检查返回的 error —— 如果是 context.DeadlineExceeded，说明有请求超时未结束，需考虑是否强制终止
• 注意：若 server 还没启动（ListenAndServe 没开始），Shutdown 会返回 ErrServerNotStarted，需判空

如何让 goroutine 和资源清理不漏掉？

信号到来时，除了 HTTP server，还有后台任务（如定时器、数据库连接池、消息消费者）需要协调退出。靠全局变量或裸 channel 容易遗漏或竞态。

• 统一用一个 context.Context（如 context.WithCancel(parentCtx)）分发给所有子 goroutine
• 每个长期运行的 goroutine 开头加 select { case <-ctx.Done(): return } ，并在退出前清理资源（如 db.Close()、consumer.Close()）
• 不要依赖 defer 在 main 函数末尾清理 —— 因为 main 可能早于 goroutine 结束而退出
• 特别注意：time.Ticker 必须显式 Stop()，否则 goroutine 泄漏

最易忽略的是：多个 shutdown 步骤之间没有顺序依赖判断。比如 DB 连接池关闭前，HTTP handler 还在查库，就会 panic。所以 shutdown 顺序很重要：先停新请求（server.Shutdown），再等活跃请求结束，最后关依赖资源（DB、Redis、Kafka consumer）。

好了，本文到此结束，带大家了解了《Golang信号处理与优雅退出技巧》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！