记一次goroutine泄漏的问题

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源码阅读