2. 程式人生 > >Go 筆記之如何防止 goroutine 洩露（二）

Go 筆記之如何防止 goroutine 洩露（二）

阿新 • • 發佈：2019-08-04

上篇文章說到，防止 goroutine 洩露可從兩個角度出發，分別是程式碼層面的預防與執行層面的監控檢測。今天，我們來談第二點。

簡述

前文已經介紹了一種簡單檢測 goroutine 是否洩露的方法，即通過 runtime.NumGoroutine 獲取當前執行中的 goroutine 數量粗略估計。但 NumGoroutine 是否真的能確定我們程式碼存在洩露，除此之外，還有沒有其他更優的方式嗎。

注：為了更好的演示效果，下面將會用常駐的 http 作為示例。

NumGoroutine

runtime.NumGoroutine 可以獲取當前程序中正在執行的 goroutine 數量，觀察這個數字可以初步判斷出是否存在 goroutine 洩露異常。

一個示例，如下：

package main

import (
	"net/http"
	"runtime"
	"strconv"
)

func write(w http.ResponseWriter, data []byte) {
	_, _ = w.Write(data)
}

func count(w http.ResponseWriter, r *http.Request) {
	write([]byte(strconv.Itoa(runtime.NumGoroutine())))
}

func main() {
	http.HandleFunc("/_count", count)
	http.ListenAndServe(":6080", nil)
}

功能很簡單，設定 _count 路由請求處理函式 count，它負責輸出服務當前 goroutine 數量。啟動服務後訪問 localhost:6080/_count 即可。

但只是一個數值，我們就能確認是否洩露了嗎？

首先，如果這個數值很大，是不是就能說明出現了洩露。我的答案是否。理由很簡單，高併發情況下的 goroutine 數量肯定很高的，但並非出現了洩露，可能只是當前的服務的承載能力還不夠。我們可以在數量基礎上引入時間，即如果 goroutine 隨著時間增加，數量在不斷上升，而基本沒有下降，基本可以確定存在洩露。我們可以定時採集不同時刻的資料來分析。

演示案例

為了更好的演示效果，我們為服務再增加一個處理函式 query， 並繫結路由 /query 上。假設它負責從多個數據表中查出資料返回給使用者。這個例子在後面的演示會一直使用。

程式碼如下：

func query(w http.ResponseWriter, r *http.Request) {
	c := make(chan byte)

	go func() {
		c <- 0x31
	}()

	go func() {
		c <- 0x32
	}()

	go func() {
		c <- 0x33
	}()

	rs := make([]byte, 0)
	for i := 0; i < 2; i++ {
		rs = append(rs, <-c)
	}

	write(w, rs)
}

在 query 中，我們啟動了 3 個 goroutine 執行資料庫查詢，通過 channel 傳遞返回資料。這裡的問題是，query 函式中只從 channel 中接收兩次資料就退出了迴圈，這會導致其中一個 goroutine 因缺少接收者而無法釋放。

我們可以多次請求 localhost:6080/query，然後通過 _count 檢視服務當前的 goroutine 數量。手動麻煩，可以用 ab 命令進行做個簡單壓測。

$ ab -n 1000 -c 100 localhost:6080/query

命令的意思是，總共訪問 1000 次，併發訪問 100 次。

pprof

前面的例子比較簡單，發現洩露後，我們可以立刻確定存在的問題。但如果比較複雜的專案，我們就很難發現問題程式碼的出現位置了。

如何解決呢？

我們可以引入一個輔助工具，pprof。它是由 Go 官方提供的可用於收集程式執行時報告的工具，其中包含 CPU、記憶體等資訊。當然，也可以獲取執行時 goroutine 堆疊資訊，如此一來，我們就可以很容易看出哪裡導致了 goroutine 洩露。

runtime/pprof

我們可以再加入一個名為 goroutineStack 的 handler，用於檢視程式中 goroutine 的堆疊資訊，，地址為 _goroutine。

實現程式碼如下：

import "runtime/pprof"

func goroutineStack(w http.ResponseWriter, r *http.Request) {
	_ = pprof.Lookup("goroutine").WriteTo(w, 1)
}

