Go协程泄漏排查方法及定位技巧

本篇文章给大家分享《Go协程泄漏怎么排查？Golang并发问题定位指南》，覆盖了Golang的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

runtime.NumGoroutine() 持续上涨是协程泄漏最直接信号，需排除初始化波动，重点观察请求后不回落或长期单调上升趋势；结合 pprof/goroutine 快照对比定位新增阻塞协程，辅以 goleak 在测试阶段拦截泄漏。

用 runtime.NumGoroutine() 快速确认是否真泄漏

协程数持续上涨是泄漏最直接的信号，但得先排除“正常波动”。比如 HTTP 服务刚启动时协程数可能跳到 100+，这是 pprof、日志、健康检查等后台 goroutine 在初始化，不是泄漏。

真正要盯的是：单次请求处理完后，总数不回落；或服务稳定运行几小时后，数字呈单调斜线上升（如从 50 → 200 → 800）。

• 在关键路径（如 HTTP handler 入口和出口）加一行：log.Printf("goroutines: %d", runtime.NumGoroutine())
• 别只看一次——至少打 3 组时间点日志（空闲态、压测中、压测后 30 秒），才能判断趋势
• 注意：runtime.NumGoroutine() 返回的是当前存活的 goroutine 总数，包括已阻塞、已休眠、正在运行的，所以它不能告诉你“哪里卡住”，只负责回答“是不是在涨”

用 /debug/pprof/goroutine?debug=1 抓堆栈定位阻塞点

确认数量异常后，下一步是看“谁没退”，而不是猜。pprof 的 goroutine profile 是生产环境唯一可靠的一手信息源。

• 确保导入了：import _ "net/http/pprof"，并启用了调试服务（如 go func() { http.ListenAndServe("localhost:6060", nil) }()）
• 访问 http://localhost:6060/debug/pprof/goroutine?debug=1，你会看到所有 goroutine 的完整调用栈，按状态分组（running、chan receive、select、sleep 等）
• 重点关注处于 chan receive 或 select 且没有超时分支的 goroutine——它们大概率在等永远不会来的信号
• 别只扫一眼：把页面内容保存为文本，用 grep -A5 -B2 "your/pkg/name" 锁定业务代码位置

对比两次快照，精准识别新增泄漏 goroutine

很多泄漏是“缓慢积累”的，单次快照里混着大量正常长期运行的 goroutine（比如 ticker、日志 flusher），靠肉眼很难分辨哪些是新长出来的。

• 第一次采集（系统空闲时）：curl "http://localhost:6060/debug/pprof/goroutine?debug=1" > before.txt
• 执行可疑操作（如调用某个 API 10 次）后，立即第二次采集：curl "http://localhost:6060/debug/pprof/goroutine?debug=1" > after.txt
• 用 diff before.txt after.txt | grep "^+" | grep -E "(chan receive|select|sleep)" 过滤出新增且阻塞的 goroutine
• 这些新增项的调用栈顶部，基本就是泄漏源头——比如显示 myapp/handler.go:42 和 net/http/transport.go:1293，就该立刻检查 resp.Body 是否 close

测试阶段用 goleak.VerifyNone(t) 拦截泄漏于开发早期

线上才发现泄漏，说明测试环节漏掉了。goleak 是目前最轻量、最准的单元测试级检测工具，它不依赖运行时环境，也不需要你手动比对快照。

• 在 TestMain 中加入：goleak.VerifyNone(t)，它会在所有测试跑完后自动检查是否有 goroutine 残留
• 一旦失败，错误信息直接给出泄漏 goroutine 的启动栈，例如：leaky_test.go:27: goroutine leak: goroutine 12 [chan receive]
• 注意两个常见误报点：未关闭的 http.DefaultClient 连接池（需在测试后调用 http.DefaultTransport.(*http.Transport).CloseIdleConnections()）、或测试中启用了未 stop 的 time.Ticker
• 它不检测“逻辑上该退但还没退”的情况（比如 context 超时设得太长），只抓“彻底卡死、永远无法退出”的 goroutine

真正难的不是发现泄漏，而是区分“设计如此的长期 goroutine”和“本该退出却卡住的泄漏”。比如一个常驻的 metrics collector 是合理的，但同一个函数里多启了一个没传 context 的 for-select 就是 bug。每次看到新增阻塞 goroutine，先问一句：它的退出条件是什么？那个条件，在当前代码路径下，有没有可能永远不满足？

理论要掌握，实操不能落！以上关于《Go协程泄漏排查方法及定位技巧》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！