Goroutine 泄漏的调试

内容简介：Goroutine 泄漏的调试

在我们谈论协程(Goroutines)泄漏之前，我们先看看并发编程的概念。并发编程处理程序的并发执行。多个连续流 任务通过并发编程 更好地利用多核处理器的功能，实现更快的并发/并行程序。

协程 (Goroutines)

协程实现了并发执行，协程是 Go 运行时轻量级线程， 协程和线程之间并无一对一的关系，协程 由Go管理调度，运行在不同的线程上。Go协程 的设计隐藏了许多线程创建和管理方面的复杂工作。

关于 并发/并行程序， 并发程序可能是并行的，也可能不是。并行是一种通过使用多处理器以提高速度的能力。一个设计良好的并发程序在并行方面的表现也非常出色。在Go语言中，为了使你的程序可以使用多个核心运行，这时协程就真正的是并行运行了，你必须使用  GOMAXPROCS  变量。详细参考： https://github.com/Unknwon/the-way-to - go_ZH_CN/blob/master/eBook/14.1.md

同步 ( synchronize)

进程、线程、协程协作都有一个共同的目标：同步和通讯。

Go语言中， Channels用于协程的同步。 传统线程模式通讯是共享内存。Go鼓励使用Channel在协程之间传递 引用 ，而不是显式地使用锁来协调对共享数据的访问。 这种方法确保在给定时间只有一个goroutine可以访问数据。

如下面的例子所示，每个worker执行完成后，他们需要与main协程协作，将返回结果通过channels传递给main协程，之后main协程退出程序。

1. package main

2. import (

3. "fmt"

4. "time"

5. )

6. func main () {

7. ch := make ( chan string )

8. go sendData(ch)

9. go getData(ch)

10. // 注释一

11. time.Sleep( 1e9 )

12. }

13. // 往通道中塞进数据 func sendData (ch chan string ) {

14. ch <- "A"

15. ch <- "g"

16. ch <- "f"

17. ch <- "e"

18. ch <- "d"

19. ch <- "c"

20. }

21. // 提取通道中的数据 func getData (ch chan string ) {

22. var input string

23. //time.Sleep(1e9)

24. for {

25. input = <-ch

26. fmt.Printf( "%s" , input)

27. }

28. }

同步出错

请注意，每次使用go关键字时，Go例程 将 如何退出。 有时候同步可能出现错误，导致一些goroutine永远等待。 在Go语言中，如下情况可能导致同步出错：

Channel没有接受者

没有一个接受者来接受发送者发送的数据， Channel 是阻塞的。 没有接受者的Channel会引起程序挂起。下面的例子，ch1没有接受者，将导致Channel是阻塞的。

1. package main

2. import "fmt"

3. func main () {

4. ch1 := make ( chan int )

5. go pump(ch1)       // pump hangs

6. fmt.Println(<-ch1) // prints only 0

7. }

8. func pump (ch chan int ) {

9. for i := 0 ; ; i++ {

10. ch <- i

11. }

12. }

Channel没有写入者

如下情况会出现channel没有写入者的情况，会出现goroutine泄漏。

例 1: for-select

1. for {

2. select { 

3. case <-c: 

4. // process here

5. }

6. }

例 2: channel循环

1. go func() {

2. for range ch { }

4. }()

例3: 演示tasks循环，导致channel没有写入者，需要主程序调用close(tasks)来避免goroutine泄漏问题。

2. import "fmt"

3. package main

5. func concurrency() {

6. // lets first create a channel with a buffer

7. tasks := make(chan string, 20)

9. // create another one to receive the results

10. results := make(chan string, 20)

12. workers := []int{1, 2, 3, 4}

14. // inserting tasks inside the channel

15. for task := 0; task < 10; task++ {

16. tasks <- fmt.Sprintf("Task %d", task)

17. }

19. for _, w := range workers {

20. // starging one goroutine for each worker

21. go work(w, tasks, results)

22. }

23. close(tasks)

25. // lets print the resutls

26. fmt.Println("Will print the results")

28. for res := 0; res < 10; res++ {

29. fmt.Println("Result:", <-results)

30. }

31. }