訪問 _goroutine，將會得到類似如下的資訊：

goroutine profile: total 1004
948 @ 0x102e70b 0x102e7b3 0x10068ed 0x10066c5 0x1233b37 0x10595d1
#	0x1233b36	main.query.func2+0x36	/Users/polo/Public/Work/go/src/study/goroutine/leak/06/main.go:20

45 @ 0x102e70b 0x102e7b3 0x10068ed 0x10066c5 0x1233ae7 0x10595d1
#	0x1233ae6	main.query.func1+0x36	/Users/polo/Public/Work/go/src/study/goroutine/leak/06/main.go:16

7 @ 0x102e70b 0x102e7b3 0x10068ed 0x10066c5 0x1233b87 0x10595d1
#	0x1233b86	main.query.func3+0x36	/Users/polo/Public/Work/go/src/study/goroutine/leak/06/main.go:24

1 @ 0x102e70b 0x1029ba9 0x1029256 0x108b7da 0x108b8ed 0x108c216 0x112f80f 0x113b348 0x11f5f6a 0x10595d1
#	0x1029255	internal/poll.runtime_pollWait+0x65		/usr/local/go/src/runtime/netpoll.go:173
#	0x108b7d9	internal/poll.(*pollDesc).wait+0x99		/usr/local/go/src/internal/poll/fd_poll_runtime.go:85
#	0x108b8ec	internal/poll.(*pollDesc).waitRead+0x3c		/usr/local/go/src/internal/poll/fd_poll_runtime.go:90
#	0x108c215	internal/poll.(*FD).Read+0x1d5			/usr/local/go/src/internal/poll/fd_unix.go:169
#	0x112f80e	net.(*netFD).Read+0x4e				/usr/local/go/src/net/fd_unix.go:202
#	0x113b347	net.(*conn).Read+0x67				/usr/local/go/src/net/net.go:177
#	0x11f5f69	net/http.(*connReader).backgroundRead+0x59	/usr/local/go/src/net/http/server.go:676

1 @ 0x102e70b 0x1029ba9 0x1029256 0x108b7da 0x108b8ed 0x108c216 0x112f80f 0x113b348 0x11f63ec 0x10fb596 0x10fbf76 0x10fc174 0x119ebbf 0x119eaeb 0x11f315c 0x11f7672 0x11fb23e 0x10595d1
#	0x1029255	internal/poll.runtime_pollWait+0x65		/usr/local/go/src/runtime/netpoll.go:173
#	0x108b7d9	internal/poll.(*pollDesc).wait+0x99		/usr/local/go/src/internal/poll/fd_poll_runtime.go:85
#	0x108b8ec	internal/poll.(*pollDesc).waitRead+0x3c		/usr/local/go/src/internal/poll/fd_poll_runtime.go:90
#	0x108c215	internal/poll.(*FD).Read+0x1d5			/usr/local/go/src/internal/poll/fd_unix.go:169
#	0x112f80e	net.(*netFD).Read+0x4e				/usr/local/go/src/net/fd_unix.go:202
#	0x113b347	net.(*conn).Read+0x67				/usr/local/go/src/net/net.go:177
#	0x11f63eb	net/http.(*connReader).Read+0xfb		/usr/local/go/src/net/http/server.go:786
#	0x10fb595	bufio.(*Reader).fill+0x105			/usr/local/go/src/bufio/bufio.go:100
#	0x10fbf75	bufio.(*Reader).ReadSlice+0x35			/usr/local/go/src/bufio/bufio.go:341
#	0x10fc173	bufio.(*Reader).ReadLine+0x33			/usr/local/go/src/bufio/bufio.go:370
#	0x119ebbe	net/textproto.(*Reader).readLineSlice+0x6e	/usr/local/go/src/net/textproto/reader.go:55
#	0x119eaea	net/textproto.(*Reader).ReadLine+0x2a		/usr/local/go/src/net/textproto/reader.go:36
#	0x11f315b	net/http.readRequest+0x8b			/usr/local/go/src/net/http/request.go:958
#	0x11f7671	net/http.(*conn).readRequest+0x161		/usr/local/go/src/net/http/server.go:966
#	0x11fb23d	net/http.(*conn).serve+0x49d			/usr/local/go/src/net/http/server.go:1788

