Go语言Mutex保护指针变量仍出现Data Race的解决方案咨询

问题根因 #

你遇到的数据竞争由两个核心逻辑缺陷共同导致：

1. 全局RWMutex仅保护了map本身的读写，NFetch指针指向的内存内容没有被纳入任何同步机制的保护范围，多个goroutine同时修改同一块int32内存时就会触发竞争
2. NFetchWorker中两次读取map的逻辑存在一致性漏洞：第一次加读锁读取DataBlock判断IsUsingNFetch、释放读锁后，到第二次加写锁读取NFetch的间隙，对应key的DataBlock可能已经被Get方法删除、或被Insert方法覆盖，不仅可能读到不匹配的NFetch指针，极端情况还会拿到nil指针触发panic

可行解决方案（均保留NFetch指针类型） #

方案1：用原子操作操作int32值（性能最优，推荐） #

NFetch是int32类型，完全可以用标准库atomic包的原子操作做同步，不需要依赖全局锁保护指针指向的内容，同时把两次读map合并为一次，避免一致性问题：

func (chm *ConcurrentHashMap) NFetchWorker() {
    for {
        key := <-NFetchWorkerPipe
        chm.mu.RLock()
        data := chm.data[string(key)]
        nFetchPtr := data.NFetch
        isUsingNFetch := data.IsUsingNFetch
        chm.mu.RUnlock()
        if isUsingNFetch && nFetchPtr != nil {
            // 原子操作减1，无锁同步，不会触发竞争
            atomic.AddInt32(nFetchPtr, -1)
        }
    }
}

注意：所有其他地方读取*NFetch的值时，必须统一使用atomic.LoadInt32(nFetchPtr)，不能直接解引用读取，否则仍然会有读竞争。

方案2：写锁范围内完成判断+修改（逻辑改动最小） #

如果不想引入原子操作，可以把判断逻辑和修改逻辑都放到全局写锁的持有范围内，全程只读取一次map，保证操作的一致性：

func (chm *ConcurrentHashMap) NFetchWorker() {
    for {
        key := <-NFetchWorkerPipe
        chm.mu.Lock()
        if data, ok := chm.data[string(key)]; ok && data.IsUsingNFetch && data.NFetch != nil {
            *(data.NFetch)--
        }
        chm.mu.Unlock()
    }
}

该方案缺点是全局写锁持有时间变长，高并发场景下会降低哈希表的整体吞吐量。

方案3：DataBlock增加独立锁（适合块内多字段修改场景） #

如果DataBlock除了NFetch外还有其他需要频繁修改的字段，可以给每个DataBlock增加独立的互斥锁，全局锁仅保护map读写，块内字段修改用独立锁同步，不会阻塞其他key的操作：
首先修改DataBlock定义：

type DataBlock struct {
    ...
    NFetch        *int32
    IsUsingNFetch bool
    mu            sync.Mutex // 新增块级独立锁
    ...
}

修改后的NFetchWorker实现：

func (chm *ConcurrentHashMap) NFetchWorker() {
    for {
        key := <-NFetchWorkerPipe
        chm.mu.RLock()
        data, ok := chm.data[string(key)]
        chm.mu.RUnlock()
        if ok && data.IsUsingNFetch && data.NFetch != nil {
            data.mu.Lock()
            *(data.NFetch)--
            data.mu.Unlock()
        }
    }
}

内容的提问来源于stack exchange，提问作者Nikhil.Nixel