Golang并发编程常见错误有哪些_Go语言并发避坑指南_技术教程

goroutine泄漏是最隐蔽危险的并发错误，因channel未关闭、锁未释放或select缺少default/case导致goroutine阻塞等待而无法回收。

最隐蔽也最危险的并发错误。goroutine 启动后若因 channel 未关闭、锁未释放、或 select 中没有 default 或 case ，就可能永远卡住，持续占用内存和 goroutine 调度资源。

常见现象：runtime.ReadMemStats 显示 MNumGoroutine 持续上涨，pprof 查看 /debug/pprof/goroutine?debug=2 发现大量 chan receive 或 semacquire
典型场景：HTTP handler 中启动 goroutine 处理耗时任务，但没绑定 context.Context；或循环中无条件 go fn() 却未控制并发数
修复关键：所有长期运行的 goroutine 必须监听 ctx.Done()；用 sync.WaitGroup 或 errgroup.Group 等待完成；避免在循环里裸写 go func() { ... }()

Go 编译器不禁止多 goroutine 直接读写同一变量，但结果不可预测。即使看起来“偶尔出错”，也是严重 bug —— go run -race 是唯一可靠检测手段。

典型错误：结构体字段被多个 goroutine 同时读写，却没加 sync.Mutex 或用 atomic；map 在并发下读写（哪怕只读+写）
容易忽略点：闭包中引用的局部变量（如 for i := range xs { go func() { use(i) }() }）导致所有 goroutine 共享同一个 i 变量

正确写法：

for i := range xs {
    i := i // 创建新变量
    go func() {
        use(i)
    }()
}

或 go func(i int) { use(i) }(i)

channel 不是万能队列，它的阻塞语义极易引发死锁，而 close 和 nil channel 的行为又常被误用。

死锁高频场景：unbuffered channel 的发送和接收不在同一时刻发生；或所有 goroutine 都在等某个 channel，但没人发/收
panic 风险：close(nil) panic；向已关闭的 channel 发送数据 panic；从已关闭且无数据的 channel 接收返回零值（不 panic），但容易掩盖逻辑错误
建议实践：send-only/recv-only channel 类型明确职责；用 select + default 避免无限阻塞；关闭 channel 应由 sender 单方面负责，receiver 不应 close

sync.Mutex 是最常用同步原语，但它的生命周期和作用域稍有偏差，就会导致竞态或性能瓶颈。

典型错误：把 mutex 当作函数局部变量（每次调用都新建），完全起不到保护作用；或在方法中对指针 receiver 加锁，但调用方传的是值拷贝
锁粒度陷阱：整个函数体用一个 mutex 包裹，把本可并行的操作串行化；尤其在 HTTP handler 中，会显著降低 QPS
安全习惯：mutex 字段必须导出为 mu sync.Mutex（小写首字母），且结构体必须以指针形式传递；读多写少场景优先考虑 sync.RWMutex；避免在锁内做 I/O、网络调用或长耗时计算