Go 怎么用泄漏剖析区分阻塞和长期存活的 goroutine

排查 Go goroutine 数量持续上升时，不能看到“阻塞”二字就直接判定泄漏。更可靠的做法是把两个问题拆开：先看完整的 goroutine profile 了解当前都卡在哪里，再用 Go 1.27 提供的 goroutineleak profile 筛出运行时判断为“永远无法唤醒”的那一部分。前者回答“谁在等”，后者回答“谁已经没有可达的唤醒路径”。

判断标准：如果 goroutine 阻塞在 channel 或受支持的 sync 原语上，并且该原语已经不可能被仍然存活的 goroutine 触达，它才是泄漏候选；有明确退出条件、仍被业务引用的常驻 worker 属于长期存活，不应因为栈状态是 waiting 就误杀。

先同时打开全量和泄漏 profile

服务中引入标准库的 pprof handler 后，Go 会在同一个端口提供 profile。下面的示例只用于说明接入关系，监听地址应放在受控网络或鉴权入口之后，不要把调试端口直接暴露给公网。

package main

import (
    "log"
    "net/http"
    _ "net/http/pprof" // 注册标准 pprof 路由，包括 goroutineleak
)

func main() {
    go func() {
        // 独立调试端口只绑定本机，避免把 profile 暴露到公网。
        if err := http.ListenAndServe("127.0.0.1:6060", nil); err != nil {
            log.Printf("pprof stopped: %v", err) // 记录调试服务异常
        }
    }()

    select {} // 示例保持主进程运行，真实服务替换为业务启动流程
}

采集时保留两份文件。goroutine 是当前所有 goroutine 的快照；goroutineleak 只包含运行时判定为泄漏的集合。不要把后者当成“所有等待中的 goroutine”。

# 记录全量堆栈，便于查看业务 worker 的等待位置
curl -s http://127.0.0.1:6060/debug/pprof/goroutine?debug=2 > goroutines.txt
# 记录 Go 运行时识别出的泄漏 profile
curl -s http://127.0.0.1:6060/debug/pprof/goroutineleak > leak.prof
# 用 pprof 查看泄漏候选的聚合调用栈
go tool pprof leak.prof

用数量趋势排除“正常变多”的长期存活 worker

完整 profile 看到几百个 goroutine 卡在同一个接收循环，并不等于它们泄漏。比如服务为了等待队列任务而常驻的 worker，本来就会长期处于等待状态；只要队列、取消上下文或关闭流程仍然可达，它们仍有机会继续工作。

先每隔固定时间记录 runtime.NumGoroutine()，再对照业务流量、worker 池大小和 goroutineleak 的 profile 数量。稳定在设计上限附近，且重启任务或关闭队列时能回收，通常是长期存活；每次请求都增加、流量下降后不回落，并且泄漏 profile 的同一调用点持续累积，才值得进入修复流程。

用 top 和 list 找到永久阻塞的具体语句

进入 profile 后先聚合，再定位到源码函数。示例中的数字是命令输出格式示意，不代表某个真实进程的测量结果。

(pprof) top
(pprof) list processWorkItems
ROUTINE ======================== main.processWorkItems.func1
         0        116 (flat, cum)   100% of Total
         .          .     ch 

如果大量 goroutine 都停在发送语句，要回看接收方是否因错误提前返回；如果停在 range ch，要确认生产者是否负责关闭 channel；如果停在 Wait、Lock 或 Cond.Wait，则需要画出谁持有、谁释放、谁负责取消。真正的修复不是给 profile 加过滤，而是恢复唤醒关系或让 goroutine 获得明确的退出路径。

修复后用同一条路径复测

常见修复包括：提前返回时停止或排空发送方；所有发送完成后由明确的拥有者执行 close(ch)；为后台 worker 传入可取消的 context.Context；给锁和等待组补齐释放与结束条件。修复后不要只看进程刚重启时的数量，而要重复触发原场景，比较同一函数在两次 profile 中是否消失或不再增长。

还要记住覆盖边界：泄漏 profile 主要针对 channel、阻塞式 select 以及 Mutex、RWMutex、WaitGroup、Cond 等标准并发原语。网络 IO、文件 IO、系统调用和自定义自旋锁的阻塞，需要配合超时、执行追踪或业务指标判断。

常见问题

goroutine profile 数量很大就是泄漏吗？

不是。它包含所有当前 goroutine，常驻 worker、连接管理器和定时任务都可能长期存在。要结合泄漏 profile、数量趋势和生命周期验证。

为什么 goroutineleak 没报出一个看起来卡死的 goroutine？

它可能阻塞在 IO 或自定义同步机制上，也可能仍能从全局变量或可运行 goroutine 触达相关原语。此时应使用超时、trace 和代码生命周期分析。

修复后要不要立刻重启服务？

先在可控环境重复触发并重新采样；线上则按灰度和回滚策略发布。重启只能清空现有 goroutine，不能证明创建泄漏的路径已经消失。