Go如何优雅关闭网络连接_Go网络资源释放策略

conn.Read() 返回 0 字节且 err 为 io.EOF 时必须立即关闭连接，否则会导致空转和 CPU 暴涨；需同时检查 n == 0 和 err == io.EOF 作为终止信号，而非仅判断 err != nil。

conn.Read() 返回 0 字节时必须关闭连接

这是最容易被忽视却最致命的坑：当 conn.Read() 返回 read_len == 0 且错误为 io.EOF（或有时无错误），说明对端已发送 FIN，连接进入半关闭状态。此时若继续循环调用 Read()，会立即返回 0 + nil，造成空转、CPU 暴涨。

• ❌ 错误做法：只检查 err != nil 就 break，却忽略 read_len == 0 的语义
• ✅ 正确做法：把 read_len == 0 和 err == io.EOF 一起视为连接终止信号，立刻 conn.Close()
• ⚠️ 注意：io.EOF 不是异常，是正常关闭流程的一部分；而 "broken pipe" 或 "connection reset by peer" 才是异常断连，也需关闭

func handleConn(conn net.Conn) {
    defer conn.Close()
    buf := make([]byte, 4096)
    for {
        n, err := conn.Read(buf)
        if n == 0 || err == io.EOF {
            log.Println("对端关闭连接")
            return
        }
        if err != nil {
            log.Printf("读取失败: %v", err)
            return
        }
        // 处理 buf[:n]
    }
}

设置读写超时 + 心跳探测防中间设备断连

NAT、防火墙、负载均衡器常在空闲 30–300 秒后静默 kill 连接，而 Go 程序毫无感知，后续写入直接 panic 或阻塞。仅靠 io.EOF 检测远远不够。

• conn.SetReadDeadline() 和 conn.SetWriteDeadline() 必须显式设置，不能依赖系统默认
• 服务端建议用心跳（如每 25 秒发一次 ping）+ 超时（如 35 秒未收 pong 就关连接）组合策略
• 客户端重连时，不要立即重试，应指数退避（reconnectionDelay: 1000, reconnectionDelayMax: 5000）

超时值要小于中间设备的 idle timeout，否则永远等不到断开信号。

并发场景下避免重复 Close 和 goroutine 竞态

多个 goroutine 共享一个 *net.TCPConn 时，谁该关？什么时候关？不加协调极易 panic（close of closed channel 类似逻辑也适用于连接）。

• 用 sync.Once 包裹 conn.Close()，确保只执行一次
• 更推荐：用 context.Context 控制生命周期，读/写 goroutine 都监听 ctx.Done()，收到信号后主动退出并触发关闭
• 禁止在 defer 中无条件 conn.Close() —— 如果连接已被其他 goroutine 关闭，defer 会 panic

var once sync.Once
func safeClose(conn 
net.Conn) {
    once.Do(func() {
        conn.Close()
    })
}

服务整体退出时：先停 Listener，再等连接 Drain

程序收到 SIGINT 或 SIGTERM 后，不能直接 os.Exit()。要分两步：停止接受新连接，再等待已有连接自然结束（或超时强制终止）。

• 调用 listener.Close() 会让阻塞的 Accept() 立即返回错误（如 "use of closed network connection"），主循环可快速退出
• 每个活跃连接应注册到 sync.WaitGroup，Accept() 后 wg.Add(1)，处理完 wg.Done()
• 主 goroutine 在关闭 listener 后，用 wg.Wait() 等待所有连接处理完毕，再退出

如果某些连接卡死（比如客户端不读响应），必须设超时（如 10 秒），否则整个 shutdown 会被拖住。