本文深入剖析一个典型却易被忽视的 Go 竞态问题：即使为字段访问加了 sync.Mutex，仍因对指针变量的非同步读写而触发 race detector 报警；核心在于区分「保护共享数据」与「保护变量本身」。
本文深入剖析一个典型却易被忽视的 go 竞态问题：即使为字段访问加了 `sync.mutex`，仍因对指针变量的非同步读写而触发 race detector 报警；核心在于区分「保护共享数据」与「保护变量本身」。
在 Go 并发编程中，sync.Mutex 是最常用的同步原语，但其作用范围常被误解——它仅保护临界区内对共享内存的访问，而非保护指向该内存的变量本身。你提供的代码看似“加锁了”，实则存在三处独立的竞态（race condition），全部被 go run -race 精准捕获。
? 问题根源分析
关键错误在于 incrementor 函数中对全局指针变量 counter 的操作：
SafeCounter.Add()
-
x := counter：多个 goroutine 同时读取全局counter变量（读-读不冲突，但读-写/写-写会冲突）； -
counter = x：两个 goroutine 并发写入counter指针变量（如goroutine A将counter设为&SafeCounter{c:10}，B同时设为&SafeCounter{c:12}，后者覆盖前者，造成逻辑丢失）； -
fmt.Println(..., x.c)：在x.Add()返回后读取x.c，此时x是局部变量，但x.c的值可能已被其他 goroutine 修改（因x和counter指向同一地址，且x.c读取未加锁）。
⚠️ 特别注意：x 是 *SafeCounter 类型的局部变量，赋值 x := counter 仅复制指针值（8 字节地址），不涉及深拷贝。因此 x.Add() 实际修改的是 counter 所指对象的 c 字段——这正是你需要保护的数据。但 counter = x 这一行毫无意义（x 和 counter 已指向同一对象），反而引入了不必要的竞态。
✅ 正确解法：移除冗余指针赋值，专注保护共享状态
根本原则：让所有对共享状态的访问（读、写、修改）都发生在加锁保护的临界区内，并避免对全局指针变量本身的并发读写。
✅ 推荐重构（简洁、安全、符合 Go 惯例）：
type SafeCounter struct {
c int
sync.Mutex
}
func (c *SafeCounter) Add() {
c.Lock()
c.c++
c.Unlock()
}
func (c *SafeCounter) Value() int { // 新增安全读取方法
c.Lock()
defer c.Unlock()
return c.c
}
var counter = &SafeCounter{} // 全局单例指针 —— 初始化后不再重新赋值！
func incrementor(s string, wg *sync.WaitGroup) {
defer wg.Done()
for i := 0; i <h3>? 关键要点总结</h3>
-
Mutex 不保护变量，只保护临界区内的内存访问：
counter是一个指针变量，其自身存储在全局内存中，需额外同步（或避免并发修改）； -
counter = x是冗余且危险的：x是counter的副本，赋值既不改变状态，又引发竞态；应直接调用counter.Add()； -
所有共享字段读取也需加锁：
fmt.Println(counter.c)是未同步读取，必须通过Value()等加锁方法访问； -
使用
sync.WaitGroup确保主 goroutine 等待完成，避免程序提前退出导致输出不全； -
始终启用
-race检测：它能发现人类难以推理的细微竞态，是并发开发的必备工具。
遵循以上实践，你的计数器将真正线程安全——不仅最终结果正确，中间状态也可预测，且 go run -race 静默通过。
