Go服务优雅关闭与平滑重启方法

Go服务的优雅关闭与平滑重启远不止调用`http.Server.Shutdown()`那么简单，其本质是一套精密协同的生命周期管理机制：必须结合信号监听（如SIGTERM）、带超时的context控制、以及关键的文件描述符（fd）复用socket传递，三者缺一不可；否则轻则丢失请求、中断长连接，重则引发goroutine泄漏和连接状态混乱；真正难点在于让每个handler、中间件、数据库/HTTP客户端都严格响应同一ctx，并精准把控父子进程间fd传递、新旧服务切换与连接drain的时序——这在高并发场景下稍有偏差就会暴露严重问题。

Go服务平滑重启和优雅关闭网络连接，核心就一条：必须用 http.Server.Shutdown() 配合信号监听与带超时的 context.Context，同时确保新旧进程通过文件描述符（fd）复用监听 socket——缺一不可。直接调 os.Exit(0)、server.Close() 或只写 Shutdown() 却不监听信号，都会丢请求、断长连接、泄漏 goroutine。

为什么 http.Server.Shutdown() 必须配信号监听

Shutdown() 本身不触发退出，它只是“开始等待”：停止 accept 新连接，但会一直等已有请求自然结束。若没监听 SIGINT 或 SIGTERM，程序就卡在运行中，Ctrl+C 无响应，容器里会被强制 kill -9。

• 必须用 signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM) 注册信号通道
• 不能只监听 SIGHUP：systemd 默认发 SIGTERM，而 SIGHUP 常被拦截或用于配置重载
• 收到信号后，立刻启动 Shutdown()，别加任何中间逻辑（比如先 flush 日志再 shutdown）——这会延迟关闭窗口
• 若用 SIGUSR2 做热重启，注意它不会被 systemd 默认转发，需显式配置 KillSignal=SIGUSR2

如何避免 Shutdown() 卡住不返回

卡住 = 有 handler 还在阻塞，且没响应 ctx.Done()。常见于数据库查询、HTTP 调用、time.Sleep() 等未受控操作。

• 超时 context 必须干净：ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)；不要 defer cancel()，否则 Shutdown() 没开始就取消了
• 所有阻塞调用必须用带 ctx 的版本：db.QueryContext(ctx, ...)、http.DefaultClient.Do(req.WithContext(ctx))
• http.Server.ReadTimeout 和 WriteTimeout 不影响 Shutdown() 行为，它们只管单次读写，不是整个请求生命周期
• 中间件里启动的 goroutine（如日志异步刷盘）必须监听同一 ctx，否则会拖慢 shutdown

热重启时怎么复用监听 socket 而不报 address already in use

Linux 下不能靠“新进程自己 listen”，必须把老 listener 的 fd 传给新进程。标准库不提供自动支持，得手动做。

• 老进程收到 SIGUSR2 后，调 ln.(*net.TCPListener).File() 获取 *os.File，记下 file.Fd()（如 3）
• 启动子进程时，把 fd 编号写进环境变量（如 LISTEN_FD=3），并确保 Files 字段包含该 fd
• 新进程启动后第一件事：读 os.Getenv("LISTEN_FD")，用 os.NewFile(3, "") 恢复 *os.File，再用 net.FileListener(file) 转成 net.Listener
• 验证是否成功：lsof -i :8080 应同时看到两个 PID；若只看到一个，说明 fd 传递失败或新进程没调 net.FileListener

长连接中断的根本原因和修复点

客户端收到 connection reset by peer 或大量 CLOSE_WAIT，通常不是网络问题，而是服务端生命周期管理错位。

• 别在 handler 里用 conn.SetReadDeadline() 后忽略 io.EOF：当 Read() 返回 n == 0 && err == io.EOF，必须立刻 conn.Close()，否则空转 CPU
• 新进程接管 listener 后，旧进程不能立刻 Shutdown()——要等新进程成功 Accept() 到第一个连接，再发信号，否则存在竞态窗口
• 若用了反向代理（如 Nginx），它的 idle timeout（常为 60s）必须大于服务端 Shutdown() 超时，否则连接在服务端还没关完就被代理断开
• goroutine 泄漏最常发生在：handler 启动了后台 goroutine 却没传入 ctx，也没监听 ctx.Done()

真正难的不是写几行 Shutdown()，而是让每个 handler、每层中间件、每个依赖客户端都对同一个 ctx 敏感；更麻烦的是 fd 传递的时序控制——父进程何时 fork、子进程何时 ready、旧连接何时真正 drain 完，这些边界稍有偏差，就会在高并发下暴露问题。

今天关于《Go服务优雅关闭与平滑重启方法》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！