如何在Golang中使用sync标准库_Golang并发同步原语详解

go sync库提供底层同步原语，需依场景慎选：读多写少且读耗时才用RWMutex；Once仅保首次成功，panic后不再重试；WaitGroup.Add须在goroutine启动前调用；map适用于长生命周期key的高读低写场景。

Go 的 sync 库不是“万能锁工具箱”，它提供的是底层同步原语，用错场景或组合方式反而会引发死锁、竞态或性能退化。

什么时候该用 sync.Mutex 而不是 sync.RWMutex

读多写少且读操作耗时明显（比如遍历大 map 或解码结构体）时，sync.RWMutex 才有收益；否则直接用 sync.Mutex 更简单安全。

• sync.RWMutex 的写锁会阻塞所有新读锁，而读锁之间不互斥——但一旦有 goroutine 在等写锁，后续所有读锁都会排队，可能造成“写饥饿”
• 对小数据（如单个 int64）做保护时，用 sync.Mutex 比 sync.RWMutex 内存开销更小、调用更快
• 不要在 defer 中混用：比如 defer mu.RLock() 是无效的，必须配对 mu.RUnlock()

sync.Once 的常见误用：以为它能控制多次执行，其实只保“首次成功”

sync.Once.Do() 不是“限流器”，也不保证函数一定执行——如果传入的函数 panic，sync.Once 会记录“已尝试”，后续调用不再执行，也不会恢复 panic。

• 典型错误：把初始化数据库连接写在 Do() 里，但连接失败 panic，导致后续所有调用都静默跳过
• 正确做法：在函数内部处理错误，用返回值或全局变量暴露状态，例如：

  var initErr error var once sync.Once once.Do(func() {     initErr = connectDB() })

• sync.Once 无法重置，需要重试逻辑时，应改用 sync.Mutex + 标志位

sync.WaitGroup 的计数陷阱：Add 必须在 goroutine 启动前调用

WaitGroup.Add() 如果在 goroutine 内部调用，极大概率触发 panic：panic: sync: negative WaitGroup counter，因为 Done() 可能在 Add() 前执行。

立即学习“go语言免费学习笔记（深入）”；

• 必须在 go 语句之前调用 wg.Add(1)，不能在 goroutine 函数体开头
• 如果启动数量动态（如从 channel 收消息后起 goroutine），需先用循环确定总数，再批量 Add()，再启动
• 避免在循环中重复声明 sync.WaitGroup：局部变量每次迭代新建，Wait() 永远不会返回

sync.Map 并不适合替代普通 map + Mutex

sync.Map 是为“读远多于写、且 key 生命周期长”的场景优化的，高频写入或频繁创建/销毁 map 时，它比加锁 map 更慢、内存更高。

• 不支持 range 遍历，必须用 Range() 方法，且回调中不能修改 map（否则 panic）
• 没有 len()，要统计长度只能遍历，O(n) 时间复杂度
• key 类型必须可比较（和普通 map 一样），但 value 类型无限制——这点常被忽略，导致类型断言失败
• 如果你的代码里出现 sync.Map.LoadOrStore 调用频率和 Store 相当，说明它没发挥优势，应回退到 map + sync.RWMutex

真正难的不是记住每个原语怎么写，而是判断哪个原语在什么负载特征、什么生命周期、什么错误容忍度下才真正合适。比如 sync.Pool 在对象复用上看似省 GC，但若 Put 进去的对象被外部引用，就会泄漏；这些边界条件，文档不会主动告诉你，只有压测和 pprof 看到 goroutine 阻塞在 mutex.lock 时才意识到——原来当时选错了。