Golang Web服务如何优雅关闭_HTTP Server关闭流程

Go 的 http.Server.Shutdown() 是唯一推荐的优雅关闭方式,因它能拒绝新连接、通知活跃连接终止、等待 handler 主动退出;而 Close() 会丢弃 Accept 中连接且不等待已建立连接,导致请求中断和 goroutine 泄漏。

Go 的 http.Server.Shutdown() 是唯一推荐的优雅关闭方式,直接调用 Close()os.Exit() 会导致请求中断、连接重置、数据丢失。

为什么必须用 Shutdown() 而不是 Close()

Close() 立即关闭 listener,所有正在 Accept 的连接会被丢弃,新请求立刻失败(返回 ErrServerClosed),但已建立的连接仍可能在处理中——这些连接不会被通知终止,也不会被等待,服务端可能 panic 或 goroutine 泄漏。
Shutdown() 则会:
• 立即拒绝新连接(Accept() 返回错误)
• 向所有活跃连接发送 FIN,触发 conn.CloseRead() 和超时机制
• 等待每个连接的 Handler 主动退出(前提是 handler 自身支持 context 取消)
• 所有连接完成或超时后才真正返回

标准流程:信号监听 + 带超时的 Shutdown()

关键三步缺一不可:启动服务不阻塞主 goroutine、监听 SIGINT/SIGTERM、用带 deadline 的 context 控制关闭时限。

package main

import ( "context" "log" "net/http" "os" "os/signal" "syscall" "time" )

func main() { http.HandleFunc("/", func(w http.ResponseWriter, r http.Request) { // 注意:真实 handler 应检查 r.Context().Done() log.Println("handling request...") time.Sleep(3 time.Second) w.Write([]byte("ok")) })

srv := &http.Server{Addr: ":8080"}

// 1. 非阻塞启动
go func() {
    log.Println("server starting on :8080")
    if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
        log.Fatal(err)
    }
}()

// 2. 监听退出信号
quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)

// 3. 收到信号后执行 Shutdown,带 10 秒兜底超时
<-quit
log.Println("shutting down gracefully...")

ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()

if err := srv.Shutdown(ctx); err != nil {
    log.Printf("shutdown error: %v", err) // 可能是 context.DeadlineExceeded
}

log.Println("server exited")

}

常见踩坑点:handler 不响应 context、没设超时、gorou

tine 泄漏

handler 忽略 r.Context():比如用 time.Sleep(10 * time.Second) 硬等,Shutdown() 无法中断它,最终超时强制退出,请求失败。
没设 context.WithTimeout:若 handler 卡死(如死循环、未响应的 DB 查询),Shutdown() 永远不返回,进程 hang 住,只能 kill -9
后台 goroutine 未清理:比如你在 handler 里启了子 goroutine 但没传 r.Context() 或没监听 done channel,它们会在 server 关闭后继续运行,造成资源泄漏。
重复调用 Shutdown():第二次调用会立即返回 ErrServerClosed,但不影响正确性;不过逻辑上应确保只调一次。

进阶注意:HTTP/2、长连接、自定义 Listener 的影响

• HTTP/2 连接复用下,单个连接承载多个请求,Shutdown() 会等该连接上所有流(stream)自然结束,不能强制中断单个 stream。
• 若用了自定义 net.Listener(如 TLS、SO_REUSEPORT),需确保其 Close() 方法能快速返回,否则 Shutdown() 会卡在 closeListenersLocked()
• 对 WebSocket 或 SSE 等长连接,务必在 handler 中监听 r.Context().Done() 并主动关闭底层 conn,否则连接会一直挂着直到超时或客户端断开。

真正决定“是否优雅”的从来不是 shutdown 调用本身,而是 handler 是否尊重 context、后台任务是否可取消、超时是否合理——这些地方写错一行,整个优雅关闭就失效了。