33. func work(workerID int, tasks chan string, results chan string) {

34. // worker will block util a new task arrives in the channel

35. for t := range tasks {

36. // simple task as example

37. results <- fmt.Sprintf("Worker %d got %v", workerID, t)

38. }

39. }

41. func main() {

42. concurrency()

43. }

好的做法

使用timeOut

1. timeout := make(chan bool, 1)

2. go func() {

3. time.Sleep(1e9) // one second

4. timeout <- true

5. }()

7. select {

8. case <- ch:

9. // a read from ch has occurred

10. case <- timeout:

11. // the read from ch has timed out

12. }           OR select {

13. case res := <-c1:

14. fmt.Println(res)

15. case <-time.After(time.Second * 1):

16. fmt.Println("timeout 1")

17. }

使用 Golang context package

Golang context package 可以 用来优雅地结束例程甚至超时

泄漏检测

仪器（ instrument）端点

检测Web服务器泄漏的办法是添加仪器端点，并将其与负载测试一起使用。

1. // get the count of number of go routines in the system.

2. func countGoRoutines() int {

3. return runtime.NumGoroutine()

4. }      

6. func getGoroutinesCountHandler(w http.ResponseWriter, r *http.Request) {

7. // Get the count of number of go routines running.

8. count := countGoRoutines()

9. w.Write([]byte(strconv.Itoa(count)))

10. }

12. func main() {

13. http.HandleFunc("/_count", getGoroutinesCountHandler)

14. }

在负载测试之前和之后，通过 仪器端点响应 在系统中存在的goroutines数量。以下是负载测试程序的流程：

1. Step 1: Call the instrumentation endpoint and get the count of number of goroutines alive in your webserver.

3. Step 2: Perform load test.Lets the load be concurrent. 

4. for i := 0; i < 100 ; i++ {

5. go callEndpointUnderInvestigation()

6. }

8. Step 3: Call the instrumentation endpoint and get the count of number of goroutines alive in your webserver.

如果负载测试后系统中存在异常增加的goroutine数量，则证明存在泄漏。这是一个具有漏洞端点的Web服务器的小例子。 通过简单的测试我们可以确定服务器 是否存在 泄漏。

1. // First run the leaky server $ go run leaky-server.go

2. // Run the load test now.$ go run load.go

3. 3 Go routines before the load test in the system.

4. 54 Go routines after the load test in the system.

您可以清楚地看到，通过50个并发请求到泄漏端点，系统中增加了50个程序。

让我们再次运行负载测试。

1. $ go run load.go

1. 53 Go routines before the load test in the system.

1. 104 Go routines after the load test in the system.

很清楚，在每次运行的负载测试中，服务器中的执行次数都在增加，而不是下降。 这是一个明显的泄漏证据。

识别泄漏的起因

使用栈跟踪端点

一旦发现Web服务器中存在泄漏，需要确定泄漏的来源。可以通过添加返回Web服务器的栈跟踪端点可以帮助识别泄漏的来源。

1. import (

2. "runtime/debug"

3. "runtime/pprof"

4. )

6. func getStackTraceHandler(w http.ResponseWriter, r *http.Request) {       

7. stack := debug.Stack()       

8. w.Write(stack)       

10. }

12. func main() {

13. http.HandleFunc("/_stack", getStackTraceHandler)

14. }

在确定泄漏的存在之后，使用端点在负载之前和之后获取栈跟踪信息，以识别泄漏的来源。 将栈跟踪 工具 添加到泄漏服务器并再次执行负载测试。 

如下 栈跟踪信息清楚地指出泄漏的震中：

1. // First run the leaky server$ go run leaky-server.go

2. // Run the load test now.$ go run load.go

3. 3 Go routines before the load test in the system.

4. 54 Go routines after the load test in the system. goroutine 149 [chan send]:

5. main.sum(0xc420122e58, 0x3, 0x3, 0xc420112240)

6. /home/karthic/gophercon/count-instrument.go:39 +0x6c

7. created by main.sumConcurrent

