如何在Golang中使用sync实现并发控制_Golang sync互斥与等待组方法

可以,但必须确保所有访问这些变量的代码路径都经过同一把 Mutex 的 Lock()/Unlock() 包裹;常见错误是漏锁、panic 导致未解锁、锁内耗时或嵌套锁;Mutex 不可复制。

sync.Mutex 能否保护多个变量?

可以,但必须确保所有访问这些变量的代码路径都经过同一把 MutexLock() / Unlock() 包裹。常见错误是只锁一部分读写,或在 defer 中 unlock 却提前 return 导致锁未释放。

典型误用:

var mu sync.Mutex
var a, b int

func badUpdate() {
    mu.Lock()
    a = 1
    // 忘记锁 b,或这里 panic → b 永远不更新
    b = 2
    mu.Unlock()
}

正确做法是把相关状态视为一个逻辑单元,统一加锁:

func goodUpdate() {
    mu.Lock()
    defer mu.Unlock()
    a = 1
    b = 2
    // 所有共享变量操作都在临界区内
}
  • 不要在锁内做耗时操作(如 HTTP 请求、文件 IO)
  • 避免嵌套锁,否则易死锁;如需多把锁,按固定顺序获取
  • sync.Mutex 不可复制,字段声明后直接使用,别用 new(sync.Mutex) 或赋值给另一个变量

sync.WaitGroup 为什么 Wait 总是提前返回?

根本原因是 Add() 调用时机不对 —— 必须在 goroutine 启动前调用,不能在 goroutine 内部调用。因为 Wait() 只等待计数归零,而 Add() 若在子 goroutine 里执行,主线程可能早已进入 Wait() 并发现计数仍是 0。

错误示例:

var wg sync.WaitGroup
for i := 0; i < 3; i++ {
    go func() {
        defer wg.Done()
        wg.Add(1) // ❌ 错!此时 wg 计数还没加,Wait 可能已开始
        time.Sleep(time.Second)
    }()
}
wg.Wait() // 立即返回

正确写法:

var wg sync.WaitGroup
for i := 0; i < 3; i++ {
    wg.Add(1) // ✅ 必须在 go 前调用
    go func() {
        defer wg.Done()
        time.Sleep(time.Second)
    }()
}
wg.Wait() // 等待全部完成
  • Add() 参数可为负数,但会导致 panic(计数变负),仅用 Done() 更安全
  • WaitGroup 不能被复制,也不能在 Wait() 返回后再复用(Go 1.20+ 允许重用,但需确保无 goroutine 正在调用 Done()
  • 若需动态增减任务数,考虑用 errgroup.Group 替代

sync.Once 是不是线程安全的初始化唯一方案?

是,且是 Go 标准库中唯一推荐的「单次初始化」机制。它内部用原子操作 + 互斥锁实现,比手写 if init == false { ... init = true } 更可靠,尤其在高并发下能避免重复初始化。

典型用途:全局配置加载、数据库连接池初始化、HTTP client 复用等。

var loadConfigOnce sync.Once
var config *Config

func GetConfig() *Config {
    loadConfigOnce.Do(func() {
        config = loadFromYAML("config.yaml") // 这个函数只会执行一次
    })
    return config
}
  • Do() 接收的函数若 panic,Once 会认为已执行完毕,后续调用不再触发 —— 所以务必在闭包内处理异常
  • 不要把带参数的初始化逻辑直接塞进 Do(),容易捕获错误变量;建议封装成无参函数再传入
  • 不需要手动管理 Once 字段生命周期,它本身是零值安全的

sync.RWMutex 比 Mutex 快在哪?

快在「读多写少」场景下允许多个 goroutine 同时读,而 sync.Mutex 无论读写都互斥。但要注意:一旦有 goroutine 请求写锁,所有新来的读请求都会阻塞,直到写完成。

适用场景:缓存、配置表、状态快照等读频次远高于写频次的数据结构。

var rwmu sync.RWMutex
var cache = make(map[string]string)

func Get(key string) string {
    rwmu.RLock()   // ✅ 允许多个 goroutine 并发读
    defer rwmu.RUnlock()
    return cache[key]
}

func Set(key, value string) {
    rwmu.Lock()    // ❗写时独占,且会阻塞后续所有 RLock()
    defer rwmu.Unlock()
    cache[key] = value
}
  • 不要在 RLock() 后调用可能阻塞或耗时的函数(比如另一个锁、channel receive),否则会拖慢其他读操作
  • 没有「升级锁」机制:不能从 RLock() 直接转为写锁,必须先 RUnlock()Lock(),这中间存在竞态窗口
  • 如果读写比例接近 1:1,RWMutex 可能比 Mutex 更慢,因内部状态更复杂
实际项目里最容易被忽略的是:把 sync.WaitGroupsync.Once 当作“语法糖”随意用,却没意识到它们对执行时序的强约束。比如在 http handler 里误用未重置的 WaitGroup,或在循环中反复创建 Once 实例——这些都不会报错,但结果不可预测。