17370845950

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

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

可以，但必须确保所有访问这些变量的代码路径都经过同一把 Mutex 的 Lock() / 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.WaitGroup 和 sync.Once 当作“语法糖”随意用，却没意识到它们对执行时序的强约束。比如在 http handler 里误用未重置的 WaitGroup，或在循环中反复创建 Once 实例——这些都不会报错，但结果不可预测。