[TOC] # 什么是goroutine leak goroutine leak，是go协程泄漏，什么是go协程泄漏，通俗来说，开启了一个goroutine，用完后，我们要正确让其结束。如果它没用了，还没结束，那就是goroutine leak。 泄漏的goroutine占用一部分cpu，还可能占着一些其他资源，从而影响主协程效率，有时甚至产生异常。 我们看下面的一个例子。 例子中我们的主协程需要通过某远程服务查询到一个结果。使用一个multiQuery的函数启动多个协程，分别向不同的服务器发起查询，只要收到一个服务器返回，multiQeury就返回结果 ~~~ package main import ( "fmt" "math/rand" "time" ) func queryFromSrc(src string) (ret string) { nanoSec := time.Now().Nanosecond() rand.Seed(int64(nanoSec)) sec := (rand.Int31() % 10) + 1 // time sleep simulates dns lookup and query time.Sleep(time.Second * time.Duration(sec)) ret = fmt.Sprintf("src=%s use sec=%d", src, sec) fmt.Println("a query ok, ret=", ret) return ret } func multiQuery() (ret string) { res := make(chan string, 3) go func() { res <- queryFromSrc("ns1.dnsserver.com") }() go func() { res <- queryFromSrc("ns2.dnsserver.com") }() go func() { res <- queryFromSrc("ns3.dnsserver.com") }() return <-res } func main() { fmt.Println("start multi query:") res := multiQuery() fmt.Println("res=", res) //time.Sleep(time.Second * 20) } ~~~ 本案例使用了一个带缓冲区的channel，multiQuery中的三个并行go func不分先后从远程获取一个结果返回。获取的结果写入channel res，在第一个结果收到后，multiQuery就返回。返回的结果肯定是三个go func中最快返回的。(go func 中的queryFromSrc使用time.Sleep(random)来模拟不同请求延时)。显然，当第一个结果返回后，multiQuery函数就结束了，而其他两个go func还在等待返回。 **如果我们使用不带缓冲区的channel，两个慢的goroutine将会卡在尝试去发送他们的结果到同一个channel，而这个channel将没有任何一个goroutine去读**。因为multiQeury已经执行结束。这种情况叫做goroutine leak。与gc回自动回收的变量不同，泄漏的goroutine不会自动被回收。 所以编程中一定要注意，不使用的goroutine要让其正确地终止 # GC 在runtime的doc中描述了，通过设置环境变量GODEBUG='gctrace=1'可以让go的运行时把gc信息打印到stderr。 ~~~ GODEBUG='gctrace=1' ./sentinel-agent >gc.log & ~~~ gc.log的输出如下： ~~~ gc781(1): 1+2385+17891+0 us, 60 -> 60 MB, 21971 (3503906-3481935) objects, 13818/14/7369 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields gc782(1): 1+1794+18570+1 us, 60 -> 60 MB, 21929 (3503906-3481977) objects, 13854/1/7315 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields gc783(1): 1+1295+20499+0 us, 59 -> 59 MB, 21772 (3503906-3482134) objects, 13854/1/7326 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields gc781：从程序启动开始，第781次gc ~~~ (1)：参与gc的线程个数 1+2385+17891+0：分别是1）stop-the-world的时间，即暂停所有goroutine；2）清扫标记对象的时间；3）标记垃圾对象的时间；4）等待线程结束的耗时。单位都是us，4者之和就是gc暂停的整体耗时 60 -> 60 MB：gc后，堆上存活对象占用的内存，以及整个堆大小（包括垃圾对象） 21971 (3503906-3481935) objects：gc后，堆上的对象数量，gc前分配的对象以及本次释放的对象 13818/14/7369 sweeps：描述对象清扫阶段。一共有13818个memory span，其中14在后台被清扫，7369在stop-the-world期间被清扫 0(0) handoff，0(0) steal：描述并行标记阶段的负载均衡特性。当前在不同线程间传送操作数和总传送操作数，以及当前steal操作数和总steal操作数 0/0/0 yields：描述并行标记阶段的效率。在等待其他线程的过程中，一共有0次yields操做 经过观察gc的输出，发现当前堆上对象总数不断增多，没有减少的趋势，这说明存在对象的泄露，从而导致内存泄露 # memory profile 根据golang官网profile指南 http://blog.golang.org/profiling-go-programs ，在代码中添加 ~~~ import _ "net/http/pprof" func main() { go func() { http.ListenAndServe("localhost:6060", nil) }() } ~~~ 可以在运行时对程序进行profile，通过http访问： ~~~ go tool pprof http://localhost:6060/debug/pprof/heap ~~~ 进行memory profile，默认是`--inuse_space`，显示当前活跃的对象（不包括垃圾对象）占用的空间。使用`--alloc_space`可以显示所有分配的对象（包括垃圾对象）。不过这两种方式都没有发现异常 # 监控goroutine个数 通过runtime.NumGoroutine()可以获取当前的goroutine的个数。通过给程序添加http server获取一些统计信息来了解程序的运行状态，这是Jeff Dean推崇的方法。通过添加下述代码来实时查看goroutine的个数 ~~~ // goroutine stats and pprof go func() { http.HandleFunc("/goroutines", func(w http.ResponseWriter, r *http.Request) { num := strconv.FormatInt(int64(runtime.NumGoroutine()), 10) w.Write([]byte(num)) }); http.ListenAndServe("localhost:6060", nil) glog.Info("goroutine stats and pprof listen on 6060") }() ~~~ 通过命令： ~~~ curl localhost:6060/goroutines ~~~ 查询当前的goroutine的个数。通过不程序运行期间，不断查看，发现goroutine个数不断增加，没有销毁的迹象 # goroutine泄露 通过上面的观察，发现存在goroutine泄露，即goroutine没有正常退出。由于每轮（每隔10秒执行一次）都会创建多个goroutine，如果不能正常退出，则会存在大量的goroutine。go的gc使用的是mark and sweep，会从全局变量、goroutine的栈为根集合扫描所有的存活对象，如果goroutine不退出，就会泄露大量内存。 在确定是由于goroutine没有正常退出后，重新review代码，发现了泄露的根本原因。在重构前，在信号处理程序中，为了正常结束程序，对于每个goroutine都有一个channel，用于主goroutine等待所有goroutine正常结束后再退出。主goroutine中，信号处理程序用于等待所有goroutine的代码： ~~~ waiters = make([]chan int, Num) for _, w := range waiters { <- w } ~~~ 执行检查逻辑的goroutine在结束后，会调用`ag.w <- 1`，用于向主goroutine发送消息。 重构后，由于每轮都会创建goroutine，由于用于主goroutine和检查逻辑的goroutine之间的channel的大小是1，所以所有创建的检查goroutine都阻塞在`ag.w <- 1`上，不能正常退出。最后，把channel逻辑去掉，就不存在goroutine泄露了