Go协程泄漏的三种现场与排查思路

Go 协程轻量，但轻量不代表可以随意放任。线上服务跑着跑着内存涨上去、响应变慢，pprof 一抓，goroutine 数量成千上万，多半就是协程泄漏了。所谓泄漏，就是协程启动了却永远无法退出，占着栈空间和堆引用，逐渐把资源耗干。这篇文章整理三种最常见的泄漏现场，以及对应的排查路径。

现场一：channel 发送/接收双方永远等不到对方

这是最经典的泄漏场景。一个协程往 channel 里发数据，但接收者已经退出；或者一个协程等着从 channel 读数据，但发送者永远不来。双方如果没有超时或取消机制，协程就会一直阻塞在那里。

举个例子：

ch := make(chan int)
go func() {
    ch <- 42  // 永远没人接收，goroutine 泄漏
}()
// 主流程继续做别的事，没有接收 ch

更隐蔽的是在业务循环中，每个请求都启动一个协程等待某个 channel，而该 channel 的写入逻辑因为提前 return 或 panic 被跳过了。

排查思路：用 pprof 抓 goroutine，在 runtime/pprof 的输出里找到阻塞在 chan send 或 chan receive 的栈。重点看调用栈的上下文，确认对端协程是否已经不存在。修复手段就是加缓冲、加超时、或者用 context 取消来兜底。推荐使用 select 配合 time.After 或 ctx.Done()，让协程有路可退。

现场二：sync.WaitGroup 计数未归零导致永久等待

不少同学喜欢用 WaitGroup 等一批协程结束，但如果在执行协程前 Add 次数不够，或者协程内部因阻塞没执行 Done，主流程就会一直卡在 Wait() 上。虽然这种不算标准意义上的“协程泄漏”，但同样会造成协程堆积——如果主流程是每来一个请求就起一组协程并 Wait，前一组没结束，后面的请求继续堆积，goroutine 数量自然会飙升。

常见错误是子协程里又起了子协程，却把 WaitGroup 的 Done 放在了外层协程的最后，而外层协程可能因为内层还没完成就提前 Done，导致内层的 Wait 永远等不到。或者是在循环里误用了 go 关键字，把 Add 放在 goroutine 内部执行，结果主流程 Wait 时计数还没加上。

排查思路：抓 goroutine 栈时看到阻塞在 sync.WaitGroup.Wait 的协程，顺着调用栈找到创建 WaitGroup 的位置。检查所有 Done 的分支是否覆盖了提前 return、panic 等情况。更稳妥的做法是在协程入口用 defer wg.Done()，并且确保 Add 在启动协程之前完成。

现场三：锁未释放或 time.Ticker 忘记停止

互斥锁（sync.Mutex）如果加锁后忘了解锁，或者因为某段逻辑 panic 导致 Unlock 没执行，另一个获取锁的协程就会永远阻塞。这虽然不是协程自己启动，但会让持有锁的协程和等待锁的协程一起形成死锁状态，在 pprof 里表现为大量 goroutine 阻塞在 sync.Mutex.Lock。

另外，time.Ticker 也是一个容易忽略的点。如果创建了 Ticker 但从不 Stop，它的 channel 会持续产生事件，关联的协程如果不退出就会一直执行，看起来像活跃泄漏。更常见的是用 for range ticker.C 的协程，外层没有退出条件。

排查思路：pprof 栈上会显示 sync.Mutex.Lock 阻塞，并且能看到当前持锁的 goroutine 是哪个（在 dump 里查找 Mutex 或 Lock 相关的地址）。如果是 panic 导致解锁失败，建议加 defer 来保证解锁。对于 Ticker，凡是 time.NewTicker 的地方都必须有对应的 Stop。可以用 go vet 检查部分问题，但最好的办法是代码审查时建立 checklist。

实战排查建议

以上三种现场，核心工具都是 Go 内置的 pprof。启动服务时引入 net/http/pprof，然后通过 go tool pprof http://localhost:port/debug/pprof/goroutine 获取 dump。用 web 或 tree 视图，找到数量异常大的阻塞栈。

还有一种简单却有效的方式：在测试环境定期输出 goroutine 数量，观察是否有单调递增趋势。如果协程总数只增不减，说明存在泄漏。对于已经泄漏的协程，直接 kill 服务没用，关键是找到泄漏点并修复。建议所有可能阻塞的 channel、锁、WaitGroup 操作都画一个生命周期图，明确每一步谁会唤醒、谁会超时。

协程泄漏没有银弹，但遵守三条原则能避开大部分坑：一是 channel 操作必须明确发送方和接收方的退出条件；二是 mutex 和 WaitGroup 尽量用 defer 保证释放；三是凡是涉及定时器、外部资源，都要考虑关闭或取消。做到这几点，你的 Go 服务至少能在高并发下稳定地呼吸。