1 @ 0x102e70b 0x1029ba9 0x1029256 0x108b7da 0x108b8ed 0x108ce80 0x112fd92 0x1142c5e 0x1141967 0x11ff7df 0x121da4c 0x11fed5f 0x11fea16 0x11ff534 0x1233a91 0x102e317 0x10595d1
#	0x1029255	internal/poll.runtime_pollWait+0x65		/usr/local/go/src/runtime/netpoll.go:173
#	0x108b7d9	internal/poll.(*pollDesc).wait+0x99		/usr/local/go/src/internal/poll/fd_poll_runtime.go:85
#	0x108b8ec	internal/poll.(*pollDesc).waitRead+0x3c		/usr/local/go/src/internal/poll/fd_poll_runtime.go:90
#	0x108ce7f	internal/poll.(*FD).Accept+0x19f		/usr/local/go/src/internal/poll/fd_unix.go:384
#	0x112fd91	net.(*netFD).accept+0x41			/usr/local/go/src/net/fd_unix.go:238
#	0x1142c5d	net.(*TCPListener).accept+0x2d			/usr/local/go/src/net/tcpsock_posix.go:139
#	0x1141966	net.(*TCPListener).AcceptTCP+0x46		/usr/local/go/src/net/tcpsock.go:247
#	0x11ff7de	net/http.tcpKeepAliveListener.Accept+0x2e	/usr/local/go/src/net/http/server.go:3232
#	0x11fed5e	net/http.(*Server).Serve+0x22e			/usr/local/go/src/net/http/server.go:2826
#	0x11fea15	net/http.(*Server).ListenAndServe+0xb5		/usr/local/go/src/net/http/server.go:2764
#	0x11ff533	net/http.ListenAndServe+0x73			/usr/local/go/src/net/http/server.go:3004
#	0x1233a90	main.main+0xb0					/Users/polo/Public/Work/go/src/study/goroutine/leak/06/main.go:40
#	0x102e316	runtime.main+0x206				/usr/local/go/src/runtime/proc.go:201

1 @ 0x122ce28 0x122cc30 0x1229694 0x1233723 0x11fc194 0x11fde37 0x11fe8eb 0x11fb3e6 0x10595d1
#	0x122ce27	runtime/pprof.writeRuntimeProfile+0x97			/usr/local/go/src/runtime/pprof/pprof.go:707
#	0x122cc2f	runtime/pprof.writeGoroutine+0x9f			/usr/local/go/src/runtime/pprof/pprof.go:669
#	0x1229693	runtime/pprof.(*Profile).WriteTo+0x3e3			/usr/local/go/src/runtime/pprof/pprof.go:328
#	0x1233722	study/goroutine/leak/06/leak.GoroutineStack+0x92	/Users/polo/Public/Work/go/src/study/goroutine/leak/06/leak/handlers.go:19
#	0x11fc193	net/http.HandlerFunc.ServeHTTP+0x43			/usr/local/go/src/net/http/server.go:1964
#	0x11fde36	net/http.(*ServeMux).ServeHTTP+0x126			/usr/local/go/src/net/http/server.go:2361
#	0x11fe8ea	net/http.serverHandler.ServeHTTP+0xaa			/usr/local/go/src/net/http/server.go:2741
#	0x11fb3e5	net/http.(*conn).serve+0x645				/usr/local/go/src/net/http/server.go:1847

首先是第一行，如下：

goroutine profile: total 1004

統計資訊，和 NumGoroutine 的返回結果相同。當前共有 1004 個 goroutine 在執行。

接下來的部分，主要是具體介紹每個 goroutine 的情況，相同函式的 goroutine 會被合併統計，並按數量從大到小排序。輸出前三段就是我們在 query 函式中開啟的三個 goroutine。

948 @ 0x102e70b 0x102e7b3 0x10068ed 0x10066c5 0x1233b37 0x10595d1
#	0x1233b36	main.query.func2+0x36	/Users/polo/Public/Work/go/src/study/goroutine/leak/06/main.go:20