8. /home/karthic/gophercon/count-instrument.go:51 +0x12b

10. goroutine 243 [chan send]:

11. main.sum(0xc42021a0d8, 0x3, 0x3, 0xc4202760c0)

12. /home/karthic/gophercon/count-instrument.go:39 +0x6c

13. created by main.sumConcurrent

14. /home/karthic/gophercon/count-instrument.go:51 +0x12b

16. goroutine 259 [chan send]:

17. main.sum(0xc4202700d8, 0x3, 0x3, 0xc42029c0c0)

18. /home/karthic/gophercon/count-instrument.go:39 +0x6c

19. created by main.sumConcurrent

20. /home/karthic/gophercon/count-instrument.go:51 +0x12b

22. goroutine 135 [chan send]:

23. main.sum(0xc420226348, 0x3, 0x3, 0xc4202363c0)

24. /home/karthic/gophercon/count-instrument.go:39 +0x6c

25. created by main.sumConcurrent

26. /home/karthic/gophercon/count-instrument.go:51 +0x12b

28. goroutine 166 [chan send]:

29. main.sum(0xc4202482b8, 0x3, 0x3, 0xc42006b8c0)

30. /home/karthic/gophercon/count-instrument.go:39 +0x6c

31. created by main.sumConcurrent

32. /home/karthic/gophercon/count-instrument.go:51 +0x12b

34. goroutine 199 [chan send]:

35. main.sum(0xc420260378, 0x3, 0x3, 0xc420256480)

36. /home/karthic/gophercon/count-instrument.go:39 +0x6c

37. created by main.sumConcurrent

38. /home/karthic/gophercon/count-instrument.go:51 +0x12b

39. ........

使用profiling

由于泄漏的goroutine通常被阻止去尝试读取或写入channel或甚至可能睡眠，profilling分析将帮助识别泄漏的起因。参见 benchmarks and profiling 谈论基准测试和分析，或 https://github.com/Unknwon/the-way-to-go_ZH_CN/blob/master/eBook/13.10.md 。

避免泄漏，赶早不赶晚

单元测试和功能测试中使用instrument机制可以帮助早期识别泄漏。计数试验前后的goroutine数。

1. func TestMyFunc() {

2. // get count of go routines. perform the test. 

3. // get the count diff. 

4. // alert if there's an unexpected rise.

5. }

测试中的栈差异

栈差异是一个简单的程序，它在测试之前和之后对栈跟踪进行 差异 比较，并在任何不期望的goroutine遗留的系统情况下发出警报。 将将其与单元测试和功能测试集成，可以帮助在开发过程中识别泄漏。

1. import (

2. github.com/fortytw2/leaktest

3. )

5. func TestMyFunc(t *testing.T) {

6. defer leaktest.Check(t)()

8. go func() {

9. for {

10. time.Sleep(time.Second)

11. }

12. }()

13. }

安全设计

当系统受到一个端点/服务受到泄漏或资源中断影响的时候，微服务架构的服务做为 独立容器/过程运行可以保护整个系统。推荐使用容器编排工具，如Kubernetes，Mesosphere和Docker Swarm。

Goroutine泄漏就像慢性自杀。  设想获取整个系统的栈跟踪，并尝试识别哪些服务导致数百个服务中的泄漏！ 真的吓人!!!! 他们在一段时间浪费你的计算资源，慢慢积累，你甚至不会注意到。 真的很重要去意识到泄漏并尽早调试它们！

Go会让你再次爱编程。 我承诺。 Go will make you love programming again. I promise.

参考：

1. 《The Way to Go》中文译本《Go入门指南》 https://github.com/Unknwon/the-way-to-go_ZH_CN

2. Debugging go routine leaks:  https://youtu.be/hWo0FEVr92A

以上所述就是小编给大家介绍的《Goroutine 泄漏的调试》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• Android 系统开发_内存泄漏篇 -- "内存泄漏"的前世今生
• 内存泄漏（增长）火焰图
• 浅谈内存泄漏
• 小心递归中内存泄漏
• Android内存泄漏场景
• 内存泄漏预防与治理

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。