Golang中sync包怎么用_Go语言并发工具实战

Go sync包提供底层同步原语，误用易致死锁、竞态或性能退化；应依场景选Mutex/RWMutex，慎用Once.Do，WaitGroup.Add须在goroutine启动前调用，Pool仅适用于GC可控的临时对象复用。

Go 的 sync 包不是用来“加锁就完事”的，它提供的是底层同步原语，用错场景或组合方式反而会引发死锁、竞态或性能退化。

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

读多写少且读操作耗时明显时，RWMutex 才有收益；否则直接用 Mutex 更轻量、更安全。

• RWMutex 的 RLock/RUnlock 在高并发读下可能饿写，尤其当持续有新读请求进来时，写操作可能无限期等待
• 如果读操作只是取一个 int 或 bool 字段，用 RWMutex 反而增加调度开销，Mutex 更合适
• RWMutex 不支持递归读锁：同一个 goroutine 多次 RLock 后只调一次 RUnlock 会导致 panic

sync.Once 的常见误用：以为它能控制「多次执行」，其实它只保「至少一次」

Once.Do 保证函数最多执行一次，但不保证执行成功 —— 如果传入的函数 panic，Once 会记录为“已执行”，后续调用直接返回，不会重试。

• 不要把带错误处理逻辑（比如重试、fallback）的代码塞进 Once.Do，应在外层封装
• 初始化失败需暴露状态时，建议搭配 sync.Once + 显式标志位：

  var once sync.Once
  var initErr error
  var inited bool
  
  func initResource() error {
      once.Do(func() {
          initErr = doActualInit()
          inited = initErr == nil
      })
      return initErr
  }

sync

.WaitGroup 的 Add 必须在 goroutine 启动前调用

这是最常踩的坑：WaitGroup.Add(1) 放在 go func() 内部，会导致 Wait() 永远阻塞，因为 Add 和 Done 不在同一线程可见序列中。

• 正确姿势是：先 wg.Add(1)，再 go func() { defer wg.Done(); ... }()
• 若需动态确定 goroutine 数量，用循环前预设总数，不要在循环体内边启 goroutine 边 Add
• 注意 WaitGroup 不能被复制 —— 如果结构体里嵌了 sync.WaitGroup，别用值传递，必须传指针

sync.Pool 不是通用缓存，它的生命周期由 GC 控制

Pool 中的对象可能在任意 GC 周期被清理，且不同 goroutine 获取到的可能是不同批次的对象。它只适合「高频创建销毁 + 对象可复用 + 无强状态依赖」的场景，比如临时字节切片、JSON 解析器实例。

• 不要往 Pool 里放含闭包、channel 或未关闭文件句柄的对象
• New 函数仅在 Pool 空时触发，不保证每次 Get 都调用；对象放回 Pool 前务必清空敏感字段（如用户 ID、token），否则可能泄露
• 测试时禁用 GC（GODEBUG=gctrace=1）可观察 Pool 实际复用率，比盲目使用更可靠

真正难的不是记住每个类型的签名，而是判断「当前问题是否属于 sync 包该解决的范畴」—— 很多时候，用 chan 配合 select 或重构为无共享设计，比加锁更简洁、更符合 Go 的并发哲学。