45 @ 0x102e70b 0x102e7b3 0x10068ed 0x10066c5 0x1233ae7 0x10595d1
#	0x1233ae6	main.query.func1+0x36	/Users/polo/Public/Work/go/src/study/goroutine/leak/06/main.go:16

7 @ 0x102e70b 0x102e7b3 0x10068ed 0x10066c5 0x1233b87 0x10595d1
#	0x1233b86	main.query.func3+0x36	/Users/polo/Public/Work/go/src/study/goroutine/leak/06/main.go:24

分別是 main.query.func1、main.query.func2 以及 main.query.func3，對應於它們，當前仍在執行中的 goroutine 數量分別是 45、948、7。看樣子洩露的 goroutine 函式分佈並非均勻。

幾個函式都是匿名的，如果我們需要確定具體位置，可以通過堆疊實現。比如 func1，明確指出了位於的所在檔案和程式碼行數。

http/net/pprof

前面部分是通過自己編寫程式碼把 goroutine 的分析統計指標加入到了 HTTP 服務中。其實，官方已經實現了這個功能，並且涉及的不僅僅是 goroutine，還有 CPU、記憶體等。

它的操作很簡單，我們只需要在服務啟動時匯入 net/http/pprof 即可。接著訪問地址 /debug/pprof/goroutine?debug=1，將會可以看到與上一節輸出的相同內容。

gops

熟悉 Java 的朋友都知道 jps 這個命令。通過它，我們可以檢視當前機器上有哪些 Java 程式在執行。Go 也有類似的命令，gops，它支援列出當前環境下的 Go 程序，並支援對 Go 程式的診斷。預設情況下，gops 可列出並不支援對程序進行成診斷。

今天，我們將只看它和 goroutine 相關的部分。

一個示例，如下：

$ gops
97778 96800 gops    go1.11.1 /usr/local/go/bin/gops
97605 73594 leaker* go1.11.1 /Users/polo/Public/Work/go/src/study/goroutine/leak/06/leaker

我的環境下當前只有兩個 go 程序在執行。

仔細觀察後，我們會發現 leaker 程序相比 gops 後面多個 * 的標號，而 * 表示這個程式支援通過 gops 診斷。這是因為我們在 leaker 加入了診斷支援的程式碼，如下：

func main() {
	if err := agent.Listen(agent.Options{ShutdownCleanup: true}); err != nil {
		log.Fatalln(err)
	}

	...
}

執行如下命令，檢視當前的 goroutine 數量。

$ gops stats 97605
goroutines: 1004
OS threads: 14
GOMAXPROCS: 8
num CPU: 8

其中，97605 是程序 PID。

結果顯示，當前在執行的 goroutine 有 1004 個。而且，我們還注意到 OS 級別的執行緒才 14 個，可見 goroutine 的輕量。

gops 也可以檢視堆疊，我們只需執行 gops stack PID 即可，這個就不具體演示了。要說明的是，這種方式並不會對執行相同函式的 goroutine 做聚合統計，不知道是我沒找到還是本身不支援。如果的確不支援，也可以自己聚合，但畢竟沒那麼方便。

Leak Test

除了出現問題後的檢測除錯，但如果我們能把洩露檢測過程加入到自動化測試中，在正式上線前就避免，豈不是更完美。我們可以通過一個開源包實現，包的名稱是 leaktest，即洩露測試的意思。

利用 leaktest，我們測試下前面寫的 http 處理函式 query。因為要檢測 handler 是否洩露，如果經過網路就會丟失服務端的相關資訊，這時，我們可以藉助 Go 中的 net/http/test 包完成測試。

程式碼如下：

func Test_Query(t *testing.T) {
	defer leaktest.Check(t)()

	//建立一個請求
	req, err := http.NewRequest("GET", "/query", nil)
	if err != nil {
		t.Fatal(err)
	}

	rr := httptest.NewRecorder()

	//直接使用 query(rr,req)
	query(rr, req)

	// 其他測試
	// ...
}

測試執行輸出如下：

