17370845950

Go并发中需用sync.Mutex或sync.RWMutex控制共享资源访问：Mutex适用于读写均需互斥的场景，RWMutex适用于读多写少场景；应优先通过channel避免共享内存，并用-race检测数据竞争。

在 Go 并发编程中，多个 goroutine 同时读写同一变量极易引发数据竞争（data race），导致程序行为不可预测。解决这个问题的核心是**控制对共享资源的访问顺序和权限**，Go 提供了 sync.Mutex（互斥锁）和 sync.RWMutex（读写锁）两种基础同步原语，它们不是“万能药”，而是需要按场景合理选用的工具。

互斥锁（Mutex）：读写都得排队

当你需要确保**任意时刻最多只有一个 goroutine 能访问共享资源**（无论是读还是写），就用 sync.Mutex。它简单、开销小，适合写操作频繁或读写比例接近的场景。

• 调用 mu.Lock() 获取锁，mu.Unlock() 释放锁；务必成对出现，推荐用 defer mu.Unlock() 防止遗漏
• 锁的作用范围应尽量小——只包裹真正需要保护的代码段，避免把网络请求、日志打印等耗时操作包进去
• 不要在持有锁时调用可能阻塞或重入的函数（比如再次 Lock 同一把锁），否则会死锁

读写锁（RWMutex）：读多写少时更高效

当共享资源**读操作远多于写操作**，且读操作本身不改变数据时，sync.RWMutex 更合适。它允许多个 goroutine 同时读，但写操作必须独占（排他）。

• 读操作用 mu.RLock() / mu.RUnlock()，写操作用 mu.Lock() / mu.Unlock()
• RWMutex 不是“读优先”或“写优先”的严格保证，但实际调度中写操作可能被大量读操作饿死，所以不适合写较频繁的场景
• 注意：RLock() 和 Lock() 不能混用——即不能用 RUnlock() 去释放 Lock() 获得的锁

常见误区与实用建议

锁只是手段，不是目的。很多并发问题其实可以通过设计规避，而非堆砌锁逻辑。

• 优先考虑“无共享通信”：用 channel 传递数据，而不是让多个 goroutine 共享一个变量（Go 的信条：“Don’t communicate by sharing memory; share memory by communicating.”）
• 结构体字段级加锁要谨慎：如果只有一两个字段需保护，可单独提取为带锁的小结构，避免整个结构体被锁住影响性能
• 运行时检测数据竞争：go run -race main.go 是开发阶段必做的检查，它能帮你发现隐性 race，比靠经验猜测可靠得多
• 避免全局锁：如非必要，不要把 sync.Mutex 声明为包级变量并到处使用，容易造成耦合和误用

基本上就这些。锁用对了能保安全，用错了反而拖慢程序还藏隐患。关键是理解“谁在什么时候需要访问什么”，再选最轻量、最贴切的同步方式。