Go goroutineleak 为什么看不到仍可运行的 goroutine

如果你在 Go 里看到 goroutine 数量持续上涨，却发现 goroutineleak profile 里没有对应条目，通常不是工具失效，而是两者统计的对象不同：runtime.NumGoroutine() 统计当前存在的全部 goroutine；goroutineleak 只关注已经阻塞，并且阻塞条件永远不会被满足的那一部分。

仍可运行的 goroutine 在泄漏分析中会先被视为存活对象，所以不会因为“未来可能卡住”而提前进入 goroutineleak。要定位问题，应把数量趋势、普通 goroutine 堆栈和泄漏 profile 放在一起看。

本文只讨论“阻塞泄漏”和“仍可运行 goroutine”的区别，不把普通 goroutine 数量上涨直接等同于泄漏。

goroutineleak 看的不是 goroutine 总数

Go 官方对 goroutine 泄漏的描述很具体：一个 goroutine 已经阻塞，而且解除它所需的条件永远不会发生。例如发送方等待无人接收的 channel，或者消费者提前返回后，生产者还在等待发送完成。goroutine 本身不会被垃圾回收，持续堆积会占用运行时资源，并让它引用的数据继续存活。

因此，下面三件事不能混为一谈：

• 存在：runtime.NumGoroutine() 返回当前存在的 goroutine 数量，包含正在运行、等待调度和阻塞中的对象。
• 暂时阻塞：goroutine 可能正在等待一个稍后会到来的消息、锁或任务，这本身还不能证明泄漏。
• 严格泄漏：goroutine 已经阻塞，而且没有任何未来事件能让它继续执行，这才是 goroutineleak 要筛出的对象。

为什么仍可运行的 goroutine 不会被列出来

泄漏 profile 的核心判定可以概括为：没有被并发原语阻塞的 goroutine，天然被视为存活；如果一个阻塞 goroutine 等待的 channel、锁或其他 sync 原语仍能从存活 goroutine 的引用中到达，它也可能被视为仍有解除机会。

这解释了“仍可运行”这个现象。profile 不能预测一个 goroutine 将来会不会进入错误分支，也不能把“现在正在运行”解释成“已经永久泄漏”。只要它当前未阻塞，就属于存活判定的起点。即使它下一秒可能因为业务条件卡住，也要等到实际阻塞并满足泄漏判定后才可能被捕获。

反过来，一个普通 goroutine profile 往往会包含更多对象：它可以帮助你查看当前所有 goroutine 的堆栈，但不会自动告诉你哪些只是高并发下的暂时等待。两种 profile 的差异，正是“总量观察”和“严格泄漏定位”的差异。

用三个观察面排查数量上涨

排查时可以按下面的顺序理解证据，而不是只看一个数字：

1. 先看总量趋势。把 runtime.NumGoroutine() 当作规模信号，观察请求量相近时数量是否仍单调增加。它只回答“有多少”，不回答“为什么没有退出”。
2. 再看普通 goroutine profile。用堆栈分组找出大量 goroutine 当前停在哪个 channel、锁或函数调用处。普通 profile 既可能包含暂时等待，也可能包含真正泄漏。
3. 最后看 goroutineleak。它用于缩小范围，确认哪些阻塞点已经被判定为严格泄漏。若这里为空，不代表系统没有问题，只代表当前没有命中这个 profile 的覆盖条件。

package main

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

func writeGoroutineProfiles() error {
    // NumGoroutine 只记录当前总数，不能单独证明存在泄漏。
    total := runtime.NumGoroutine()
    _ = total

    // 普通 profile 便于查看所有 goroutine 的堆栈，debug=2 保留完整栈形态。
    all, err := os.Create("goroutines.txt")
    if err != nil {
        return err
    }
    defer all.Close() // 文件句柄必须在函数返回时释放。
    if err := pprof.Lookup("goroutine").WriteTo(all, 2); err != nil {
        return err
    }

    // goroutineleak 只输出运行时已经判定为严格泄漏的子集。
    leak, err := os.Create("goroutine-leaks.txt")
    if err != nil {
        return err
    }
    defer leak.Close() // 保证泄漏 profile 文件也会关闭。
    return pprof.Lookup("goroutineleak").WriteTo(leak, 2)
}

上面是采集逻辑示意，不把文件内容当作本机运行结果。官方 runtime/pprof 文档说明，WriteTo 会写出 profile 快照；对预定义的 goroutine profile，debug=2 可输出接近程序 panic 时的完整堆栈形态。

提前返回时，怎样避免发送方变成泄漏

最常见的根因是消费者提前返回，但生产者仍向无缓冲 channel 发送。修复重点不是让 profile “显示出更多”，而是让发送方在消费者离开后拥有明确的退出路径。

func process(ctx context.Context, items []int) error {
    // 缓冲容量覆盖一次调用创建的发送者，避免提前返回时无人接收。
    results := make(chan result, len(items))
    for _, item := range items {
        go func(item int) {
            value, err := work(item)
            select {
            case results 

如果结果数量不适合一次性缓冲，就用 context.Context 或关闭的 done channel 广播取消，并让每个发送点都通过 select 响应取消。Go 官方的 pipeline 文章把“下游提前停止、上游发送永久阻塞”列为典型资源泄漏，并建议让上游收到取消信号后退出。

哪些情况不能只依赖 goroutineleak

这个 profile 有意保持严格，因此空结果不等于空风险：

• 它重点覆盖 channel 操作、阻塞式 select 以及 sync.Mutex、RWMutex、WaitGroup、Cond 等原语的永久阻塞。
• 卡在网络 I/O、文件 I/O 或直接系统调用上的 goroutine，不属于它能严格判断的全部范围；应结合普通堆栈、超时和资源指标分析。
• 如果同步原语一直能从全局变量或仍可运行的 goroutine 到达，泄漏判断可能认为它仍有潜在解除路径，因此不报告。
• 数量上涨也可能只是流量增加造成的暂时等待。要把采样时间、请求量、堆栈位置和退出路径放在同一个时间窗口里比较。

官方资料：https://go.dev/blog/goroutine-leak-profiles；pipeline 取消模式：https://go.dev/blog/pipelines；运行时数量 API：https://pkg.go.dev/runtime#NumGoroutine；profile API：https://pkg.go.dev/runtime/pprof。

常见追问

goroutine 数量持续增加，就一定是泄漏吗？

不一定。先看是否有稳定的退出延迟、堆栈是否长期停在同一阻塞点，再用 goroutineleak 判断是否命中严格泄漏范围。

为什么普通 goroutine profile 有内容，goroutineleak 却为空？

普通 profile 展示的是当前 goroutine 堆栈，范围更宽；泄漏 profile 只保留已经阻塞且运行时判断没有解除路径的对象，二者为空与否不需要一致。