=== RUN   Test_Query
--- FAIL: Test_Query (5.01s)
    leaktest.go:162: leaktest: context canceled
    leaktest.go:168: leaktest: leaked goroutine: goroutine 20 [chan send]:
        study/goroutine/leak/06.query.func2(0xc0001481e0)
        	/Users/polo/Public/Work/go/src/study/goroutine/leak/06/main.go:24 +0x37
        created by study/goroutine/leak/06.query
        	/Users/polo/Public/Work/go/src/study/goroutine/leak/06/main.go:23 +0x7e
FAIL

從輸出資訊中，我們可以明確地知道出現了洩露，並且通過輸出堆疊很快就能定位出現問題的程式碼。測試程式碼非常簡單，在測試函式開始通過 defer 執行 leaktest 的 Check。

它提供的三個檢測函式，分別是 Check、CheckTimeout 和 CheckContext，從前到後的實現一個比一個底層。Check 預設會等待五秒再執行檢測，如果需要改變這個時間，可以使用 CheckTimeout 函式。

leaktest 的實現原理也和堆疊有關，原始碼不多，如果有興趣可以讀讀，原始碼檔案地址。

總結

本系列文章分別從程式碼實現和監控檢測兩個角度介紹瞭如何避免 goroutine 的洩露。Go 的併發降低了併發程式的開發難度，但併發一直都是個比較複雜的話題，為了用好它，必要學習還是不可缺少的。

參考資料

Goroutine leak
gops 工作原理
gops - Go 語言程式檢視和診斷工具
gops — Go 程式診斷分析工具
效能調式：分析並優化 Go 程式
Debugging Go Routine leaks
視訊-Debugging Go routine leaks
HTTP

相關推薦

Go 筆記之如何防止 goroutine 洩露（二）

上篇文章說到，防止 goroutine 洩露可從兩個角度出發，分別是程式碼層面的預防與執行層面的監控檢測。今天，我們來談第二點。

Spring Cloud學習筆記之微服務實現（二）（Spring Boot+Spring Cloud+IDEA）

在【Spring Cloud學習筆記之微服務實現（一）】中，我們實現了微服務，但是在實際的專案中，我們需要實現動態訪問微服務，在此之前，已經介紹了Spring Cloud和Eureka，並且實現了eureka註冊中心。現在我們實現一下動態呼叫。 注：註冊中心的服務在此期間保持啟動狀態。

學習筆記之shell指令碼基礎（二）

Shell----if&for 判斷檔案是否存在 [[email protected] ~]# vi 1.sh [[email protected] ~]# bash -x 1.sh + l=123/121 + '[' '!' -e

床頭筆記之Android開發學習（二）

安卓Android開發環境搭建 之前用Android studio環境搭建，發現因為初學不熟，後面裝的東西太多了，電腦本身就卡，被我直接全卸了，打算用另一種簡單用得比較多的環境先入手。 本次用Eclipse、JDK、Android SDK、ADT外掛、安卓模擬器

android學習筆記之多執行緒（二）

這個需要在輸出，點選start後會隔一會輸出一行字，點end會結束輸出。 Code package tk.handleractivity; import android.app.Activity; import android.os.Bundle; import andr

Javascript高級程序設計--讀書筆記之面向對象（二）

原型鏈 func pro 原型對象 ets span gre {} javascrip 前面講了面向對象的封裝，這章我們就來說一說繼承 1.原型鏈 實現原型鏈有一種基本模式，其代碼大概如下 <script> function Super

STL之set具體解釋（二）

基本操作 二叉樹 mono itl 自己 pair leading 左右子樹 ews 首先來看看set集合容器： set集合容器實現了紅黑樹的平衡二叉樹數據結構。在插入元素時它會自己主動調整二叉樹的排列，把該元素放到適當的位置，而且 保證左右子樹平衡。平衡二

jdk源碼閱讀筆記之java集合框架（四）（LinkedList）

ray private array public 源碼閱讀 jdk源碼閱讀 oid color 解釋 關於LinkedList的分析，會從且僅從其添加（add)方法入手。 因為上一篇已經分析過ArrayList,相似的地方就不再敘述，關註點在LinkedList的特點。 屬

