Go程序对map加锁仍触发concurrent map读写错误的缺陷排查

1. 已确认的并发冲突点 #

你定位的select块中的map读取确实是触发fatal error: concurrent map read and map write的直接原因：

• Go标准库的map没有内置并发安全保障，只要存在同时发生的读和写操作（无论是否操作同一个key），就会被runtime检测到并抛出致命错误
• select块中<-(*channelMap)[key]的执行逻辑是：先对共享map执行读操作获取对应key的channel，再监听该channel，这个map读操作完全没有加互斥锁保护，而同一时间其他goroutine可能在执行map写入（read函数的赋值操作）或map删除（read函数的defer操作），构成明确的并发读写冲突

2. 简化代码难复现的原因 #

这个问题是概率性触发的，无法复现通常有以下几个原因：

• 测试时长不足：并发冲突依赖特定的时序重叠，短时间运行可能刚好没有触发冲突
• 竞态窗口极小：当前示例中key固定为0，map操作的执行时序刚好错开的概率较高
  你可以在运行程序时加上Go自带的竞态检测参数go run -race main.go，几乎可以100%立即检测到这个并发访问问题。

3. 额外的逻辑缺陷 #

除了并发冲突外，你的代码还存在逻辑错误：

• 多个read协程操作同一个key时，后执行的read协程会覆盖map中该key对应的channel值，导致先执行的read协程在select中读取到的不是自己创建的channel，write协程发送的消息可能永远无法被预期的read协程接收，逻辑完全不符合预期
• 多个read协程的defer删除操作时序混乱，可能出现read协程还在监听channel，对应key就被其他read协程删除的情况

修复方案 #

最简单的修复方式是将创建的channel存储到局部变量中，select直接监听局部变量，完全避免在加锁区域外访问共享map：

func read(channelMap *map[int]chan bool, key int, mutex *sync.Mutex) {
    mutex.Lock()
    ch := make(chan bool, 1) // 用局部变量存储新建的channel
    (*channelMap)[key] = ch
    mutex.Unlock()

    defer func() {
        mutex.Lock()
        delete((*channelMap), key)
        mutex.Unlock()
    }()

    select {
    case <-ch: // 直接读局部变量，不需要访问共享map
    case <-time.After(time.Second):
    }
}

这个修改既解决了并发map读写冲突，也避免了channel被其他协程覆盖的逻辑问题。

内容的提问来源于stack exchange，提问作者Rahn