Golang因为有着比线程更加轻量级的协程的出现，使得并发编程的上手难度一下子变得亲民起来。而channel的引入，使得goroutine之间的通信变得异常的便捷。
但好用并不意味着毫无风险，go channel使用不当，也极易引起goroutine泄漏。
何谓goroutine泄漏？就是开启了goroutine，却并没有及时回收，导致goroutine越积越多，如果程序及时关闭还不会出现问题，如果是在服务器中，程序长期运行，就会导致资源占用十分恐怖。
虽然goroutine比线程更轻量级，但每个goroutine至少也会有8~10K的空间，如果goroutine达到了一个恐怖的量级，内存的占用也是十分可怕的。
笔者近期就遇到了一个生产环境的goroutine泄漏问题。
问题复盘
我们有一套go语言开发的程序部署在客户的机器，该程序主要用来接收http请求，并将相应的请求解释成客户端配置文件，下发给客户端。服务器与客户端之间采用的是TCP长连接，二者之间靠心跳机制保活。
除此之外，该服务器还会接收客户端发过来的自监控性能指标信息，通过写ES或其他数据库的方式落到硬盘，以供监控分析。
以上这是背景。
起因是发现其中某一台机器上，该程序运行一段时间后，内存占用达到了数个G，而客户端的连接数量其实并不多。
通过
pprof查看，发现goroutine的数量多得很不正常，甚至达到了13万多个。
用pprof工具定位，最终发现了问题所在，就是因为goroutine泄漏了。
那么，goroutine怎么会泄漏呢？经过分析代码终于发现了端倪，原来问题出在自监控信息上。
为了接受客户端自监控性能指标的信息，我们在服务器的配置文件中配置了数据库信息，如ES、MySQL、InfluxDb等，客户可以根据自己的需要选择合适的数据库进行存储。自监控信息通过心跳包携带上来。
在设计上是这么做的：心跳接受自监控信息和写数据库分别位于两个协程中，彼此之间通过channel通信。
channel的定义如下，它有1000个缓存：
Runner{
input: make(chan ProcessMetric, 1000),
config: config,
exporters: make(map[string]Exporter, 0),
}
在心跳接收的地方：
pm := exporters.ProcessMetric{
AgentId: agentID,
Timestamp: time.Unix(agentHeartbeatInfo.Monitor.Timestamp/1000, 0),
HostName: agentHeartbeatInfo.System.HostName,
Ip: agentHeartbeatInfo.System.Connection.Ip,
Pid: subProcess.Pid,
ProcessName: subProcess.Procname,
Cmd: subProcess.Cmd,
CpuUsageRate: subProcess.CpuUsageRate,
MemUsage: subProcess.MemUsage,
SendLines: subProcess.SendLines,
}
svr.exporterService.Input() <- pm
写入数据库的地方：
for {
select {
case metric := <-exporter.input:
exporter.process(metric)
case <-exporter.t:
return
}
}
乍看起来这样设计似乎没有什么问题，但是为了代码的健壮性，当用户在配置文件里一个数据库都没配置时，就不会去写到数据库。
if len(runner.config.Exporters) == 0 {
return nil
}
问题就出在这里。本来这段代码只是为了提高健壮性的，因为监控信息一般都会打开，偏偏真有客户因为机器上没有部署相应的数据库，所以没有打开，所以导致心跳一直在往channel里发信息，但是channel的接收端由于直接return了，导致无法读取，当1000个缓存满了之后，消息就全部阻塞在那里，导致goroutine越来越多，最终达到了数十万个。
问题重现
为了重现这个问题，我将代码抽象出来了，大致如下程序所示：
package main
import (
"fmt"
"net/http"
_ "net/http/pprof"
"runtime"
"time"
)
func main() {
go http.ListenAndServe("0.0.0.0:6060", nil) //注册pprof监控
ch := make(chan int, 5) //go channel，负责go routine之间通信，5个缓存
flag := false //bool类型标记，模拟配置信息，false表示没有配置
//第一个 go routine, 模拟写数据库信息，这里简化，直接读取channel的内容
go func() {
//当flag为false时，直接return，这行代码是导致go routine泄漏的关键
if !flag {
return
}
for {
select {
case recv := <-ch:
//读取 channel
fmt.Println("recive channel message:", recv)
}
}
}()
//for 循环模拟TCP长连接，每隔500ms向channel写一条数据，模拟心跳上报客户端自监控信息
for {
i := 0
time.Sleep(500 * time.Millisecond)
go func() {
fmt.Println("goroutine count:", runtime.NumGoroutine())
i++
ch <- i
}()
}
}
运行上面的程序，发现当channel中5个缓存满了之后，每向channel中写一次数据，goroutine就会多一个，如果不停止程序，goroutine还将无限增加下去。
问题修复
修复这个问题的方法也很简单，在发送端也做一个判断，当flag为false的时候不向channel发送数据就可以了。
for {
i := 0
time.Sleep(500 * time.Millisecond)
go func() {
fmt.Println("goroutine count:", runtime.NumGoroutine())
i++
if flag {
ch <- i
}
}()
}
修复后运行情况如下所示：
可见无论运行多久，goroutine数量始终保持在3个，不会随着时间的推移无休止增加。
原理剖析
很多人可能不明白，为什么channel阻塞，会造成goroutine增加。看现象似乎每向channel写入一次数据，就会产生一个goroutine，而每从channel中取出一个数据，就会销毁这个goroutine。
其实这么理解也是说得通的。channel本来就是为了goroutine通信用的，数据的传输自然要借助于goroutine。
我们打开channel的源码（src/runtime/chan.go），可以看到向channel写入信息的函数其实是chansend1，内部调用的是chansend函数。
// entry point for c <- x from compiled code
//go:nosplit
func chansend1(c *hchan, elem unsafe.Pointer) {
chansend(c, elem, true, getcallerpc())
}
channel对应的数据结构封装在一个hchan的结构体里，这个结构体的结构如下所示：
type hchan struct {
qcount uint // total data in the queue
dataqsiz uint // size of the circular queue
buf unsafe.Pointer // points to an array of dataqsiz elements
elemsize uint16
closed uint32
elemtype *_type // element type
sendx uint // send index
recvx uint // receive index
recvq waitq // list of recv waiters
sendq waitq // list of send waiters
// lock protects all fields in hchan, as well as several
// fields in sudogs blocked on this channel.
//
// Do not change another G's status while holding this lock
// (in particular, do not ready a G), as this can deadlock
// with stack shrinking.
lock mutex
}
在这个结构体里，维护了两类队列，一个基于数组的循环队列buf，主要用来缓存数据，还有两个用户缓存阻塞的goroutine的双向队列sendq和recvq。
这个buf的大小dataqsiz其实就是我们创建channel时指定的缓存大小。当qcount的数量小于dataqsiz的时候，其实数据是可以放入缓存的。
当buf满了之后，数据就无法再放入缓存队列中了，它就会阻塞在那地方，这些阻塞的数据会新创建一个goroutine，并把这个goroutine存放到sendq队列中。
// Block on the channel. Some receiver will complete our operation for us.
gp := getg()
//这里调用acquireSudog()创建一个goroutine
mysg := acquireSudog()
mysg.releasetime = 0
if t0 != 0 {
mysg.releasetime = -1
}
// No stack splits between assigning elem and enqueuing mysg
// on gp.waiting where copystack can find it.
mysg.elem = ep
mysg.waitlink = nil
mysg.g = gp
mysg.isSelect = false
mysg.c = c
gp.waiting = mysg
gp.param = nil
//放入sendq队列
c.sendq.enqueue(mysg)
//goroutine进入休眠
gopark(chanparkcommit, unsafe.Pointer(&c.lock), waitReasonChanSend, traceEvGoBlockSend, 2)
如果数据一直发不不去，那么这个goroutine将一直在这里休眠，直到有数据发送出去了，就会唤醒它。
// someone woke us up.
if mysg != gp.waiting {
throw("G waiting list is corrupted")
}
最后调用releaseSudog函数回收这个sudog(goroutine)。
通过上面的分析，我想大家已经理解了，为什么channel有数据阻塞，就会导致goroutine得不到释放，从而导致更严重的goroutine泄漏问题。
总结
编程千万条，协程第一条；协程有泄露，亲人两行泪！
[参考资料]
golang channel源码阅读