sync.Mutex 是保护共享变量最直接有效的方式，需作用于被竞争变量本身、避免锁内耗时操作、不可声明为局部变量；读多写少场景用 sync.RWMutex；简单整数/指针操作优先用 sync/atomic；必用 -race 检测竞态。
用 sync.Mutex 保护共享变量是最直接有效的方式
Go 的 goroutine 天然支持高并发，但多个 goroutine 同时读写一个变量（比如全局计数器、map、结构体字段）时，fatal error: concurrent map writes 或静默数据错乱就是典型表现。这时候不能靠“少写点”或“加 sleep”来缓解，必须显式同步。
关键不是“要不要锁”，而是“锁哪”和“锁多久”：
-
sync.Mutex必须作用于被竞争的变量本身，而不是外围逻辑；例如对map[string]int加锁，要确保所有读写都经过同一把mu - 避免在锁内做耗时操作（如 HTTP 请求、文件读写），否则会严重拖慢并发吞吐
- 不要把
mutex声明为局部变量——它必须是共享变量的“伴生字段”或包级变量，否则每次调用都新建一把锁，等于没锁
var mu sync.Mutex
var counts = make(map[string]int)
func inc(key string) {
mu.Lock()
counts[key]++
mu.Unlock()
}
用 sync.RWMutex 区分读多写少场景
当共享数据以读为主（比如配置缓存、路由表）、写极少（仅初始化或热更新），sync.RWMutex 能显著提升并发读性能。它的 RLock() 允许多个 goroutine 同时读，而 Lock() 仍是排他性的。
常见误用是：只对写操作加 Lock()，却对读操作完全不加 RLock()，导致读取时仍可能看到写到一半的中间状态。
立即学习“go语言免费学习笔记（深入）”；
- 读操作必须包裹在
RLock()/RUnlock()中，哪怕只是取一个字段值 -
RWMutex不是银弹——如果写操作频繁，它反而比普通Mutex开销更大 - 不能嵌套使用：在一个已持
RLock()的 goroutine 中再调Lock()会死锁
用 sync/atomic 替代锁处理简单整数或指针操作
对于 int32、int64、uint32、uintptr 和指针类型，sync/atomic 提供无锁原子操作，性能远高于 Mutex，且不会阻塞。
但它只适用于“单个变量”的原子读写或 CAS（CompareAndSwap），无法用于复合操作：
- 像
counter++这种“读-改-写”必须用atomic.AddInt64(&counter, 1)，不能拆成atomic.LoadInt64+atomic.StoreInt64 - 不能用它安全地更新 struct 字段（除非整个 struct 是
unsafe.Pointer且用atomic.CompareAndSwapPointer） -
atomic.Value可安全存取任意类型（如map或struct），但每次Store都是整体替换，不是增量更新
用 -race 编译器检测工具暴露隐藏的竞争
很多竞争条件只在高负载或特定调度下才触发，人工 review 很难发现。Go 自带的竞态检测器是上线前必跑的一环。
运行方式很简单，但有几个关键点容易忽略：
- 必须用
go run -race或go test -race，普通编译不启用检测 - 竞态报告里会标出两个（或多个） goroutine 的读写栈，重点关注 “Previous write at...” 和 “Current read at...” 的交叉点
- CGO 代码、第三方 C 库、syscall 直接操作内存等场景，
-race可能漏报或误报，需结合逻辑分析 - 开启
-race后程序变慢、内存占用翻倍，不能长期在线上运行，仅用于测试阶段
真正棘手的竞争往往藏在边界路径里：比如 defer 中的变量捕获、闭包引用了外部循环变量、或 channel 接收后未检查是否为 nil 就直接解引用。这些地方，-race 能揪出来，但修复得靠你盯住数据流。
