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

千丽酱_7730

发布时间：2026-01-13 11:03:52

320人浏览过

来源于php中文网

原创

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

如何避免go并发中的数据竞争_go并发安全处理方法

用 `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
<p>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
<p>func worker() {
for i := 0; i < 100; i++ {
atomic.AddUint64(&ops, 1)
}
}

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

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

AI舌诊面诊问诊医疗系统+诊疗商城系统源码

AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。

下载

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

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

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