go 原生 map 非并发安全，多 goroutine 同时读写会触发数据竞争；即使使用 sync.rwmutex，也必须确保所有共享变量（包括临时接收值的变量）的访问均受同一锁保护，否则仍会引发 race。
go 原生 map 非并发安全，多 goroutine 同时读写会触发数据竞争；即使使用 sync.rwmutex，也必须确保所有共享变量（包括临时接收值的变量）的访问均受同一锁保护，否则仍会引发 race。
在 Go 中，map 类型默认不是并发安全的——这意味着多个 goroutine 同时对同一个 map 执行读+写、写+写，或甚至多个 goroutine 同时写入不同 key，都可能引发 panic 或未定义行为。虽然你使用了 sync.RWMutex 来保护 dictionary 的读写，但原代码中存在两个关键问题，导致 go test -race 报告数据竞争：
? 问题定位：竞争不在 map，而在 value 变量
Race detector 明确指出竞争发生在 value = dictionary["Key"] 这一行。原因在于：
-
value是一个跨 goroutine 共享的局部变量（声明在 goroutine 外部，但在闭包中被多个 goroutine 并发赋值）； - 多个
go func()并发执行value = dictionary["Key"]，而value本身未加任何同步保护； -
RWMutex.RLock()只保护了dictionary的读操作，但无法阻止对value的并发写入。
此外，原代码还存在其他严重隐患：
-
for { }无限启动 goroutine，造成资源爆炸（goroutine 泄漏）； -
log.Println(value)在 goroutine 内部执行，但value的最终值不可预测，且该语句实际永远不会执行（因for无退出条件）； -
RLock()/RUnlock()成对使用缺失（当前代码中RUnlock()被遗漏，会导致死锁风险）。
✅ 正确解决方案：统一锁保护 + 避免共享可变状态
最稳妥的做法是：所有对共享状态（包括 map 和其关联的读取结果变量）的访问，均由同一把互斥锁串行化。以下是修复后的完整示例：
func TestConcurrency(t *testing.T) {
var mu sync.RWMutex
dictionary := make(map[string]interface{}) // 使用 string 作为 key 更符合常规（interface{} key 效率低且易错）
// 启动一个长期运行的 goroutine 模拟并发读写
done := make(chan struct{})
go func() {
defer close(done)
ticker := time.NewTicker(10 * time.Millisecond)
defer ticker.Stop()
for i := 0; i < 100; i++ {
<-ticker.C
// 写操作：加写锁
mu.Lock()
dictionary["Key"] = "written-by-" + strconv.Itoa(i)
mu.Unlock()
// 读操作：加读锁，并在锁内完成读取与局部处理
mu.RLock()
val, ok := dictionary["Key"]
mu.RUnlock()
if ok {
_ = val // 使用 val，避免未使用警告；真实业务中可做进一步处理
}
}
}()
// 等待 goroutine 完成
<-done
}? 关键改进说明：
- 使用
strconv.Itoa需导入"strconv"；- 所有对
dictionary的读写均通过mu保护；- 读取结果
val是函数内局部变量，每个 goroutine 独立持有，彻底消除value竞争；- 避免无限 goroutine 创建，改用
ticker控制节奏；- 显式调用
RLock()/RUnlock()，确保成对出现。
? 进阶建议：何时用 sync.Map？
若场景满足以下条件，可考虑 sync.Map（专为高并发读、低频写优化）：
- Key 类型固定（如
string），且读远多于写； - 不需要遍历全部 key（
sync.Map不提供安全迭代接口）； - 无需原子性地执行“读-改-写”复合操作（如
LoadOrStore可用，但LoadAndDelete等受限）。
示例：
var syncDict sync.Map
syncDict.Store("Key", "value")
if val, ok := syncDict.Load("Key"); ok {
_ = val
}⚠️ 注意：sync.Map 并非万能替代品——它在写密集或需强一致性（如计数器累加）场景下性能反而更差，且 API 更复杂。绝大多数情况，优先选择 map + sync.RWMutex 并严格遵循“锁住所有共享访问”原则。
✅ 总结
- Go map 本身不支持并发读写，必须显式同步；
-
sync.RWMutex仅保护被其包裹的代码段中的变量，不能自动保护闭包捕获的外部变量； - 共享变量（如
value）若被多个 goroutine 写入，必须单独加锁，或改为局部变量； - 始终确保
Lock/Unlock、RLock/RUnlock成对出现，避免死锁； - 使用
-race是发现并发问题的黄金工具，应纳入常规测试流程。
