本文详解因未正确关闭 websocket 连接引发的文件描述符泄漏问题，指导开发者通过 lsof 和系统参数排查“持续 eof”现象，并提供健壮的重连与资源清理方案。
本文详解因未正确关闭 websocket 连接引发的文件描述符泄漏问题，指导开发者通过 lsof 和系统参数排查“持续 eof”现象，并提供健壮的重连与资源清理方案。
在使用 golang.org/x/net/websocket（已归档，但仍有遗留项目依赖）进行长连接通信时，常见现象是：初始连接正常，数小时后 websocket.JSON.Receive 突然持续返回 EOF 错误，即使调用 connect() 重建连接也无法恢复——这通常不是网络抖动或服务端断连所致，而是客户端自身发生了文件描述符（file descriptor）泄漏。
根本原因在于：每次重连时，旧的 *websocket.Conn 对象未被显式关闭，其底层 TCP 连接对应的文件描述符未释放。Linux 系统对每个进程有默认的打开文件数限制（通常为 1024），当泄漏累积至上限，新连接失败、读写操作均会触发 EOF 或 too many open files 错误，最终导致整个应用“假死”。
✅ 快速诊断步骤（Linux 环境）
在问题复现后、重启前，立即执行以下命令定位泄漏：
# 获取进程 PID（以 your-app 为例）
ps aux | grep your-app | grep -v grep | awk '{print $2}'
# 统计该进程当前打开的文件描述符数量（关键！）
lsof -p $PID | wc -l # 总数（含非文件类 fd）
lsof -a -p $PID | wc -l # 仅实际文件/网络连接（更准确）
# 或直接查看 /proc
ls -l /proc/$PID/fd | wc -l若结果远超预期（如 >2000），且 lsof -p $PID | grep websocket 显示大量 IPv4 或 TCP 条目处于 ESTABLISHED 或 CLOSE_WAIT 状态，则确认为连接泄漏。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
同时检查系统级限制：
sysctl fs.file-max # 全局最大值 ulimit -n # 当前 shell 进程限制
? 正确修复：确保连接生命周期可控
原代码中 ws, _ = connect(token) 替换了 ws 变量，但旧连接从未关闭，这是核心缺陷。修正后的 getMessage 应显式关闭旧连接，并增加错误分类处理：
func getMessage(ws *websocket.Conn) (m Message, err error) {
err = websocket.JSON.Receive(ws, &m)
if err != nil {
log.Printf("Receive failed: %v", err)
// 关键：安全关闭旧连接（忽略关闭错误，避免掩盖主错误）
if ws != nil {
_ = ws.Close() // 不要忽略此行！
}
// 仅对网络层错误（非协议错误）尝试重连
if !isNetworkError(err) {
return m, err
}
// 重连并重试
ws, err = connect(token)
if err != nil {
log.Printf("Reconnect failed: %v", err)
return m, err
}
err = websocket.JSON.Receive(ws, &m)
}
return
}
// 辅助函数：判断是否为可重试的网络错误
func isNetworkError(err error) bool {
if err == io.EOF || err == io.ErrUnexpectedEOF {
return true
}
if opErr, ok := err.(*net.OpError); ok && opErr.Err != nil {
return opErr.Err.Error() == "use of closed network connection" ||
opErr.Err.Error() == "connection reset by peer" ||
opErr.Err.Error() == "broken pipe"
}
return false
}⚠️ 重要注意事项
- websocket.Conn 必须显式调用 Close()：它不仅发送关闭帧，更会释放底层 net.Conn 和关联的文件描述符。依赖 GC 自动回收是不可靠的。
- 避免裸 connect() 调用：connect(token) 函数内部应设置合理的 Dialer.Timeout 和 Dialer.KeepAlive，防止阻塞或僵尸连接。
- 升级建议：golang.org/x/net/websocket 已于 2017 年归档，强烈推荐迁移到 gorilla/websocket —— 它提供更完善的错误处理、Ping/Pong 心跳、并发安全的 WriteMessage/ReadMessage，并内置连接健康检查机制。
- 生产环境加固：配合 net/http/pprof 暴露 /debug/fd（需自实现）或使用 expvar 统计活跃连接数，实现连接数监控告警。
通过以上诊断与重构，可彻底解决“重连无效、持续 EOF”的顽疾，让 WebSocket 长连接真正稳定可靠。
