链接关闭的时候有概率发生 panic

[NeverENG]

在跟着《深入理解GO语言》搓框架，在测试的时候发现在关闭的时候有概率发生panic，原因是 sent to closed channle
极小概率，同时看到 issue 中有人提了一下但是不被重视，个人建议要不要加一个recover避免出问题

[aceld]

@NeverENG 你看下最新的master代码会不会出现你说的阻塞情况，出现可以将堆栈信息贴一下，Thanks

[aceld]

@NeverENG

这个 send on closed channel / send to closed channel 的 panic 确实一般是“关闭连接时并发 send”导致的竞态问题，光靠 recover 只能兜底，根因还是要把关闭/发送的时序和状态收敛好。

我这边看了下 master 目前的实现，确实存在一个典型风险点：

• 在 TCP 连接的 SendToQueue 里，如果触发了 case <-c.ctx.Done(): 分支，会直接 close(c.msgBuffChan)（见 znet/connection.go），但与此同时其他 goroutine 可能还在往 c.msgBuffChan <- data 发送，从而小概率触发 send on closed channel。
• WebSocket/KCP 的实现里关闭 msgBuffChan 的路径不完全一样（WS/KCP 主要在 finalizer() 里 close），但同类竞态也可能发生在“关闭与发送并发”的场景中。

所以建议你这边先补充两点信息，方便我们定位到具体触发路径：

1. 你用的是 TCP / WebSocket / KCP 哪种模式？
2. 能否贴一下 panic 的 完整堆栈（尤其是指向哪个文件/哪一行触发了 send on closed channel）？

短期兜底当然可以在 goroutine 入口加 recover，避免进程被打挂；但更推荐的修复方向是：

• 关闭通道要做到 只关闭一次、并且发送方不直接 close（或用 sync.Once 控制 close）；
• 发送时用“连接状态 + ctx.Done()”提前返回，避免对已关闭通道发送；
• 或者统一由 writer goroutine 负责关闭通道，其他发送方只写、不关。

你把堆栈贴出来后，我可以进一步确认是 TCP 的 SendToQueue 这条路径，还是 WS/KCP 的关闭路径，并给出更准确的修复建议/PR 方向。

[NeverENG]

见信安好！ 不好意思，在收到您第一封邮件时想找个时间复现bug，可是因为学业繁重一不小心忘记了（QwQ） 我用的是tcp模式，堆栈信息稍后有时间给您 的确用recover会使得代码混乱，功能不明，也解决不了根因，不过我认为并发send这种小概率事件（发生在链接关闭时）用recover兜底安全退出就好了，当然在writer设置case一劳永逸的方法也方便扩展 祝好！

…

---原始邮件--- 发件人: ***@***.***&gt; 发送时间: 2026年5月4日(周一) 上午10:28 收件人: ***@***.***&gt;; 抄送: ***@***.******@***.***&gt;; 主题: Re: [aceld/zinx] 链接关闭的时候有概率发生 panic (Issue #400) aceld left a comment (aceld/zinx#400) @NeverENG 这个 send on closed channel / send to closed channel 的 panic 确实一般是“关闭连接时并发 send”导致的竞态问题，光靠 recover 只能兜底，根因还是要把关闭/发送的时序和状态收敛好。 我这边看了下 master 目前的实现，确实存在一个典型风险点： 在 TCP 连接的 SendToQueue 里，如果触发了 case <-c.ctx.Done(): 分支，会直接 close(c.msgBuffChan)（见 znet/connection.go），但与此同时其他 goroutine 可能还在往 c.msgBuffChan <- data 发送，从而小概率触发 send on closed channel。 WebSocket/KCP 的实现里关闭 msgBuffChan 的路径不完全一样（WS/KCP 主要在 finalizer() 里 close），但同类竞态也可能发生在“关闭与发送并发”的场景中。 所以建议你这边先补充两点信息，方便我们定位到具体触发路径： 你用的是 TCP / WebSocket / KCP 哪种模式？ 能否贴一下 panic 的 完整堆栈（尤其是指向哪个文件/哪一行触发了 send on closed channel）？ 短期兜底当然可以在 goroutine 入口加 recover，避免进程被打挂；但更推荐的修复方向是： 关闭通道要做到 只关闭一次、并且发送方不直接 close（或用 sync.Once 控制 close）； 发送时用“连接状态 + ctx.Done()”提前返回，避免对已关闭通道发送； 或者统一由 writer goroutine 负责关闭通道，其他发送方只写、不关。 你把堆栈贴出来后，我可以进一步确认是 TCP 的 SendToQueue 这条路径，还是 WS/KCP 的关闭路径，并给出更准确的修复建议/PR 方向。 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***&gt;

[NeverENG]

@aceld 我在下游fork了仓库，构建了稳定浮现 panic 的代码，目前的maste的代码不会出现 send to close chanel的问题，但是测出来了另一个问题，close the close chanel，我这边想要加入 sync.Once 修复这个 bug ，您意下如何