[wsutil] Broadcaster.writeMu 对每个历史 Conn 永久留存锁条目——轮换型推送服务内存无上界，sync.Map 持引用把已断开的 Conn 连同缓冲一起钉死

现象

wsutil/broadcaster.go:73-77：

// writeMu 按 Conn 记录串行写锁（#87）：……条目不随
// Unregister 删除：在途写可以活得比房间成员身份久，若重注册时换新锁，
// 卡死的旧写会与新写放成并发（正是要防的帧损坏）。
writeMu sync.Map // map[Conn]*sync.Mutex

connWriteLock（broadcaster.go:222-227）只有 Load/LoadOrStore，全文件无任何 Delete；Close()（broadcaster.go:270+）只清 rooms 也不同步清理 writeMu。于是每见过一个 Conn 就永久多一条 Conn→*Mutex 条目，且 sync.Map 的 key 是强引用——断开的 websocket Conn 对象（及其内部读写缓冲、底层 net.Conn 包装）永远无法被 GC。

失败场景推演

长驻广播服务（聊天室/推送/进度流）的客户端轮换是常态（断线重连、App 前后台切换、滚动发布）。每轮换一次泄漏一个 Conn 全量对象：千次/小时的轮换下 RSS 随历史连接总数线性增长、永不回落，数天后 OOM 或内存告警。正确性上毫无症状（帧不坏、测试绿），只有内存一个维度爆。

为什么测试没抓到

现有测试生命周期秒级、断言只看功能（帧正确、房间计数）；泄漏不产生断言失败。#87 的修复测试专测帧交错，没有内存维度断言。

建议修复方向

安全回收条件是「conn 不属于任何房间且写锁空闲（TryLock 成功）」——可在 handleUnregister 收尾处尝试 TryLock 成功后 writeMu.Delete(conn)（拿不到锁说明在途写还活着，留待写协程退出时清理）；或给锁条目加写者退出标记。至少在 godoc 明示泄漏面与监控口径。

置信度：中高（「无 Delete 路径、sync.Map 持引用」为代码级确定事实；泄漏量级依赖部署形态，故非最高档；基线 = network 9f3d2c3）

与既有 issue 的差异：#87（帧损坏）正是引入 writeMu 并写下「条目不随 Unregister 删除」的那条 issue，但其正文只论证正确性（防并发写坏帧），泄漏维度（无上界增长 + pin Conn）无任何 issue 覆盖。delta：#87 解决「删了会坏」，本条指出「不删会漏」，需要安全回收协议。

Merge pull request #152 from oekit/fix/sweep-20261111-network

已在 v0.10.0 修复并发布 ✅

变更内容

本条修复（在 v0.10.0 的版本节里定位到）：

fix(wsutil): Broadcaster.writeMu 锁条目随 Conn 生命周期回收（[wsutil] Broadcaster.writeMu 对每个历史 Conn 永久留存锁条目——轮换型推送服务内存无上界，sync.Map 持引用把已断开的 Conn 连同缓冲一起钉死 #142）——条目此前无任何 Delete 路径，每见过一个 Conn 永久多一条 Conn→锁强引用，断开的 websocket Conn 连同读写缓冲永远无法 GC，轮换型推送服务 RSS 随历史连接总数线性增长、永不回落。现按安全回收协议回收（无在途写协程窗口且 conn 不属任何房间才删，users 计数盖住「取到条目、尚未加锁」的缝隙，恒等校验防换锁）：写协程归还与 Unregister 收尾两处收尾，广播等待超时后在途写 goroutine 可与下一轮并发写同一 Conn——websocket 帧损坏 #87 的同锁串行保证不受影响（在途窗口内条目必留）

该版本 `v0.10.0` 的其余变更

fix(streamx): SSESink.Emit 的关闭检查与 stream 写入原子化（[streamx] SSESink.Emit 的 closed 检查与写入非原子——#117 在 wsutil.Outbox 修掉的同构竞态换包复活，Close 后仍可能写已关 stream 且不返回 ErrSinkClosed #144）——[wsutil] Outbox.Send 的 closed 检查与入队非原子——Close 后通过检查的帧永久滞留，Send 返回 true 却既不写入也不计 Dropped #117 在 wsutil.Outbox 修掉的同构竞态换包复活：closed 检查与写入两步无 happens-before，Close 可插进中间，通过检查的 Emit 把事件写进已关 stream、返回底层 stream 错误而非 ErrSinkClosed（契约「Close 后 Emit 返回 ErrSinkClosed」被击穿，Hub 把正常关闭当 sink 故障留痕）。现照 [wsutil] Outbox.Send 的 closed 检查与入队非原子——Close 后通过检查的帧永久滞留，Send 返回 true 却既不写入也不计 Dropped #117 修法把两步纳入同一临界区（Emit 持 RLock、Close 持 Lock，Close 等在途 Emit 写完才关 stream——慢消费者在途写会推迟 Close 返回，契约明示），Sink 接口契约同步写明原子要求

关联问题单：#144。

fix(mq): MQClient.Close 改 Close(ctx) error（BREAKING）（[mq] MQClient 门面把 Close() error 写进接口——与 AGENTS.md「组件 Close 统一 Close(ctx) error」硬规则及同仓 nats 实现三方分裂，每个后端实现者被迫签名违规 #143）——门面此前把无 ctx 的 Close() error 写进契约，与 AGENTS.md「组件 Close 统一 Close(ctx) error」硬规则及同仓 nats.Client 实现三方分裂：实现者只能无界关停（Client.Close 无超时的 Drain 可能永久阻塞关停——签名违反矩阵 Close(ctx) error 规范 #83/Client.Close 无超时的 Drain 可能永久阻塞关停——且签名违反矩阵 Close(ctx) error 规范 #86 事故形态，ctx 上界入口都没有）或放弃门面。现接口与全部实现统一 Close(ctx) error（Go 不支持同名重载，无参形态移除，调用点改 c.Close(context.Background())），Requester.Request/RequestJSON 的「ctx 截止与 timeout 谁压谁」同步写死：先到先生效（min 语义，context.WithTimeout 同款），timeout ≤ 0 不是「不限时」而是立即到期（同 sshx [sshx] Dial 的 ctx 截止时间与 Budget 不是总预算 —— 握手窗口锚定在连接之后，总耗时可超预算、超 ctx 截止时间 #106 的两截止源教训）

关联问题单：#143。

关联问题单：#142。

现代语言特性（贴合处落地）：clear（Broadcaster.Close 丢弃条目表）、for range int（churn 轮换回归）、errors.Join（并发 emit/close 错误聚合）、sync.Once（SSESink.Close 幂等——「仅首次返回结果」口径贴 nats.Close 先例，故用 Do + 局部结果而非 OnceValue 的结果缓存形态）

Release: https://github.com/oekit/network/releases/tag/v0.10.0

复核确认：修复已合入 main 且随 v0.10.0 发版，main CI 全绿（wsutil/streamx/mq -race 全过）。

Navigation Menu

Repository navigation

[wsutil] Broadcaster.writeMu 对每个历史 Conn 永久留存锁条目——轮换型推送服务内存无上界，sync.Map 持引用把已断开的 Conn 连同缓冲一起钉死 #142

现象

失败场景推演

为什么测试没抓到

建议修复方向

变更内容

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[wsutil] Broadcaster.writeMu 对每个历史 Conn 永久留存锁条目——轮换型推送服务内存无上界，sync.Map 持引用把已断开的 Conn 连同缓冲一起钉死 #142

Description

现象

失败场景推演

为什么测试没抓到

建议修复方向

Activity

zy84338719 commented on Nov 10, 2026

变更内容

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions