Golang如何用goleak检测协程泄漏

本文深入解析了Go语言中协程泄漏的检测与预防全链路方案：强调goleak必须用defer包裹以确保在panic或提前返回时仍能执行检测，子测试需独立加defer，手动启动的http.Server等需显式忽略；指出90%的泄漏源于channel生命周期管理失当，需严格把控创建者负责关闭、避免nil/重复close、合理使用done channel替代无界range；线上环境依赖pprof实时分析goroutine堆栈，通过对比采样定位长期阻塞点；更关键的是在开发测试阶段就构建防御体系——结合-race检测竞态、context统一控制goroutine生命周期、runtime.NumGoroutine()持续观测数量变化，从而将协程泄漏从“事后救火”转变为“事前拦截”，尤其应对多goroutine协同场景下的链式依赖卡死问题。

goleak.VerifyNone(t) 必须放 defer 里，否则白加

测试中加了 goleak.VerifyNone(t) 却没报泄漏？大概率是它没执行到。因为 test panic 或提前 return 时，没被 defer 包裹的调用直接跳过了。

• goleak.VerifyNone(t) 要放在 TestXxx 函数末尾，并用 defer 包裹，确保无论成功失败都检查
• 别写成 goleak.VerifyNone(t); return 这种直出写法——panic 时这行根本不会跑
• 如果用了 test.SubTest，每个子测试也得单独加 defer goleak.VerifyNone(t)，父测试的不传递
• 默认会忽略标准库启动的 goroutine（比如 net/http 的监听协程），但你手动启的 http.Server 不在白名单里，得显式忽略：goleak.IgnoreCurrent() 或传 goleak.Option

90% 的泄漏来自 channel 使用不当，重点盯这三件事

goleak 告诉你“有泄漏”，但堆栈往往停在 runtime.gopark 或 runtime.selectgo —— 实际问题八成出在 channel 生命周期管理上。

• 谁创建 chan，谁负责 close()；向已 close 的 channel 发送数据会 panic，但接收还能读完缓冲区 + 零值
• 用 for range ch 的 goroutine，必须由发送方关 channel；如果发送方不确定何时结束，改用 select + done channel 控制退出
• 别对 nil channel 执行 close()，也别重复 close()，两者都 panic
• 错误示例：go func() { for range ch { ... } }() —— 若 ch 永远不关，这个 goroutine 就永远挂起

线上/集成环境没法用 goleak？pprof 是唯一能靠得住的入口

goleak 只能在单元测试里用，而线上或 CI 流水线中一旦发现协程数持续上涨，pprof 是唯一可落地的诊断手段。

• 导入 _ "net/http/pprof"，再启一个 debug server：go func() { http.ListenAndServe("localhost:6060", nil) }()
• 访问 http://localhost:6060/debug/pprof/goroutine?debug=2，重点关注堆栈末尾停在 chan receive、semacquire、time.Sleep 的 goroutine
• 对比两次采集结果（间隔几十秒），新增且长期卡在相同位置的 goroutine，基本就是泄漏点
• 命令行也可用：go tool pprof http://localhost:6060/debug/pprof/goroutine，进交互后输 top 看占用最多的函数

测试阶段就该预防：-race + context + runtime.NumGoroutine() 组合拳

等 goleak 报警才修，已经晚了一步。真正靠谱的做法是在开发和测试阶段就建立多层防线。

• 跑测试必加 go test -race，它能暴露因竞态导致的 goroutine 卡死（比如两个 goroutine 争抢关闭同一个 channel）
• 凡是有长周期 goroutine（如 ticker、websocket handler、后台轮询），一律用 context.Context 控制生命周期，而不是靠 channel 关闭信号
• 在关键路径打点：fmt.Printf("goroutines: %d\n", runtime.NumGoroutine())，观察数量是否随请求完成回落
• 别依赖 “应该会退出” —— 每个 goroutine 启动前，先想清楚它收到什么信号才会退出，以及那个信号由谁发、什么时候发

实际项目里最麻烦的不是找不到泄漏点，而是泄漏发生在多个 goroutine 协同逻辑里，比如 A 发 signal、B 收 signal、C 等 B 完成后再关 channel —— 这种链式依赖只要一环没触发，整条链就全卡住。这种时候，光看 goleak 报错堆栈没用，得结合 pprof 的实时堆栈和 context.Done() 的监听位置交叉验证。

到这里，我们也就讲完了《Golang如何用goleak检测协程泄漏》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！