Go 笔记之如何防止 goroutine 泄露

 

今天来简单谈谈，Go 如何防止 goroutine 泄露。

概述

Go 的并发模型与其余语言不一样，虽然说它简化了并发程序的开发难度，但若是不了解使用方法，经常会遇到 goroutine 泄露的问题。虽然 goroutine 是轻量级的线程，占用资源不多，但若是一直得不到释放而且还在不断建立新协程，毫无疑问是有问题的，而且是要在程序运行几天，甚至更长的时间才能发现的问题。

对于上面描述的问题，我以为能够从两方面入手解决，以下：

一是预防，要作到预防，咱们就须要了解什么样的代码会产生泄露，以及了解如何写出正确的代码；

二是监控，虽然说预防减小了泄露产生的几率，但没有人敢说本身不犯错，于是，一般咱们还须要一些监控手段进一步保证程序的健壮性；

接下来，我将会分两篇文章分别从这两个角度进行介绍，今天先谈第一点。

如何监控泄露

本文主要集中在第一点上，但为了更好的演示效果，能够先介绍一个最简单的监控方式。经过 runtime.NumGoroutine() 获取当前运行中的 goroutine 数量，经过它确认是否发生泄漏。它的使用很是简单，就不为它专门写个例子了。

一个简单的例子

语言级别的并发支持是 Go 的一大优点，但这个优点也很容易被滥用。一般咱们在开始 Go 并发学习时，经常听别人说，Go 的并发很是简单，在调用函数前加上 go 关键词即可启动 goroutine，即一个并发单元，但不少人可能只听到了这句话，而后就出现了相似下面的代码：

package main import ( "fmt" "runtime" "time" ) func sayHello() { for { fmt.Println("Hello gorotine") time.Sleep(time.Second) } } func main() { defer func() { fmt.Println("the number of goroutines: ", runtime.NumGoroutine()) }() go sayHello() fmt.Println("Hello main") } 复制代码

对 Go 比较熟悉的话，很容易发现这段代码的问题，sayHello 是个死循环，没有如何退出机制，所以也就没有任何办法释放建立的 goroutine。咱们经过在 main 函数最前面的 defer 实如今函数退出时打印当前运行中的 goroutine 数量，毫无心外，它的输出以下：

the number of goroutines: 2
复制代码

不过，由于上面的程序并不是常驻，有泄露问题也不大，程序退出后系统会自动回收运行时资源。但若是这段代码在常驻服务中执行，好比 http server，每接收到一个请求，便会启动一次 sayHello，时间流逝，每次启动的 goroutine 都得不到释放，你的服务将会离奔溃愈来愈近。

这个例子比较简单，我相信，对 Go 的并发稍微有点了解的朋友都不会犯这个错。

泄露状况分类

前面介绍的例子因为在 goroutine 运行死循环致使的泄露。接下来，我会按照并发的数据同步方式对泄露的各类状况进行分析。简单可归于两类，即：

• channel 致使的泄露
• 传统同步机制致使的泄露

传统同步机制主要指面向共享内存的同步机制，好比排它锁、共享锁等。这两种状况致使的泄露仍是比较常见的。go 因为 defer 的存在，第二类状况，通常状况下仍是比较容易避免的。

chanel 引发的泄露

先说 channel，若是以前读过官方的那篇并发的文章，翻译版，你会发现 channel 的使用，一个不当心就泄露了。咱们来具体总结下那些状况下可能致使。

发送不接收

咱们知道，发送者通常都会配有相应的接收者。理想状况下，咱们但愿接收者总能接收完全部发送的数据，这样就不会有任何问题。但现实是，一旦接收者发生异常退出，中止继续接收上游数据，发送者就会被阻塞。这个状况在 前面说的文章 中有很是细致的介绍。

示例代码：

