如何处理 WebSocket 的多重连接状态并发难题

WebSocket并发问题核心是状态混乱，需通过单writer队列、组件生命周期绑定、WeakMap状态管理及内存/网络面板验证来解决。

WebSocket 的多重连接状态并发问题，核心不在“连接多”，而在于“状态混乱”——比如多个协程/线程同时读写同一连接、组件卸载后 socket 仍在发消息、重连逻辑与心跳定时器相互干扰等。解决的关键是明确状态归属、隔离操作边界、严格配对生命周期。

一、服务端：避免多线程/协程争抢单个连接

Go、Java、Python 等语言中，若多个 goroutine 或线程直接调用同一 WebSocket 连接的 WriteMessage，极易触发 panic 或消息错乱。

• 用互斥锁（sync.Mutex）保护写入入口，确保写操作串行化
• 更优方案是引入**单 writer goroutine + channel 消息队列**：所有写请求发往 channel，由唯一 goroutine 顺序消费并发送，天然规避竞争
• 读操作可独立运行（如 ReadMessage 单独 goroutine），但解析后的业务处理需判断连接是否仍活跃（如检查 ws.IsClosed()）

二、客户端：连接状态必须与组件生命周期强绑定

React/Vue 中常见问题：组件已卸载，但 onmessage 回调还在更新已销毁的 state，或心跳定时器持续运行。

• 在组件卸载清理函数（useEffect cleanup / onUnmounted）中，必须显式调用 socket.close()
• 关闭前清空所有引用：socket.onmessage = null、socket.onclose = null、socket.onerror = null
• 心跳定时器（setInterval）必须在 onclose 中 clearInterval；监听 window.online 等全局事件也要同步 removeEventListener

三、跨连接协同：状态统一管理，不靠全局变量堆砌

不要用 const sockets = [] 长期累积实例，这会阻碍 GC，且难以追踪哪个连接属于哪个业务模块。

• 按需创建、按需销毁：连接与具体业务上下文（如聊天窗口 ID、设备 ID）绑定，销毁时一并释放
• 使用 WeakMap 存储关联状态（如 WeakMap），避免内存泄漏
• 重连逻辑加约束：最大重试次数（如 5 次）、指数退避（首次 1s，下次 2s、4s…），防止雪崩式新建连接

四、诊断与验证：别只看日志，要观察真实释放效果

是否真正解决了？不能只依赖 console.log，得用工具确认。

• Chrome DevTools → Memory 面板：录制堆快照，筛选 WebSocket 实例，对比操作前后数量变化
• Performance 面板录制：查看是否存在未清除的定时器（Timer Fired 事件持续出现）
• Network 面板关注 WS 标签：观察连接是否重复建立又未关闭（Status 显示 101 后无 Closed）