背景
周所周知，内存泄漏是一个很严重的问题，会导致系统运行占用资源越来越多，无法释放，直至崩溃。所幸 Go 语言是一门 具有垃圾回收的语言，能大大降低遇到内存泄漏的概率，而我们今天要说的是另外一个棘手的问题：协程泄漏。
协程泄漏：顾名思义就是出现了应该释放而没有被释放的协程，导致系统协程数量一直上升。不像对象回收需要引用计数、三色标记等手段，协程的回收是相当简单的，等待协程将代码从头到尾执行完毕之后这一块儿空间就会自动回收，通常协程泄漏问题都是因为某段代码卡住了，陷入了死循环或者再等待一个不可能的条件等原因。
那么具体如何定位到到底是哪里出了问题呢，具体就要用到 Go 官方提供的性能分析工具了：pprof。
pprof
pprof 具体在 Go 语言中的实现是在包：runtime/pprof 中，提供了诸如内存分析、CPU分析、锁分析等函数供调用，调用这个库之后会将性能数据以 protobuffer 这种二进制序列化格式导出。同时考虑到这一个库较为底层，Go 官方在 runtime/pprof 上包装提供了一个更加易用的库：net/http/pprof，提供了一种通过 HTTP 协议和性能数据交互的能力。除了性能数据的抓取工具，Golang 也提供了官方的性能数据分析工具：go tool pprof，下面我们将基于这些工具进行一次协程泄漏问题的排查。
制造协程泄漏
http.pprof 会在 init 的时候注册一些路由到 http.DefaultServeMux 上，所以要使用这个库，我们要做的只需要引入这个包，并且使用 DefaultServeMux 监控一个端口即可，具体的话调用：http.ListenAndServe 时 handler 传空即可，传空的时候会默认使用 DefaultServeMux 来处理。
一下是一个协程泄漏的例子，分别在第 11 行和 14 行泄漏了 1000 个协程。
package main
import (
"net/http"
_ "net/http/pprof"
)
func main() {
for i := 0; i < 1000; i++ {
go func() {
select {} // 泄漏了 1000 个协程
}()
go func() {
select {} // 泄漏了 1000 个协程
}()
}
// 启动一个 pprof http server
if err := http.ListenAndServe(":7899", nil); err != nil {
panic(err.Error())
}
}
下面我们把这个服务跑起来：go run pprof.go
分析泄漏问题
我们先打开协程 Debug 的地址，我的服务监听在本地 7899 端口，所以地址是：http://127.0.0.1:7899/debug/pprof/goroutine?debug=1，通过这个我们已经可以很明显看到，我们的问题就发生在 pprof.go 11 行和 14 行这里，泄漏了 2000 个协程，那么我们就重点去排查这一段代码即可。
这个页面很简单，可读性不高，不过当程序内存状态很复杂的时候，可以考虑配合可视化工具使用。
输入命令：go tool pprof -http=:8001 http://127.0.0.1:7899/debug/pprof/goroutine\?debug\=1
在本地 8001 端口启动一个 HTTP 可视化分析工具，打开 http://127.0.0.1:8001/ui/ 地址，我们就能更直观的看到所有的协程启动的情况：
同时这个可视化分析工具还支持火焰图、类 TOP 图表等格式进行分析，点击左上角 VIEW 切换即可：
总结
pprof 可以很方便帮助我们排查协程泄漏问题，同时这套工具能干的不止如此，几乎所有在程序性能上遇到的问题都可以使用其进行分析，想了解其他功能的话可以参考以下官方文章进行进一步的学习： https://blog.golang.org/pprof https://github.com/google/pprof/blob/master/doc/README.md