记一次goroutine泄漏的问题

Golang因为有着比线程更加轻量级的协程的出现，使得并发编程的上手难度一下子变得亲民起来。而channel的引入，使得goroutine之间的通信变得异常的便捷。SOFMGUEBMWIDREWO
但好用并不意味着毫无风险，go channel使用不当，也极易引起goroutine泄漏。
何谓goroutine泄漏？就是开启了goroutine，却并没有及时回收，导致goroutine越积越多，如果程序及时关闭还不会出现问题，如果是在服务器中，程序长期运行，就会导致资源占用十分恐怖。
虽然goroutine比线程更轻量级，但每个goroutine至少也会有8~10K的空间，如果goroutine达到了一个恐怖的量级，内存的占用也是十分可怕的。
笔者近期就遇到了一个生产环境的goroutine泄漏问题。

问题复盘
我们有一套go语言开发的程序部署在客户的机器，该程序主要用来接收http请求，并将相应的请求解释成客户端配置文件，下发给客户端。服务器与客户端之间采用的是TCP长连接，二者之间靠心跳机制保活。
除此之外，该服务器还会接收客户端发过来的自监控性能指标信息，通过写ES或其他数据库的方式落到硬盘，以供监控分析。
以上这是背景。
起因是发现其中某一台机器上，该程序运行一段时间后，内存占用达到了数个G，而客户端的连接数量其实并不多。

image.png

通过pprof查看，发现goroutine的数量多得很不正常，甚至达到了13万多个。

image.png
用pprof工具定位，最终发现了问题所在，就是因为goroutine泄漏了。
那么，goroutine怎么会泄漏呢？经过分析代码终于发现了端倪，原来问题出在自监控信息上。
为了接受客户端自监控性能指标的信息，我们在服务器的配置文件中配置了数据库信息，如ES、MySQL、InfluxDb等，客户可以根据自己的需要选择合适的数据库进行存储。自监控信息通过心跳包携带上来。
在设计上是这么做的：心跳接受自监控信息和写数据库分别位于两个协程中，彼此之间通过channel通信。
channel的定义如下，它有1000个缓存：

Runner{
input: make(chan ProcessMetric, 1000),
config: config,
exporters: make(map[string]Exporter, 0),
}