小马别过河

V1

2022/12/14阅读:13主题:默认主题

Goroutines 泄漏场景与防治

场景

Go 有很多自动管理内存的功能。比如:

  • 变量分配到堆内存还是栈内存,编译器会通过内存逃逸(escpage analysis)来判断;
  • 堆内存的垃圾回收。

即便如此,如果编码不谨慎,我们还是有可能导致内存泄漏的,最常见的是 goroutine 泄漏,比如下面的函数:

func goroutinueLeak() {
 ch := make(chan int)

 go func(ch chan int) {
    // 因为 ch 一直没有数据,所以这个协程会阻塞在这里。
  val := <-ch
  fmt.Println(val)
 }(ch)
}

由于ch一直没有发送数据,所以我们开启的 goroutine 会一直阻塞。每次调用goroutinueLeak都会泄漏一个goroutine,从监控面板看到话,goroutinue 数量会逐步上升,直至服务 OOM。

Goroutine 泄漏常见原因

channel 发送端导致阻塞

使用 context 加超时设置是常见的一个场景,试想一下,下面的函数什么情况下会 goroutine 泄漏 ?

func contextLeak() error {
 ctx, cancel := context.WithTimeout(context.Background(), 1*time.Minute)
 defer cancel()

 ch := make(chan int)

  //g1
 go func() {
  // 获取数据,比如网络请求,可能时间很久
  val := RetriveData()
  ch <- val
 }()

 select {
 case <-ctx.Done():
  return errors.New("timeout")
 case val := <-ch:
  fmt.Println(val)
 }

 return nil
}

RetriveData() 如果超时了,那么contextLeak() 会返回 error,本函数执行结束。而我们开启的协程g1,由于没有接受者,会阻塞在 ch<-val

解决方法也能简单,比如可以给ch加上缓存。

channel 接收端导致阻塞

开篇给出的函数goroutinueLeak,就是因为channel的接收端收不到数据,导致阻塞。

这里举出另一个例子,下面的函数,是否有可能 goroutinue 泄漏?

func errorAssertionLeak() {
 ch := make(chan int)
  // g1
 go func() {
  val := <-ch
  fmt.Println(val)
 }()
  // RetriveSomeData 表示获取数据,比如从网络上
 val, err := RetriveSomeData()
 if err != nil {
  return
 }

 ch <- val
 return nil
}

如果 RetriveSomeData() 返回的err 不为 nil,那么本函数中断,也就不会有数据发送给ch,这导致协程g1会一直阻塞。

如何预防

goroutine 泄漏往往需要服务运行一段时间后,才会被发觉。

我们可以通过监控 goroutine 数量来判断是否有 goroutine 泄漏;或者用 pprof(之前文章介绍过的) 来定位泄漏的 goroutine。但这已经是亡羊补牢了。最理想的情况是,我们在开发的过程中,就能发现。

本文推荐的做法是,使用单元测试。以开篇的 goroutinueLeak 为例子,我们写个单测:

func TestLeak(t *testing.T) {
 goroutinueLeak()
}

执行 go test,发现测试是通过的:

=== RUN   TestLeak
--- PASS: TestLeak (0.00s)
PASS
ok   example/leak 0.598s

这是是因为单测默认不会检测 goroutine 泄漏的。

我们可以在单测中,加入Uber 团队提供的 uber-go/goleak 包:


import (
 "testing"

 "go.uber.org/goleak"
)

func TestLeak(t *testing.T) {
  // 加上这行代码,就会自动检测是否 goroutine 泄漏了
 defer goleak.VerifyNone(t)
 goroutinueLeak()
}

这时候执行 go test,输出:

=== RUN   TestLeak
    /xxx/leak_test.go:12: found unexpected goroutines:
        [Goroutine 21 in state chan receive, with example/leak.goroutinueLeak.func1 on top of the stack:
        goroutine 21 [chan receive]:
        example/leak.goroutinueLeak.func1(0x0)
         /xxx/leak.go:9 +0x27
        created by example/leak.goroutinueLeak
         /xxx/leak.go:8 +0x7a
        ]
--- FAIL: TestLeak (0.46s)
FAIL
FAIL example/leak 0.784s

这时候单测会因为 goroutine 泄漏而不通过。

如果你觉得每个测试用例都要加上 defer goleak.VerifyNone(t) 太繁琐的话(特别是在已有的项目中加上),goleak 提供了在 TestMain 中使用的方法VerifyTestMain,上面的单测可以修改成:


func TestLeak(t *testing.T) {
 goroutinueLeak()
}

func TestMain(m *testing.M) {
 goleak.VerifyTestMain(m)
}

总结

虽然我的文章经常提及单测,但我本人不是单元测试的忠实粉丝。扎实的基础,充分的测试,负责任的态度也是至关重要的。

引用

  1. https://www.ardanlabs.com/blog/2018/11/goroutine-leaks-the-forgotten-sender.html
  2. https://www.ardanlabs.com/blog/2018/12/goroutine-leaks-the-abandoned-receivers.html
  3. https://github.com/uber-go/goleak

分类:

后端

标签:

Golang

作者介绍

小马别过河
V1