如何避免Go并发中的数据竞争_Go并发安全处理方法_技术教程

应使用 sync.Mutex 保护共享变量，因 goroutine 轻量但非线程安全；多 goroutine 同时读写未同步变量会引发数据竞争，需读写均加锁，避免漏锁、死锁或锁粒度不当。

用 `sync.Mutex` 保护共享变量，而不是靠“我保证不会同时写”

Go 的 goroutine 轻量，但不等于线程安全。只要多个 goroutine 同时读写同一个变量（比如一个全局 map 或结构体字段），且没加同步机制，就构成数据竞争——go run -race 会直接报 Data race 错误。

常见错误是只对写操作加锁、读操作裸奔，或者锁粒度太粗（整个函数一把锁）拖慢性能，太细（每行都 lock/unlock）又容易漏锁或死锁。

读写都必须在 mutex.Lock() 和 mutex.Unlock() 之间完成
避免在锁内调用可能阻塞或重入的函数（如另一个带锁函数）
优先使用 defer mu.Unlock()，防止忘记解锁
如果只是读多写少，考虑 sync.RWMutex：多个 goroutine 可并发 RLock()，但写必须独占 Lock()

var mu sync.Mutex
var counter int
func increment() {
mu.Lock()
defer mu.Unlock()
counter++
}

用 `sync/atomic` 替代锁处理简单整数或指针操作

当共享变量只是 int32、int64、uint32、uintptr 或指针，且操作是原子读、写、增减、比较并交换（CAS），sync/atomic 比 Mutex 更轻量、无锁、性能更高。

注意：atomic 不适用于结构体、浮点数（除非转成 uint64 再操作）、或需要多步协调的逻辑（比如“先读再判断再写”这种非原子组合）。

atomic.AddInt64(&x , 1) 是安全的；x++ 不是
atomic.LoadInt64(&x) 和 atomic.StoreInt64(&x, v) 用于读写
atomic.CompareAndSwapInt64(&x, old, new) 是实现无锁队列、状态机的基础
所有 atomic 函数参数必须是指针，且变量必须是导出的（首字母大写）或全局对齐的，否则运行时 panic

var ops uint64
func worker() {
for i := 0; i < 100; i++ {
atomic.AddUint64(&ops, 1)
}
}

用 channel 替代共享内存，让 goroutine 通过通信来同步

Go 的哲学是 “不要通过共享内存来通信，而应通过通信来共享内存”。意思是：与其大家抢着读写一个变量，不如让一个 goroutine 独占该变量，其他 goroutine 通过 channel 发送指令（如 “加1”、“取值”）给它，由它串行处理。

这天然规避了数据竞争，也更易推理。但要注意 channel 容量和阻塞行为——无缓冲 channel 会同步等待收发双方就绪；有缓冲 channel 可能掩盖背压问题。

适合封装状态机、计数器、连接池等有明确 owner 的资源
避免在 select 中对同一 channel 多次收发导致逻辑混乱
记得关闭 channel 并让接收方检测 ok，否则可能死锁或 panic
别把 channel 当作通用消息总线滥用；复杂交互建议用 sync.WaitGroup + 明确生命周期控制

type Counter struct {
    ops chan int64
}
func NewCounter() *Counter {
c := &Counter{ops: make(chan int64)}
go c.run()
return c
}
func (c *Counter) run() {
var total int64
for inc := range c.ops {
total += inc
}
}
func (c *Counter) Inc(n int64) { c.ops <- n }