Golang 并发常见问题：死锁、竞态与 Goroutine 泄漏-Golang-PHP中文网

Go并发三大问题：死锁（channel收发不匹配、mutex重复锁定）、竞态（共享变量未同步）、Goroutine泄漏（协程永久阻塞）。需用context、锁、race检测等工具预防。

golang 并发常见问题：死锁、竞态与 goroutine 泄漏 - php中文网

Go 并发问题最常卡在三类现象上：程序停住不动（死锁）、结果每次都不一样（竞态）、服务跑着跑着就变慢甚至 OOM（Goroutine 泄漏）。它们不总在本地复现，但线上一出就是大问题。关键不是“能不能写出来”，而是“写完后是否真能安全退出、正确同步、及时释放”。

死锁：不是卡在代码里，是卡在逻辑配对上

Go 的死锁提示很明确：fatal error: all goroutines are asleep - deadlock!。但它不告诉你哪条 channel 没人接、哪把锁被谁锁死了。核心原因就两个：

无缓冲 channel 的收发没“碰上”——一方发，另一方还没启或已退出；一方收，发送端根本没动或已关闭
sync.Mutex 被同个 goroutine 重复 Lock，且没 unlock（比如 defer 写错位置、递归调用持锁）
select 等待多个 channel，所有 case 都阻塞，又没 default 或 ctx.Done() 保底，整个 goroutine 就挂在那里

修复思路不是加更多锁，而是检查“谁负责发、谁负责收、谁负责关、谁负责解锁”。例如启动 goroutine 做接收前，确保发送逻辑已就绪；用 ctx.Done() 替代纯 channel 等待；给 mutex 加锁范围严格限定在临界区，defer mu.Unlock() 必须紧跟 mu.Lock() 后。

竞态条件：共享变量没保护，读写就乱套

多个 goroutine 同时读写一个变量，且至少有一个写操作，行为就不可预测。编译器不会报错，go run -race 也未必每次触发，但压测时极易暴露。

全局变量、结构体字段、闭包捕获的循环变量（如 for i := range items { go func(){ println(i) }() } 总输出最后一个值）都算共享数据
map 和 slice 本身非并发安全，即使只读写各自索引，也要加锁或改用 sync.Map
别依赖“我只读它，应该没事”——只要有人写，所有读就必须同步

标准解法是显式同步：读写共用变量必须用 sync.Mutex 或 sync.RWMutex 包裹；高频读低频写的场景可考虑 sync.Once 或原子操作 atomic. 系列。

Golang Uber Dig

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

下载

Goroutine 泄漏：看不见的资源黑洞

泄漏的 goroutine 不会 panic，也不会立刻报错，只是永远卡在某处：等一个永远不会来的 channel 消息、拿不到锁、或没监听 ctx.Done() 就进了无限循环。几小时后可能吃光内存。

HTTP handler 中启 goroutine 处理异步任务，但没绑定 request context，请求取消后协程还在跑
for-select 循环里只等 channel，channel 关了却没检查 ok，导致继续空转
sync.WaitGroup 的 Add() 写在 goroutine 启动后，或 Done() 因 panic 没执行到

验证方式很直接：访问 /debug/pprof/goroutine?debug=2 查看堆栈，重点关注长期停在 chan receive、select 或 semacquire 的协程；上线前用 runtime.NumGoroutine() 打点监控，看数量是否随请求稳定或持续上涨。