LIVE555研究之五：RTPServer（二）

tpch live555 循環調用 family 每一個 函數 計算 ack close LIVE555研究之五：RTPServer（二） 接上文，main函數的幾行代碼創建了RTSPSe

Java基礎學習筆記十六 集合框架（二）

first 哈希 cat etag 基於 col 容器 處的 新元素 List List接口的特點: 它是一個元素存取有序的集合。例如，存元素的順序是11、22、33。那麽集合中，元素的存儲就是按照11、22、33的順序完成的。 它是一個帶有索引的集合，通過索引就

jenkins實戰之jenkins安裝部署（二）

自動化運維 上一小節介紹了Jenkins安裝（Linux/uninx平臺）,這節我們講講Jenkins界面操作（包括系統設置，工具安裝，插件管理，系統升級，安全設置等等操作）； 登錄jenkins首頁，分別有以下選項欄，從左側看起，點擊Jenkins系統管理我們會看到右側list欄，內

Jmeter之Bean shell使用（二）

.get 方法 tro 邏輯 麻煩 str www title jar 　上一篇Jmeter之Bean shell使用(一)簡單介紹了下Jmeter中的Bean shell，本文是對上文的一個補充，主要總結下常用的幾種場景和方法，相信這些基本可以涵蓋大部分的需求。本節內容如

C#.Net 設計模式學習筆記之創建型 （一）

應用 種類 單件 src nag abstract 子類 指定 相關 1、抽象工廠（Abstract Factory）模式 常規的對象創建方法： //創建一個Road對象 Road road =new Road(); new 的問題： 實現依賴，不能應對“具

讀書筆記--C陷阱與缺陷（二）

ase 結果 erro bit 使用 功能 錯誤 多層 gnu 第二章 1. 理解函數聲明 書中分析了復雜的類型聲明方式，也說明了使用typedef聲明會更好理解，推薦大家使用typedef進行函數聲明。 書中類型分析一層一層挖掘，讓讀者可以理解多層嵌套的類型含義，有

構建之法學習回顧（二）

保持 競爭 增量 版本 工作 集合 tro 以及 完成 　學習完構建之法五到八章之後，發現這本書更加貼近於當代，一般的軟工教材為了追求更廣更久的接受度，在內容上會趨於保守，而這本書不同，許多生硬的知識都得到了新的活力。 在第五章的學習中，主要講了典型的軟件團隊模

EEPROM讀寫學習筆記與I2C總線（二）

一點 後來 並不是 完數 cal 效應 計算 spi 速度慢 無論任何電子產品都會涉及到數據的產生與數據的保存，這個數據可能並不是用來長久保存，只是在運行程序才會用到，有些數據體量較大對於獲取時效性並不太強，各種各樣的數據也就有不同的存儲載體，這次在EEPR

【安全牛學習筆記】手動漏洞挖掘（二）

security+ 漏洞 信息安全 手動漏洞挖掘身份認證 常用弱口令/基於字典的密碼破爆破 鎖定賬號 信息收集 手機號 密碼錯誤提示信息 密碼嗅探手動漏洞挖掘會話sessionID Xss / cookie importer Sess

Appium python自動化測試系列之appium環境搭建（二）

ftp 自動化 手動 文件 搭建環境 做到 安裝python reg 成員 ?2.1 基礎環境搭建 當我們學習新的一項技術開始基本都是從環境搭建開始，本書除了第一章節也是的，如果你連最基礎的環境都沒有那麽我們也沒必要去說太多，大概介紹一下： 1、因為appium是支持and

談談-Android-PickerView系列之源碼解析（二）

需求 動態 () comm tag 多個 來源 ntc 寬高 前言 　　WheelView想必大家或多或少都有一定了解， 它是一款3D滾輪控件，效果類似IOS 上面的UIpickerview 。按照國際慣例，先放一張效果圖： 　　以上是Android-PickerView

linux學習之進程篇（二）

通過 passwd 查看 現在 替換 cnblogs exe -1 stdio.h 進程原語 1.fork #include<unistd.h> pid_t fork(void); 　 fork 　　子進程復制父進程，子進程和父進程的PID是不一樣的，在