如何使用Golang mutex实现共享资源互斥_防止并发读写冲突

Go中使用sync.Mutex保护共享资源需明确共享数据、统一封装访问逻辑、读写均加锁、避免死锁与粒度失当、读多写少用RWMutex、简单原子操作优先atomic，并用-race检测竞态。

使用 Go 的 sync.Mutex 是保护共享资源、避免并发读写冲突最直接有效的方式。关键不是“加锁”本身，而是明确哪些数据是共享的、谁在读/写、锁的粒度是否合理、以及是否遗漏了临界区。

明确共享变量并封装访问逻辑

不要让多个 goroutine 直接读写同一个变量。把共享数据（如 map、计数器、配置结构体）定义为包级或结构体字段，并通过方法控制访问。

• 避免：全局裸变量 var counter int 被多个 goroutine 直接 ++
• 推荐：定义结构体 + mutex + 方法，例如：

type Counter struct {
  mu sync.Mutex
  val int
}

func (c *Counter) Inc() {
  c.mu.Lock()
  c.val++
  c.mu.Unlock()
}

func (c *Counter) Get() int {
  c.mu.Lock()
  defer c.mu.Unlock()
  return c.val
}

读写都必须加锁，不能只锁写不锁读

即使只是读取共享数据，也必须加锁。因为 Go 内存模型不保证未同步读操作能看到最新写入 —— 可能读到脏数据、零值，甚至触发 panic（比如读 map 时被另一个 goroutine 并发修改）。

• 错误示例：if counter > 0 { ... }（没锁，可能刚判断完 counter 就被改了）
• 正确做法：所有访问（包括 ==、len()、遍历）都在锁内完成
• 注意：defer mu.Unlock() 在函数开头加锁后立即写，避免忘记解锁

避免死锁和锁粒度陷阱

死锁常发生在嵌套加锁顺序不一致，或锁住后调用可能再次加同一把锁的函数。锁太粗会降低并发性，太细则易出错。

• 按固定顺序获取多把锁（如总是先 lock A 再 lock B）
• 不要在持有 mutex 时调用不可控的外部函数（如 HTTP 请求、数据库查询），它们可能阻塞或回调本对象
• 考虑读多写少场景：用 sync.RWMutex，允许多个 reader 并发，writer 独占
• 若只做简单原子操作（如 int64 计数），优先用 sync/atomic，比 mutex 更轻量

用 go tool race 检测竞态条件

光靠人工检查很难覆盖所有并发路径。每次测试或运行服务时加上 -race 标志：

go run -race main.go
go test -race ./...

它会在运行时检测实际发生的竞态访问，并打印出读写 goroutine 的堆栈，是最可靠的验证手段。