package main import "time" func gen(nums ...int) <-chan int { out := make(chan int) go func() { for _, n := range nums { out <- n } close(out) }() return out } func main() { defer func() { fmt.Println("the number of goroutines: ", runtime.NumGoroutine()) }() // Set up the pipeline. out := gen(2, 3) for n := range out { fmt.Println(n) // 2 time.Sleep(5 * time.Second) // done thing, 可能异常中断接收 if true { // if err != nil break } } } 复制代码

例子中，发送者经过 out chan 向下游发送数据，main 函数接收数据，接收者一般会依据接收到的数据作一些具体的处理，这里用 Sleep 代替。若是这期间发生异常，致使处理中断，退出循环。gen 函数中启动的 goroutine 并不会退出。

如何解决？

此处的主要问题在于，当接收者中止工做，发送者并不知道，还在傻傻地向下游发送数据。故而，咱们须要一种机制去通知发送者。我直接说答案吧，就不循渐进了。Go 能够经过 channel 的关闭向全部的接收者发送广播信息。

修改后的代码：

package main import "time" func gen(done chan struct{}, nums ...int) <-chan int { out := make(chan int) go func() { defer close(out) for _, n := range nums { select { case out <- n: case <-done: return } } }() return out } func main() { defer func() { time.Sleep(time.Second) fmt.Println("the number of goroutines: ", runtime.NumGoroutine()) }() // Set up the pipeline. done := make(chan struct{}) defer close(done) out := gen(done, 2, 3) for n := range out { fmt.Println(n) // 2 time.Sleep(5 * time.Second) // done thing, 可能异常中断接收 if true { // if err != nil break } } } 复制代码

函数 gen 中经过 select 实现 2 个 channel 的同时处理。当异常发生时，将进入 <-done 分支，实现 goroutine 退出。这里为了演示效果，保证资源顺利释放，退出时等待了几秒保证释放完成。

执行后的输出以下：

the number of goroutines:  1
复制代码

如今只有主 goroutine 存在。

接收不发送

发送不接收会致使发送者阻塞，反之，接收不发送也会致使接收者阻塞。直接看示例代码，以下：

package main func main() { defer func() { time.Sleep(time.Second) fmt.Println("the number of goroutines: ", runtime.NumGoroutine()) }() var ch chan struct{} go func() { ch <- struct{}{} }() } 复制代码

运行结果显示：

the number of goroutines:  2
复制代码

固然，咱们正常不会遇到这么傻的状况发生，现实工做中的案例更多多是发送已完成，可是发送者并无关闭 channel，接收者天然也没法知道发送完毕，阻塞所以就发生了。

解决方案是什么？那固然就是，发送完成后必定要记得关闭 channel。

nil channel

向 nil channel 发送和接收数据都将会致使阻塞。这种状况可能在咱们定义 channel 时忘记初始化的时候发生。

示例代码：

func main() { defer func() { time.Sleep(time.Second) fmt.Println("the number of goroutines: ", runtime.NumGoroutine()) }() var ch chan int go func() { <-ch // ch<- }() } 复制代码

两种写法：<-ch 和 ch<- 1，分别表示接收与发送，都将会致使阻塞。若是想实现阻塞，经过 nil channel 和 done channel 结合实现阻止 main 函数的退出，这或许是能够一试的方法。

func main() { defer func() { time.Sleep(time.Second) fmt.Println("the number of goroutines: ", runtime.NumGoroutine()) }() done := make(chan struct{}) var ch chan int go func() { defer close(done) }() select { case <-ch: case <-done: return } } 复制代码

在 goroutine 执行完成，检测到 done 关闭，main 函数退出。

真实的场景

真实的场景确定不会像案例中的简单，可能涉及多阶段 goroutine 之间的协做，某个 goroutine 可能即便接收者又是发送者。但归根接底，不管什么使用模式。都是把基础知识组织在一块儿的合理运用。

传统同步机制

虽然，通常推荐 Go 并发数据的传递，但有些场景下，显然仍是使用传统同步机制更合适。Go 中提供传统同步机制主要在 sync 和 atomic 两个包。接下来，我主要介绍的是锁和 WaitGroup 可能致使 goroutine 的泄露。

Mutex

和其余语言相似，Go 中存在两种锁，排它锁和共享锁，关于它们的使用就不做介绍了。咱们以排它锁为例进行分析。

示例以下：

func main() { total := 0 defer func() { time.Sleep(time.Second) fmt.Println("total: ", total) fmt.Println("the number of goroutines: ", runtime.NumGoroutine()) }() var mutex sync.Mutex for i := 0; i < 2; i++ { go func() { mutex.Lock() total += 1 }() } } 复制代码

执行结果以下：

total: 1
the number of goroutines: 2
复制代码

这段代码经过启动两个 goroutine 对 total 进行加法操做，为防止出现数据竞争，对计算部分作了加锁保护，但并无及时的解锁，致使 i = 1 的 goroutine 一直阻塞等待 i = 0 的 goroutine 释放锁。能够看到，退出时有 2 个 goroutine 存在，出现了泄露，total 的值为 1。

怎么解决？由于 Go 有 defer 的存在，这个问题仍是很是容易解决的，只要记得在 Lock 的时候，记住 defer Unlock 便可。

示例以下：

mutex.Lock()
defer mutext.Unlock() 复制代码

其余的锁与这里其实都是相似的。

WaitGroup

WaitGroup 和锁有所差异，它相似 Linux 中的信号量，能够实现一组 goroutine 操做的等待。使用的时候，若是设置了错误的任务数，也可能会致使阻塞，致使泄露发生。

一个例子，咱们在开发一个后端接口时须要访问多个数据表，因为数据间没有依赖关系，咱们能够并发访问，示例以下：

package main import ( "fmt" "runtime" "sync" "time" ) func handle() { var wg sync.WaitGroup wg.Add(4) go func() { fmt.Println("访问表1") wg.Done() }() go func() { fmt.Println("访问表2") wg.Done() }() go func() { fmt.Println("访问表3") wg.Done() }() wg.Wait() } func main() { defer func() { time.Sleep(time.Second) fmt.Println("the number of goroutines: ", runtime.NumGoroutine()) }() go handle() time.Sleep(time.Second) } 复制代码

执行结果以下：

the number of goroutines: 2
复制代码

出现了泄露。再看代码，它的开始部分定义了类型为 sync.WaitGroup 的变量 wg，设置并发任务数为 4，可是从例子中能够看出只有 3 个并发任务。故最后的 wg.Wait() 等待退出条件将永远没法知足，handle 将会一直阻塞。

怎么防止这类状况发生？

我我的的建议是，尽可能不要一次设置所有任务数，即便数量很是明确的状况。由于在开始多个并发任务之间或许也可能出现被阻断的状况发生。最好是尽可能在任务启动时经过 wg.Add(1) 的方式增长。

示例以下：

...
    wg.Add(1) go func() { fmt.Println("访问表1") wg.Done() }() wg.Add(1) go func() { fmt.Println("访问表2") wg.Done() }() wg.Add(1) go func() { fmt.Println("访问表3") wg.Done() }() ... 复制代码

总结

大概介绍完了我认为的全部可能致使 goroutine 泄露的状况。总结下来，其实不管是死循环、channel 阻塞、锁等待，只要是会形成阻塞的写法均可能产生泄露。于是，如何防止 goroutine 泄露就变成了如何防止发生阻塞。为进一步防止泄露，有些实现中会加入超时处理，主动释放处理时间太长的 goroutine。

本篇主要从如何写出正确代码的角度来介绍如何防止 goroutine 的泄露。下篇，将会介绍如何实现更好的监控检测，以帮助咱们发现当前代码中已经存在的泄露。

参考资料

Concurrency In Go
Goroutine leak
Leaking-Goroutines
Go Concurrency Patterns: Context
Go Concurrency Patterns: Pipelines and cancellation
make goroutine stay running after returning from function
Never start a goroutine without knowing how it will stop

原文：http://www.javashuo.com/article/p-hbgvlpwk-ct.html