关于使用 SendBuffMsg以后，QPS下降明显，且有『僵死』连接的一些问题

[redfox1999]

问题一：
表现：现在服务器在有连接进来时，每个连接至少有两个协程。一个是connection.StartReader() 用来读数据，另一个是从 server.go ListenTcpConn函数里，开了一个协程来调用 StartConn(), StartConn 又调用了connection.go 的 Start(), 在 connection 的 Start里。会打开连接的读协程。这时这个协程并不会退出，而是一直等连接关闭，然后去做清理的工作。
connction 默认并不会开启Write协程，只有在每一次调用 SendBuffMsg/SendToQueue 时。才会开始写协程

现在的问题时。我在做压测时。10000连接，每个连接1000个请求与回复，如果服务器用 SendMsg，那一切正常。但如果我用 SendBuffMsg时。会发现QPS下降明显，而且经常会出现有几个连接不关闭，僵死。而且从服务器的协程数来看，用SendMsg 时，一个连接有两个协程，也是我前面提到的那两个。如果用SendBuffMsg时。一个连接就有3个协程。在我上面的说明里看，这也是正常。

想做的修改：

1. 因为server.go StartConn 的协程在开启connection 读协程以后，就一直等在那里等收尾工作，有点浪费。现在想去掉这个，开始读协程以后就直接退出。然后收尾工作由 connction 自己处理。想用 RunOnce的方式，直接在 Read协程里处理或用延时协程处理。
2. connection的写协程，现在有问题，不知道是不是和写超时有关，僵死的连接不知道是什么原因

测试代码在： https://github.com/redfox1999/znix_demo

[aceld]

GPT-5.4 回复

基于当前仓库代码排查，这个 issue 的重点不在 StartConn() 多挂着一个等待关闭的 goroutine，而是在 SendBuffMsg/SendToQueue 这条异步发送路径本身。

结论

1. SendToQueue() 存在并发初始化竞态
   msgBuffChan 的初始化和 writer 启动没有严格同步保护。
   同一连接上多个 goroutine 并发���一次调用 SendBuffMsg() 时，可能出现：

   • 一个 goroutine 已经置位启动标志
   • 但 msgBuffChan 还没初始化完成
   • 另一个 goroutine 已进入发送分支

   这样会导致发送侧阻塞到 timeout，直接拉低 SendBuffMsg() 的 QPS。

2. 发送路径里直接 close(c.msgBuffChan) 是不安全的
   当前关闭逻辑如果放在 SendToQueue() 里：

   • 多个发送方并发走到关闭分支时，可能重复 close
   • 其它 goroutine 还可能继续 send，导致 channel 状态错乱甚至 panic

   msgBuffChan 应该只在连接统一收尾逻辑里关闭，而且要保证只关闭一次。

3. 默认 5ms timeout 在压测下过于激进
   当前 SendBuffMsg() 默认发送等待时间太短，而 writer 又是缓冲+周期 flush 模式。
   在高并发压测下，队列稍有堆积就会大量 timeout，这会进一步放大 SendBuffMsg() 相比 SendMsg() 的吞吐差异。

4. StartConn() 的等待 goroutine 不是这次问题主因
   它确实会增加每连接 goroutine 数量，但它主要是生命周期管理协程，不是导致 SendBuffMsg() QPS 明显下降的核心原因。

---

建议修复

1. 用 sync.Once 或互斥锁保护 msgBuffChan 初始化，确保：

   • channel 只创建一次
   • writer 只启动一次

2. 删除 SendToQueue() 里的 close(c.msgBuffChan)
   发送方只返回错误，不负责关闭 channel。

3. 在连接统一收尾逻辑里关闭 msgBuffChan，并保证幂等。

4. 把 SendBuffMsg() 默认 timeout 调大，或改成可配置（例如 50ms/100ms）。

---

总结

这次问题的核心是异步发送路径同时存在：

• 初始化竞态
• channel 关闭时机错误
• timeout 过短

这三点叠加起来，足以造成：

• SendBuffMsg() QPS 明显下降
• 少量连接关闭异常，表现为“僵死”