Go 1.26 的 goroutineleak profile 值得先试吗：协程泄漏排查多了一个官方入口

Go 1.26 的发布说明里有个热度不高、但常年扛线上Go服务的后端团队看了会觉得很实用的更新：运行时新增了实验性的 goroutineleak profile。它不是要替代现有的 goroutine dump，也不会让协程泄漏问题自动消失，而是给「协程数量持续上涨、接口偶尔卡住、排查时抓不到现场」这类折腾人好久的老问题，多开了一个官方做的专用采样入口。

变化没怎么大肆宣传，刚好戳中Go服务跑了很多年的老痛点

不少线上Go服务出现协程泄漏的时候，最早的信号根本不是直接炸掉崩溃，而是 runtime.NumGoroutine() 数值慢慢往上飘，接口延迟毛刺变多，连接池或者队列消费开始时不时抽风。值班的同学第一反应基本都是先抓个goroutine profile，对着成百上千段调用栈翻来覆去找重复的相似模式，特别耗时间。

Go 1.26 这次把 goroutineleak 放进正式发布说明，并不是说“以后协程泄漏排查点一下就完事”，而是把这类长期挂着不动的协程问题，单独放到更明确的诊断入口里。对常年维护线上 Go 服务的开发来说，这种改动比单纯的语法小优化更贴近日常排障。

为什么这次改动值得工程团队抽点时间瞅一眼

协程泄漏难排查，从来不是缺工具，而是相关证据散在各个地方凑不到一起。监控能提醒你goroutine数量在涨，日志能告诉你某个接口反应变慢，普通的goroutine dump能导出一大堆栈信息，但这些信息中间往往就差了一层判断：到底哪一批协程最有可能是泄漏出来的僵死协程？

goroutineleak 的价值就在这儿：它直接把泄漏排查的视角从普通的全量栈快照里单独拆了出来，大家完全可以在现有的排障流程里多塞一个观察点。尤其是网关、任务调度、消费队列、长连接这类服务，平时跑的好好的，哪天上游处理慢了点或者下游卡了没响应，一堆没来得及退出的协程就会悄咪咪堆起来，时间长了直接堆爆内存。

旧代码不会因为出了这个新profile就自动变安全

这类新的profile能力再好用，也只能帮你更快找到问题，没法替你把协程生命周期设计的漏洞给补上。大家踩过无数次的泄漏场景还是那几样：启动协程的时候压根没想着加退出信号，循环里等一个永远没人往里面写也没人关闭的channel，请求超时了下游开的协程还在傻乎乎等结果占着资源。

如果你的项目已经有健全的健康检查、受控的pprof入口和基础监控，Go 1.26这次加的能力完全可以当一个不错的补充；要是你的项目连统一的 context 传递规则、超时预算配置和协程退出流程都没做，先把基础工程约束补上，比急着换用新工具优先级高多了。

func startWorker(ctx context.Context, jobs 

上面这段代码没什么花里胡哨的技巧，核心就只是把协程的退出条件写得明明白白。排查工具顶多能帮你定位到“哪里的协程没正常退出”，但真正把泄漏问题根治的，永远是每一条协程执行路径都有清晰的生命周期管控逻辑。

灰度接入的时候别上来就把结论拍死

因为 goroutineleak 在 Go 1.26 里还属于实验性能力，团队接入的时候最好把它当成排查辅助工具，别上来就当成强依赖核心组件。比较稳妥的玩法是先在预发环境、压测集群或者一小部分灰度节点上开着观察，慢慢摸清楚它和你现在用的其他profile、日志、trace数据之间的对应关系。

• 先确认服务已经做好了pprof入口的权限管控，绝对不能把调试接口直接裸露在公网。
• 压测的时候故意构造一个永远不会退出的测试worker，试试这个新的profile能不能给出靠谱的有效线索。
• 拿到采样结果之后配着日志里的请求ID、任务ID、版本号一起对照着看，别光凭一张profile截图就直接上线改代码。
• 如果返回的结果和普通goroutine profile差得特别多，先把现场完整保留下来，再回头写最小复现用例验证情况。

最小验证完全可以从写个泄漏的小demo开始

想知道这个新能力对你自己的项目有没有实际帮助，完全不用一上来就往生产环境堆。随便写个几行代码的小内部demo就行：启动几个永远卡在等待里的goroutine，再启动几个跑几秒就正常退出的goroutine，然后分别对比普通goroutine profile和 goroutineleak 给出的信息差异。

这个小实验根本不用搞什么复杂场景，核心是让团队里的相关同学先练熟判断三件事：哪些栈是本来就该长期驻留的正常协程，哪些栈看起来就像是泄漏出来的僵死协程，哪些栈必须配着业务上下文日志才能下结论。把这一步摸透了，后面把它加进值班排查手册里，才不会出现“一看到这个新profile的输出就慌神瞎操作”的情况。

相关问题

Go 1.26 的 goroutineleak profile 可以替代普通 goroutine profile 吗？

不建议直接替换。普通goroutine profile还是全局调用栈的完整视角，goroutineleak 只是更适合从泄漏的角度补一条关键线索，排查的时候两个对着看反而更稳。

线上服务要不要立刻打开这个能力？

更推荐先灰度试水。尤其是调试入口权限、采样性能开销、采样数据留存规则这些点先提前捋顺，别为了试一个新profile就把pprof的暴露面搞大了，引入不必要的安全风险。

协程数量上涨一定是泄漏吗？

不一定。突发大流量、临时批处理任务、长连接保持、后台数据同步这类场景，都可能让协程数量短时间内往上冲。判断是不是泄漏核心看数值会不会长期不回落，以及调用栈里是不是反复出现同一类等待点。

Go 项目预防协程泄漏最有效的习惯是什么？

每个goroutine刚启动的时候就把退出条件想清楚：谁负责取消任务、谁负责关闭channel、下游响应慢了怎么设超时、服务停机的时候怎么收尾回收资源。工具负责帮你快速发现线索，前期把协程生命周期设计做好，才是从根上减少这类问题的办法。

Go 1.26这次的改动，当然没把协程泄漏排障变成点一下就搞定的自动驾驶，但它确实把协程泄漏这个大家碰到好多年的老问题，放到了更方便定位的明确诊断位置。对常年扛线上Go服务的团队来说，完全可以在下一轮压测或者灰度环境里跑一下试试，看看它能不能帮大家少翻成百上千段没用的调用栈，省点值班排障的时间。