Go 1.27 goroutineleak 怎么看：能发现什么，为什么全局可达对象仍可能漏检

服务运行一段时间后，goroutine 数量不再回落，最容易出现的误判是“所有多出来的 goroutine 都泄漏了”。Go 1.27 给出了一个更窄、更有用的检查入口：runtime/pprof 中正式提供 goroutineleak profile，用运行时的可达性关系寻找那些已经不可能被唤醒的阻塞 goroutine。

goroutineleak 适合做泄漏线索筛选，不是全量替代 goroutine dump 的万能判定器。它最擅长发现阻塞原语已经与可运行 goroutine 断开联系的情况；如果阻塞对象仍被全局变量或某个可运行 goroutine 持有，运行时可能有意漏报。

先分清 goroutine 数量上涨和真正泄漏

普通 goroutine profile 展示的是当前所有 goroutine；goroutineleak 只展示运行时认为已经永久阻塞的一部分。前者回答“现在有哪些栈”，后者回答“哪些栈可能永远等不到下一次唤醒”。两者不是同一份数据，也不能用数量差直接当作泄漏数量。

例如，一个消息消费者在等待下一条消息时长期处于阻塞状态，只要 channel 仍会被生产者使用，它就是正常等待；一个请求结束后遗留的 goroutine 永久等一个没人再发送的 channel，才符合这项 profile 试图识别的对象。排查时先记录业务生命周期，再看 profile 的栈，避免把长轮询、连接复用和后台 worker 误杀成泄漏。

goroutineleak 的判断依据是什么

Go 1.27 的官方说明把判断建立在垃圾回收可达性上：假设 goroutine G 阻塞在并发原语 P 上，如果 P 已经无法从任何可运行 goroutine，或从这些 goroutine 能够解除阻塞的对象继续到达，那么 P 不可能被唤醒，G 就属于可报告的泄漏候选。

这个模型的价值在于它不靠“运行了几分钟”这种经验阈值，而是尝试判断阻塞关系是否已经断开。但它也有明确边界：运行时不可能仅凭当前快照证明所有永久阻塞场景，尤其是并发原语仍被全局对象或可运行 goroutine 保存时。

用 runtime/pprof 采集一份本地快照

如果服务没有暴露 pprof HTTP 端点，可以在诊断命令或维护入口中直接查找 profile。关键是先判断 profile 是否存在，再把结果写到文件；不要把它当成业务日志长期高频输出。

package main

import (
    "fmt"
    "log"
    "os"
    "runtime/pprof"
)

func writeLeakProfile(path string) error {
    profile := pprof.Lookup("goroutineleak")
    if profile == nil {
        return fmt.Errorf("goroutineleak profile is unavailable")
    }

    file, err := os.Create(path)
    if err != nil {
        return err
    }
    defer file.Close()
    return profile.WriteTo(file, 2)
}

func main() {
    if err := writeLeakProfile("goroutineleak.txt"); err != nil {
        log.Fatal(err)
    }
}

这里特意保留了“profile 不存在”的分支，便于旧 Go 版本或不具备该能力的构建环境明确失败。WriteTo 的调试级别决定输出形式，级别 2 适合人读，但它仍然只是某一时刻的诊断快照。

接入 net/http/pprof 后怎么读端点

HTTP 服务可以通过匿名导入 net/http/pprof 注册标准 pprof 路由。Go 1.27 的 release notes 明确列出 /debug/pprof/goroutineleak，排查时可把它与普通 goroutine 端点并列保存，比较同一时间窗口里的栈。

import (
    _ "net/http/pprof"
    "net/http"
)

func startDebugServer() error {
    return http.ListenAndServe("127.0.0.1:6060", nil)
}

采集顺序建议固定为：先保存 /debug/pprof/goroutine，再保存 /debug/pprof/goroutineleak，最后回到业务日志核对请求、任务或连接是否已经结束。调试端口应限制在本机或受控网络，不要为了方便直接暴露到公网。

为什么全局可达对象会造成漏检

假设一个 goroutine 阻塞在 channel 接收上，而这个 channel 被全局变量保存。即使业务上已经没有任何发送者，垃圾回收仍能从全局根找到这个 channel。按照可达性模型，运行时不能据此断言它“永远不可能被唤醒”，所以 goroutineleak 可能不报告它。

类似地，某个可运行 goroutine 的局部变量仍持有锁、条件变量或 channel 时，运行时也可能认为未来存在解除阻塞的路径。这不是 profile 出错，而是它选择了较少误报的证明标准。此时应该把 profile 当作高价值线索，而不是“空结果就安全”的证明。

把 profile 结果变成修复动作

拿到栈之后，先按阻塞点分组：channel 接收要找关闭或发送责任，sync.Mutex 要找持锁路径和退出分支，sync.Cond 要找等待条件是否存在终止信号。接着把每个 goroutine 绑定回请求、队列任务或组件生命周期，确认它应该在何时退出。

修复通常不是“加一个超时”这么简单。对请求协程，应把 context.Context 传到阻塞调用；对 worker，应定义停止信号和等待回收顺序；对长期后台服务，则要确认它本来就不应退出。完成改动后同时保留普通 goroutine 快照和 leak profile，观察创建量、退出量与业务结束事件是否重新对齐。

常见误区与核对清单

• 把 goroutineleak 当成 Go 1.27 的“泄漏计数器”：它报告的是一类可由可达性证明的阻塞栈。
• 只看空结果：全局根和可运行 goroutine 持有的并发原语可能导致漏报。
• 只采集一次：一次快照无法说明生命周期，至少要和请求结束、任务停止等业务事件对应。
• 公开调试端口：pprof 含有栈和运行时信息，应限制监听地址并按内部诊断流程访问。

相关问答

Go 1.26 能直接使用 goroutineleak 吗？

该能力在 Go 1.26 还是实验性能力，Go 1.27 才正式可用。跨版本工具链应先检查 profile 是否存在，再决定是否采集。

goroutineleak 和 goroutine profile 有什么区别？

goroutine 展示当前所有 goroutine；goroutineleak 聚焦运行时判断为永久阻塞的一类对象。排查应两者一起看。

profile 为空是不是说明没有协程泄漏？

不是。全局可达对象、可运行持有者和无法被运行时证明的阻塞关系都可能漏报，仍需结合普通栈、代码生命周期和业务日志判断。

Go 1.27 的 goroutineleak 更像一盏筛选灯：它把最值得先看的永久阻塞候选标出来，但不会替你完成生命周期设计。把它接入受控诊断入口，再用普通 profile 和业务事件补齐证据，排查结果才可靠。