Go 1.27 的 goroutine leak profile 适合怎样的排查场景

如果线上 Go 服务的 goroutine 数量只在某些请求或故障路径后持续上涨，Go 1.27 的 goroutineleak profile 值得优先尝试。它不是“运行多久都能找出所有泄漏”的扫描器，而是利用运行时和垃圾回收器的可达性，找出一类已经不可能被唤醒的阻塞协程。

goroutineleak 最适合排查“协程卡在 channel、锁或条件变量上，而负责解除阻塞的对象已经脱离可达对象图”的场景；临时等待、仍被全局对象持有的同步原语，以及纯 CPU 死循环，不应直接按泄漏处理。

先看它到底识别什么

Go 1.27 发布说明明确把 goroutineleak 列为正式能力，并在 net/http/pprof 中提供 /debug/pprof/goroutineleak。在 runtime/pprof 里，它和几个容易混淆的 profile 分工不同：goroutine 是当前所有协程，block 记录同步原语上的阻塞时间，而 goroutineleak 只报告运行时判断为“无法再唤醒”的那一类。

判断的关键不是等待了几秒，而是对象关系。假设协程 G 阻塞在 channel、sync.Mutex 或 sync.Cond 上，如果这个并发原语已经无法从任何可运行协程及其可解除阻塞的协程继续抵达，那么 G 没有重新运行的路径，运行时就可以把它列为泄漏候选。

需要注意，官方也把边界说得很清楚：这种基于可达性的办法覆盖面很大，却不可能识别所有永久阻塞。如果同步原语仍由全局变量或某个可运行协程的局部变量保持可达，profile 可能不会把它列出来。

适合排查哪些场景

第一类是请求结束后仍不断增长的后台协程。例如每次请求都启动一个 worker，但请求取消时没有关闭任务输入 channel；当 worker 又没有其他持有者能够发送或关闭它时，就可能形成这类候选。第二类是故障分支里的孤儿等待：正常路径会唤醒消费者，超时或错误路径却丢掉了负责发送结果的对象。

第三类是服务重载、连接断开或任务移交之后，协程仍卡在锁或条件变量上。此时 profile 能帮你把“总数变多”的现象缩小到具体阻塞堆栈，再回到创建它的代码确认生命周期。

相反，短暂的队列拥堵不等于泄漏；有生产者、有超时、有明确的恢复条件时，协程只是暂时阻塞。纯 CPU 忙循环也不属于这个 profile 的目标，应该转向 CPU profile 或 trace。把“当前很忙”和“不可能醒来”分开，是使用新 profile 的第一道门槛。

怎样把 profile 放进排查流程

如果服务已经有受保护的 pprof 入口，可以直接读取新端点。自建诊断入口时，通常只需要导入 net/http/pprof 并把它绑定到内部地址；不要把未鉴权的 profile 端口暴露到公网。

package main

import (
    "log"
    "net/http"
    _ "net/http/pprof" // 注册 /debug/pprof/ 下的诊断处理器
)

func main() {
    mux := http.NewServeMux()
    mux.Handle("/debug/pprof/", http.DefaultServeMux) // 只把诊断路由挂到内部服务

    // 监听内网地址，生产环境还应叠加鉴权和访问控制。
    if err := http.ListenAndServe("127.0.0.1:6060", mux); err != nil {
        log.Fatal(err)
    }
}

诊断时可以先取文本结果，快速确认有没有候选堆栈；也可以从程序内通过 pprof.Lookup("goroutineleak") 写出 profile。第一次采集建议记录时间、请求负载和 goroutine 总量，之后在相同负载下复采，避免把一次性启动任务误判为泄漏。

拿堆栈回到所有权、取消和清理路径

profile 给的是证据入口，不是修复清单。看到堆栈后，沿着四个问题复查：这条协程由谁创建和负责结束？它等待的 channel、锁或条件变量由谁持有？请求或任务取消时，哪个分支应该让它退出？退出前需要释放哪些 ticker、连接、锁或引用？

如果堆栈落在消费循环，优先检查输入 channel 的关闭责任和 context.Context 的取消分支；如果落在锁等待，检查持锁方是否在错误返回前解锁；如果落在条件变量，检查等待条件是否有明确的广播或超时。修复后不要只看 profile 数量归零，还要确认正常请求、超时请求和异常返回都能走完清理路径。

相关问题

goroutineleak 能替代普通 goroutine profile 吗？

不能。普通 profile 适合先看全量协程和调用栈，leak profile 适合缩小到运行时判定无法唤醒的子集，两者应该配合使用。

为什么明确卡住的协程没有出现在结果里？

最常见的原因是阻塞原语仍然可达，或者它属于暂时等待、外部 I/O、纯 CPU 循环等不在该算法覆盖范围内的情况。回到全量堆栈和业务生命周期继续查。

升级 Go 1.27 后需要改业务代码吗？

只为获得这个 profile 通常不需要改业务代码，但要升级运行时并接入或保护 pprof 入口。真正的修复仍需补齐取消、关闭、解锁和清理路径。

总结

Go 1.27 的 goroutine leak profile 把一类过去需要人工从全量堆栈中筛选的并发问题，变成了更容易观察的诊断信号。它最适合处理“阻塞原语已失去可达唤醒路径”的协程泄漏；面对全局引用、临时拥堵、外部 I/O 或 CPU 忙循环时，仍要换用其他 profile 和 trace。把新能力接入监控只是开始，沿堆栈确认所有权、取消和清理责任，才是排查真正闭环。