Go goroutine 泄漏剖析怎么按创建栈聚合

Go goroutine 泄漏剖析要按“创建栈”聚合，入口不是普通的 goroutine profile，而是 Go 1.27 提供的 goroutineleak profile。先用 top 看哪些调用栈积累了最多泄漏样本，再用 list 下钻到发送、接收或锁等待的源码行；最后回到退出路径，检查谁负责关闭 channel、结束 worker 或传递取消信号。

一、先确认“泄漏”真的属于可聚合范围

一个 goroutine 只要还可能被唤醒，就不能仅凭数量上升判定为泄漏。适合本方法的典型场景是：worker 永久等不到 channel 消息，发送方在接收方提前返回后卡在无缓冲 channel，或者启动后台循环却没有对应的停止动作。它们最终会在相同的阻塞调用栈上聚合。

Go 官方的 goroutine leak profiler 使用运行时可达关系判断存活状态，因此能过滤掉一部分“暂时被大量流量挡住”的正常 goroutine。但它不负责判断网络读取、文件 IO、自旋锁等非目标阻塞；这类现象需要结合 trace、业务指标和常规 goroutine profile 复核。

二、从 pprof 端点采集可分析的泄漏样本

服务已经注册 net/http/pprof 时，泄漏 profile 会出现在同一诊断地址的 /debug/pprof/goroutineleak。生产环境应把诊断端口放在受控网络中，下面命令只描述采集动作，不代表本文已经在你的机器上执行。

# 只从受控的 pprof 地址保存泄漏 profile，文件名便于区分采样时间
curl --fail --silent http://127.0.0.1:6060/debug/pprof/goroutineleak -o goroutine-leak.prof

# 进入交互式分析器，profile 类型会保留为 goroutineleak
go tool pprof goroutine-leak.prof

如果项目尚未引入 pprof，可在只监听诊断地址的进程中导入 net/http/pprof；不要把调试处理器无意暴露到公网。采集时至少保留一次原始 profile，后续修复前后用相同入口复采，才能比较聚合桶是否下降。

三、用 top 聚合创建栈，再用 list 定位阻塞行

进入 pprof 后，先看总量最大的栈，再挑一个函数名展开。聚合关注的是“同一调用栈出现了多少泄漏样本”，不是把每个 goroutine 当成一个独立事故。

(pprof) top
Showing nodes accounting for 116, 100% of 116 total
      flat  flat%   sum%        cum   cum%
       116 100.0% 100.0%        116 100.0%  main.runBatch.func2

(pprof) list runBatch
ROUTINE ======================== main.runBatch.func2
       116        116 (flat, cum) 100% of Total
         .        116     resultCh 

这里的 116 只是说明聚合计数：它提示多个 goroutine 在同一个发送点等待。接着沿着 runBatch 的错误返回、超时分支和接收循环检查：接收方是否提前结束？channel 是否应该有有限缓冲？是否缺少关闭或取消？不要只把 channel 改成大缓冲，先确认消息是否必须送达以及缓冲上限是否可控。

四、修复生命周期后用同一聚合口径复采

修复方向取决于栈底的生命周期。接收方可能提前返回时，让发送动作具备可完成的出口；worker 按 range ch 工作时，由拥有发送端的一方在结束输入后关闭 channel；后台 worker 则提供明确的 Stop 或取消路径。修复后不要只看总 goroutine 数，重新采集 goroutineleak，比较原来最大的创建栈聚合桶是否消失或持续下降。

常见问题

普通 goroutine profile 能按创建栈聚合吗？

能按调用栈统计数量，但它无法直接区分“设计上暂时阻塞”和“永远无法解除”的 goroutine；需要把聚合结果与生命周期证据结合起来。

为什么采不到 goroutineleak？

先确认运行时和工具链支持该 profile，并确认 pprof 处理器挂载在你访问的诊断地址；如果阻塞发生在网络、文件 IO 或自定义同步机制上，它本来就可能不在该 profile 的检测范围。

聚合数量下降就代表问题彻底修好了吗？

不一定。还要在重复触发、超时和错误返回路径下复采，并检查是否出现新的聚合栈；数量变化只能证明这次样本减少。

参考入口：https://go.dev/blog/goroutine-leak-profiles；命令和图示用于说明分析方法，不能替代对实际服务生命周期的验证。