如何在Golang中使用sync标准库_Golang并发同步原语详解-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() 前执行。