本文剖析 go 中基于 sync.rwmutex 实现的并发 map 在迭代操作中的典型线程安全缺陷，重点揭示非缓冲通道 + 持久读锁导致的写阻塞问题，并提供简洁、可靠、易维护的修复方案。
本文剖析 go 中基于 sync.rwmutex 实现的并发 map 在迭代操作中的典型线程安全缺陷，重点揭示非缓冲通道 + 持久读锁导致的写阻塞问题，并提供简洁、可靠、易维护的修复方案。
在 Go 中，sync.RWMutex 是构建并发安全 Map 的常用基础，但若使用不当，极易引发隐蔽的死锁或资源泄漏风险。您提供的 ConnectionMap 实现看似合理：读操作用 RLock()/RUnlock()，写操作用 Lock()/Unlock()，且所有临界区均受锁保护。然而，IterKeys() 和 IterValues() 方法存在严重设计缺陷——它们在持有读锁期间启动 goroutine，并通过非缓冲 channel 异步输出迭代结果，而读锁直到整个 for 循环结束、close(kch) 执行后才释放。
这意味着：
✅ 若调用方未完全消费 channel（如提前 break、return 或 panic），goroutine 将永久阻塞在 kch ，导致 <code>RLock() 无法释放；
❌ 此时所有 Lock()（如 Put、Remove、Clear）将无限期等待，整个连接管理陷入停滞；
⚠️ 这正是“已关闭连接未被及时清理”的根本原因——Remove() 被阻塞，无法执行。
以下是修正后的推荐实现（采用同步迭代方案，即前述“方案2”）：
// IterKeys 返回所有 key 的切片（拷贝），不持有锁
func (cm *ConnectionMap) IterKeys() []int64 {
cm.RLock()
keys := make([]int64, 0, len(cm.m))
for k := range cm.m {
keys = append(keys, k)
}
cm.RUnlock()
return keys
}
// IterValues 返回所有 Connection 的副本切片（注意：若 Connection 不可拷贝，需返回指针）
func (cm *ConnectionMap) IterValues() []Connection {
cm.RLock()
vals := make([]Connection, 0, len(cm.m))
for _, v := range cm.m {
vals = append(vals, v) // 假设 Connection 可拷贝；否则用 []*Connection
}
cm.RUnlock()
return vals
}
// 若需流式处理大量数据且必须用 channel，应确保 caller 必须消费完：
// func (cm *ConnectionMap) IterKeysSafe() <-chan int64 {
// ch := make(chan int64, 32) // 设置合理缓冲区
// go func() {
// cm.RLock()
// for k := range cm.m {
// ch <- k
// }
// cm.RUnlock()
// close(ch)
// }()
// return ch
// }关键改进点总结：
- ✅ 消除 goroutine 泄漏风险：迭代逻辑在锁内完成，锁粒度清晰可控；
- ✅ 调用方零负担：返回切片无需额外 channel 消费逻辑，不易出错；
- ✅ 性能更优：避免 goroutine 创建/调度开销及 channel 通信延迟；
- ✅ 语义明确：
IterKeys()表示“此刻快照”，符合多数业务场景（如连接健康检查、批量清理）需求。
额外建议：
- 对于高频读写场景，可考虑使用 Go 标准库
sync.Map（适用于 key 类型为interface{}且读多写少）； - 若需强一致性迭代（如遍历时同时允许增删），应结合
range+sync.Map的Load/Delete，或引入更高级并发结构（如分段锁哈希表）； - 生产环境务必对
ConnectionMap添加单元测试，覆盖IterKeys后Put/Remove并发调用场景。
遵循“锁内做最小必要事，避免跨 goroutine 持锁”原则，才能写出真正健壮的并发 Map。
