17370845950

最轻量的 goroutine 泄漏检测方式是 runtime.NumGoroutine()，通过操作前后计数差值判断是否回归基线，需显式等待 goroutine 退出并多次采样取最小值以避免误报。

用 runtime.NumGoroutine() 在测试里快速抓明显泄漏

这是最轻量、也最容易上手的检测方式，适合在单元测试或 CI 阶段第一时间拦截低级泄漏。它不依赖外部服务，只靠一个计数差值就能发出警报。

关键不是看绝对值，而是看「操作前后是否回归基线」：启动函数 → 给足够时间让 goroutine 退出 → 检查数量是否回落。

• 别只 time.Sleep(100 * time.Millisecond)：有些 goroutine 依赖超时或外部信号（如 context.WithTimeout 或 time.AfterFunc），100ms 可能根本不够；建议配合 done chan struct{} 显式等待退出
• 系统 goroutine 本身有波动（GC、timer、netpoll 等），单次采样易误报；推荐采样 3 次取最小值作 baseline，或直接用 goleak 库自动过滤已知安全 goroutine
• 示例中漏掉 close(ch) 或没 sender 却 ，这种写法一跑就漏，NumGoroutine() 能立刻暴露

用 net/http/pprof 查生产环境里卡在哪一行

runtime.NumGoroutine() 告诉你“有泄漏”，pprof 才告诉你“谁卡着、为什么卡、从哪来的”。这是线上服务的标准排查路径。

只需两步：导入 _ "net/http/pprof"，再起个独立监听 goroutine（端口建议固定为 :6060）；无需改业务逻辑，零侵入。

• 访问 http://localhost:6060/debug/pprof/goroutine?debug=1 看当前所有 goroutine 的堆栈；加 ?debug=2 还能看到更详细的 channel blocking 信息
• 重点关注状态为 chan receive、select、semacquire 或长时间 sleep 的 goroutine —— 它们大概率就是泄漏源
• 对比两次快照：服务刚启动时抓一次（A），运行 5 分钟后再抓一次（B），用 diff -u A B | grep "^+" 找新增堆栈，直指问题函数

用 uber-go/goleak 在测试阶段自动报错

手动数 goroutine 容易漏、难复现、还费时间。goleak 是 Uber 开源的专用检测库，能在测试结束时自动扫描未回收 goroutine，并打印初始调用栈，开发阶段就能堵住大部分泄漏。

• 在 TestMain 中调用 goleak.VerifyNone(t)，它会自动忽略 runtime 内部 goroutine（比如 timerproc、gcworker），只报你代码里漏掉的
• 它比 NumGoroutine() 更准：不依赖 sleep，不被系统波动干扰，还能定位到 goroutine 启动的原始位置
• 注意：必须确保被测逻辑真正“结束”了——比如 HTTP handler 测试要等 response 写完、channel 操作要 close 或 drain 完，否则 goleak 会误报

用 context.Context 从源头避免泄漏

绝大多数 goroutine 泄漏，本质是“没有退出机制”。而 context 是 Go 官方提供的、最自然的取消信号传递方式，尤其适合 HTTP 请求、定时任务、长连接等场景。

• 永远不要写 for { select { case 这种无限循环，除非你明确知道它何时停；应改成 for { select { case
• 启动 goroutine 时

  

  ，把 ctx 作为第一个参数传入，而不是靠全局变量或闭包捕获；这样 cancel 信号才能穿透到底层
• 常见坑：忘了 defer cancel()、在子 goroutine 里没检查 ctx.Err()、用 context.Background() 代替 context.WithTimeout 导致无法超时退出

真正难排查的泄漏，往往藏在“看起来会自己结束”的地方：比如一个被遗忘的 time.Ticker 没 Stop()，或者一个 HTTP client 的 Transport 里残留了 idle connection goroutine。这些不会被 NumGoroutine() 立刻发现，但 pprof 快照对比和 goleak 的调用栈追踪能揪出来。动手前先想清楚：这个 goroutine，谁负责关？怎么关？关得掉吗？