17370845950

net.Conn不能直接复用，因其绑定唯一文件描述符和缓冲区，且不保证并发安全；并发读写会导致数据错乱或连接重置，须用“一连接一goroutine”模型并分离读写协程。

为什么 net.Conn 不能直接复用？

每个 net.Conn 是一个独立的、有状态的连接实例，底层绑定着唯一的文件描述符和读写缓冲区。试图在多个 goroutine 中并发调用 conn.Read() 或 conn.Write() 会导致数据错乱、read: connection reset by peer 或 write: broken pipe —— 因为 TCP 流本身无消息边界，且 Go 的 net.Conn 接口不保证并发安全。

常见错误是写成这样：

go func() { conn.Read(buf) }()  
go func() { conn.Write(data) }()

这会引发竞态，Go 的 race detector 通常能捕获到 sync/atomic 相关警告。

• 必须为每个连接启动独立 goroutine 处理读或写（推荐「一读一写」分离）
• 若需多路写入（如广播、异步通知），应通过 channel 向单个 writer goroutine 投递数据
• 不要在 handler 中直接 defer conn.Close()，除非你确定所有 goroutine 已退出并停止使用该 conn

如何安全地实现「一连接一goroutine」模型？

标准做法是在 accept 后立即启一个 goroutine 处理该连接，内部再拆分为 reader/writer 协程（或仅一个协程做同步读写），避免阻塞主线 accept 循环。

典型结构如下：

for {
    conn, err := listener.Accept()
    if err != nil { continue }
    go handleConnection(conn) // 每连接一个 goroutine
}

handleConnection 内部建议：

• 用 bufio.NewReader(conn) 包装读取，提升小包效率
• 用 io.Copy() 做透传时注意它会关闭目标 io.Writer，慎用于长连接
• 设置 conn.SetReadDeadline() 防止空闲连接长期占用资源
• 用 sync.WaitGroup 或 errgroup.Group 等待 reader/writer 协程退出后再关闭 conn

怎样避免 goroutine 泄漏？

泄漏常发生在：reader 协程因网络中断未退出、writer 协程卡在阻塞写、或 panic 后未 recover 导致协程静默死亡但资源未释放。

关键控制点：

• 所有 conn.Read() 调用前必须设 SetReadDeadline，超时后主动 break 退出 reader
• 写操作建议用带超时的 conn.SetWriteDeadline()，尤其在发送大块数据或响应慢时
• 在 handleConnection 入口加 defer func(){if r := recover(); r != nil { log.Println(r) } }()
• 用 context.WithTimeout 控制整个连接生命周期，例如 5 分钟无活动则强制断开

漏掉 deadline 设置，是线上服务 goroutine 数持续上涨的最常见原因。

需要支持百万连接时，还能用 goroutine per connection 吗？

可以，但要注意：Go runtime 对 goroutine 的调度开销极低（初始栈仅 2KB），实测单机 100w+ 连接 + goroutine 在合理优化下可行。真正瓶颈往往不在 goroutine 数量，而在：

• 系统级限制：ulimit -n 是否足够（需 ≥ 连接数 × 2）
• 内存：每个 net.Conn + goroutine + buffer 约占用 10–20KB，100w 连接 ≈ 10–20GB RAM
• 频繁小包：未合并读写导致 syscall 过多，应启用 TCP_NODELAY(false) 并用 bufio 批量处理
• GC 压力：大量短生命周期 byte slice 容易触发高频 GC，考虑使

  

  用 sync.Pool 复用 buf

别过早切换到 epoll/kqueue 手动轮询模型 —— Go 的 netpoller 已帮你做了这事；先压测、看 profile、再决定是否要上连接池或协议分帧优化。