如何在 Go 中使用 sync.Mutex 和 chan 的选择策略-Golang-PHP中文网

必须用 sync.mutex 保护共享变量，不可用 chan 模拟锁；多 goroutine 读写 map、结构体字段等会触发 fatal error: concurrent map writes 并立即崩溃。

如何在 go 中使用 sync.mutex 和 chan 的选择策略

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

改共享变量必须用 sync.Mutex，别碰 chan

当你在多个 goroutine 里读写同一个 map[string]int、结构体字段、切片或缓存快照时，sync.Mutex 是唯一安全的选择。Go 运行时会直接 panic：fatal error: concurrent map writes，这不是警告，是立即崩溃。用 chan 模拟锁（比如开个 chan struct{} 然后每次操作前 select { case ）语义错乱、调度开销大、还容易死锁。 <ul> <li>map、slice、struct 字段更新：必须用 <code>mu.Lock()/mu.Unlock()

读多写少场景（如配置、健康状态）：优先用 sync.RWMutex，RLock() 不互斥，吞吐更高

单个整数计数器：用 atomic.AddInt64，比锁更轻，零分配、无调度

锁内禁止阻塞操作：http.Get、db.Query、time.Sleep 都得挪到锁外，否则卡住所有等待者

分发任务或通知状态必须用 chan，别用 Mutex

当你需要让 goroutine 协作——比如启动 worker 池、广播“配置已更新”、实现超时退出、或构建日志 pipeline——chan 不是选项，是自然解法。它自带同步语义：ch 会阻塞直到有人接收，这是 <code>Mutex 根本做不到的。

任务分发：用 jobs := make(chan int, 10) + 多个 worker goroutine 从里面取
信号通知：比如 done chan struct{} 或 updateCh chan string，消费者 for range 监听
超时控制：必须配合 select 使用 ctx.Done()，time.After 无法取消，会泄漏 timer
关闭 channel 是唯一安全的“广播结束”方式；反复 close 同一个 channel 会 panic

两者组合用得对，代码才真正清晰

复杂场景下，sync.Mutex 和 chan 不是二选一，而是分工明确：锁保护临界区，channel 解耦通信。比如热更新配置——写入新配置时用 mu.Lock() 保证 map 安全，写完立刻发消息到 updateCh，监听协程收到后 reload，不侵入锁内逻辑。

所有权要明确：生产者 close channel，消费者绝不 close；用 chan 或 <code> 标注方向，防误写
别用 chan int 传“最新值”，比如轮询式想拿当前计数器——这是状态同步，该用原子操作或带锁字段
缓冲 channel 要设合理容量：太小易阻塞写入，太大内存浪费；make(chan string, 10) 常见于事件通知
向已关闭的 channel 发送数据会 panic；接收则得零值并继续执行，可用 v, ok := 判断是否关闭

性能和可维护性陷阱常被忽略

纳秒级的 mu.Lock() 和微秒级的无缓冲 chan 收发，差距不是一个数量级。高频小数据通信（如每毫秒一次状态更新），atomic.Value + sync.RWMutex 比 chan struct{} 更稳。而用 channel 模拟锁、在循环里反复创建无缓冲 channel、把整个 HTTP handler 包进一个 lock ——这些不是“高级用法”，是给自己埋雷。