Go语言并发读写普通Map引发竞态问题的优化方案咨询

方案1：为内部普通Map添加互斥锁 #

把productCatalog存储的value改成带互斥锁的结构体，既保证内部Map的并发安全，又不会像嵌套concurrent-map那样带来大量内存开销。

修改更新逻辑： #

import "sync"

// 定义带锁的ID集合结构体
type LockedIDSet struct {
    mu sync.RWMutex
    ids map[int64]struct{}
}

// 更新时的Upsert逻辑
r.productCatalog.Upsert(catalogValue, flatProduct.ProductId, func(exists bool, valueInMap interface{}, newValue interface{}) interface{} {
    productID := newValue.(int64)
    if valueInMap == nil {
        return &LockedIDSet{
            ids: map[int64]struct{}{productID: {}},
        }
    }
    idSet := valueInMap.(*LockedIDSet)
    idSet.mu.Lock()
    defer idSet.mu.Unlock()
    idSet.ids[productID] = struct{}{}
    return idSet
})

修改读取逻辑： #

// 获取数据并安全迭代
catalogProductMap := clientRepo.GetProductCatalogMap()
productIds, ok := catalogProductMap.Get("211")
if !ok {
    // 处理不存在的情况
    return
}
idSet := productIds.(*LockedIDSet)
idSet.mu.RLock()
defer idSet.mu.RUnlock()
// 此时迭代idSet.ids不会有并发写入问题
for pid := range idSet.ids {
    // 业务逻辑
}

优点：内存开销极小（仅增加一个互斥锁实例），读写性能均衡，适合更新频繁的场景。

方案2：原子替换内部Map（无锁方案） #

利用concurrent-map的Upsert操作是原子性的特点，每次更新时复制旧Map并修改，然后替换原Map。这样读取到的Map是不可变的，迭代时不会遇到并发写入。

修改更新逻辑： #

r.productCatalog.Upsert(catalogValue, flatProduct.ProductId, func(exists bool, valueInMap interface{}, newValue interface{}) interface{} {
    productID := newValue.(int64)
    if valueInMap == nil {
        return map[int64]struct{}{productID: {}}
    }
    oldIDs := valueInMap.(map[int64]struct{})
    // 复制旧Map到新Map
    newIDs := make(map[int64]struct{}, len(oldIDs)+1)
    for k := range oldIDs {
        newIDs[k] = struct{}{}
    }
    newIDs[productID] = struct{}{}
    return newIDs
})

读取逻辑无需修改： #

catalogProductMap := clientRepo.GetProductCatalogMap()
productIds, ok := catalogProductMap.Get("211")
data, _ := productIds.(map[int64]struct{})

// 现在迭代不会panic，因为data是更新时复制的不可变Map
for pid := range data {
    // 业务逻辑
}

优点：无需额外锁，读取性能极高；缺点：每次更新会复制Map，适合读取频繁、更新频率较低或内部Map规模较小的场景，避免频繁复制带来的性能和内存波动。

方案3：批量更新+快照读取 #

如果你的更新是每30秒批量执行的，可以考虑在更新完成后生成整个productCatalog的快照，读取时直接访问快照，彻底隔离读写操作：

实现思路： #

1. 维护私有快照变量productCatalogSnapshot，搭配读写锁。
2. 每次批量更新完成后，复制整个productCatalog到快照（或直接替换引用）。
3. 读取时从快照获取数据，无需担心并发写入。

优点：读写完全隔离，性能最优；缺点：读取到的数据有最多30秒的延迟，适合对数据实时性要求不高的场景。

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