协程泄漏可通过监控协程数、使用pprof分析堆栈、优化退出机制来排查和预防。首先，通过runtime.numgoroutine()监控协程数量，若持续增长则可能存在泄漏；其次，使用pprof查看goroutine堆栈，重点检查处于chan receive、select或sleep状态的协程；最后，在编码中避免常见问题，如忘记关闭channel、select无default分支、循环中无限启动协程，并结合日志埋点和context控制生命周期，确保协程能正常退出。
协程泄漏在 golang 中是一个常见但容易被忽视的问题，尤其在高并发场景下，如果协程没有正确退出，会导致内存占用持续增长、系统性能下降，甚至服务崩溃。本文直接切入主题，讲几个实用的方法，帮你检测和预防协程泄漏，特别是结合 runtime 工具进行实战排查。
如何发现协程数量异常？
最简单的判断方式就是监控当前运行的 goroutine 数量。Golang 提供了 runtime.NumGoroutine() 函数，可以实时获取活跃的协程数。你可以把它嵌入到健康检查接口或者日志中定期输出：
log.Println("current goroutines:", runtime.NumGoroutine())
如果你观察到这个数字一直增长且不回落，那大概率存在协程泄漏。这时候就需要进一步分析具体是哪个地方创建了大量无法退出的协程。
立即学习“go语言免费学习笔记（深入）”；
使用 pprof 查看协程堆栈信息
Go 自带的 pprof 工具非常强大，不仅可以用来分析 CPU 和内存使用情况，还能查看所有正在运行的协程堆栈信息。
启用方法很简单，在你的服务中加入以下代码：
import _ "net/http/pprof" go func() { http.ListenAndServe(":6060", nil) }()
然后访问 http://localhost:6060/debug/pprof/goroutine?debug=1，可以看到当前所有 goroutine 的调用栈。重点查找那些处于 chan receive, select, 或者 sleep 状态但长时间不退出的协程。
比如你可能会看到类似这样的内容：
goroutine 123 [chan receive]: main.worker()
这说明某个 worker 协程卡在了 channel 接收操作上，可能是因为没有关闭 channel 导致的阻塞。
避免协程泄漏的几个关键点
协程泄漏的根本原因通常是：协程没有正常退出路径。下面是几个常见的场景和应对建议：
- 忘记关闭 channel：向已关闭的 channel 发送数据会 panic，但从未关闭的 channel 读取会一直阻塞。确保所有写端都关闭 channel。
- select 没有 default 分支或退出机制：如果 select 里只有几个 case 在等 channel，而这些 channel 又永远不触发，协程就会卡住。
- 使用 context 控制生命周期：传入 context 并监听 ctx.Done() 是一种推荐做法，尤其是在处理 HTTP 请求、后台任务时。
- 循环中启动协程未控制生命周期：比如在一个 for 循环里不断起新协程但没有退出机制，很容易积累大量僵尸协程。
举个例子：
for { go func() { // 没有任何退出逻辑 time.Sleep(time.Hour) }() }
这段代码会在每次循环中启动一个协程，并且每个协程都睡一小时，但没有任何机制能终止它们，最终导致协程爆炸。
实战小技巧：加 defer 检查和日志埋点
为了更容易定位问题，可以在协程开始和结束的地方加上日志，特别是在关键函数入口和出口处：
go func() { log.Println("goroutine started") defer func() { log.Println("goroutine exited") }() // 协程逻辑 }()
这样即使协程真的泄露了，也可以通过日志对比“start”和“exit”的数量差异来快速发现问题点。
另外，可以考虑封装一个带超时的协程管理器，自动回收长时间未完成的任务。
基本上就这些。检测协程泄漏的关键在于主动监控 + 日常编码习惯，别让协程变成“孤儿”。工具虽然好用，但还是要靠平时写代码的时候多留心结构设计和退出机制。
