如何在Golang中优化WebSocket海量连接内存 Go语言epoll池实战

Go标准库net/http默认WebSocket服务无法支撑10万连接，因其阻塞式模型导致goroutine泛滥、内存飙升、GC频繁且无法复用TCP连接；须改用gorilla/websocket等手动升级连接并配合I/O复用、连接生命周期管理及主动心跳检测。

为什么 net/http 默认 WebSocket 服务扛不住 10 万连接

Go 标准库的 http.Serve 是阻塞式模型，每个连接占一个 goroutine，而默认 runtime.GOMAXPROCS 和调度器在高并发下会因频繁切换、栈分配、GC 扫描导致内存飙升（常达 2–3 GB/10w 连接）。更关键的是，标准 http.ResponseWriter 没有暴露底层 TCP 连接控制权，无法对接 epoll 级别复用。

• 现象：runtime.ReadMemStats 显示 Mallocs 持续上涨，HeapInuse 居高不下，GC 频次超过 5s/次
• 根本原因：没绕过 http.Server 的中间层封装，没接管 net.Conn 生命周期
• 必须换用 gorilla/websocket 或 gobwas/ws 手动升级连接，并配合自定义 listener

如何用 epoll 思路复用 goroutine 而不真用 syscall.epoll

Go 不暴露 epoll 接口，但可通过 net.Conn.SetReadDeadline + net.Conn.SetWriteDeadline 配合非阻塞读写 + runtime.Gosched() 让调度器自然挂起 idle goroutine，等同于“用户态 epoll 池”。核心是避免每个连接独占 goroutine，改用固定数量 worker 处理所有连接的 I/O 事件。

• 用 sync.Pool 复用 websocket.Conn 的读写 buffer，避免每次 ReadMessage 分配新 slice
• worker 数量建议设为 runtime.NumCPU() * 2，太少吞吐不足，太多反而增加调度开销
• 禁用 websocket.Conn.SetPongHandler 默认实现（它会启动 goroutine），改用同步响应 Ping 帧
• 示例关键点：

  conn.SetReadLimit(512 * 1024) conn.SetReadDeadline(time.Now().Add(30 * time.Second)) // 后续在 worker 中循环调用 conn.ReadMessage()

gorilla/websocket 升级后忘记关闭底层 net.Conn 的后果

调用 upgrader.Upgrade 后，HTTP 连接已转为裸 TCP 连接，但 http.Request.Body 和底层 net.Conn 仍被持有。若未显式关闭，连接不会真正释放，FD 泄露，netstat -an | grep :PORT | wc -l 持续增长，最终 hit EMFILE 错误。

• 正确做法：在 Upgrade 成功后立即 req.Body.Close()，并在连接断开时 conn.UnderlyingConn().Close()
• 容易漏掉的场景：panic 恢复路径、超时退出、websocket.CloseMessage 发送后未 Close underlying
• 验证方式：用 lsof -p PID | grep TCP | wc -l 对比连接数与活跃 conn map 长度

心跳和断连检测必须自己做，别信 Ping/Pong 自动机制

gorilla/websocket 的 SetPingHandler 只负责接收 Ping 并自动回 Pong，但不发 Ping，也不检查对方是否失联。客户端假死、NAT 超时、防火墙静默丢包都会让连接卡在 ESTABLISHED 状态，内存持续占用。

立即学习“go语言免费学习笔记（深入）”；

• 必须启动独立 goroutine 定期向每个 conn 发 Ping，并设置 conn.SetWriteDeadline，写失败即标记断连
• 不要用 time.Ticker 全局广播，应 per-conn 启动，避免单个慢连接拖垮全部心跳节奏
• 断连清理必须加锁操作 conn map，且要防止 double-close：先从 map 删除，再调 conn.Close()

最麻烦的其实是连接恢复逻辑——重连窗口、消息去重、状态同步这些，都得在应用层补全。底层优化只解决“能扛住”，不解决“怎么稳住”。