go內存泄露case

用go寫了一個守護進程程序：用於檢測redis的存活狀態並將結果寫到zookeeper中，部署到redis機器上。對於每個redis實例會有一個goroutine每隔固定時間去檢測其狀態，由主goroutine負責信號處理等。再接收到信號時kill其它的goroutine。程序執行了一段時間發現，有些redis實例的相應zookeeper的信息不更新。經過日誌發現相應redis的goroutine掛掉了。

閱讀源代碼發現貌似是zk的第三方庫拋出一個非預期的異常致使。

爲了解決問題，對邏輯重構：由主goroutine每隔固定時間，對於每個redis實例啓動一個goroutine去進行檢測，避免出現非預期異常致使goroutine掛掉，從而狀態信息不更新的狀況。

由於goroutine的建立開銷很是低，並且golang官方推薦使用大量的goroutine來抗併發，因此這樣的方式實現也很是合理。重構完。上線測試發現存在內存泄露。

（1）觀察GC

首先對代碼review，由於半年前寫的，並且近期都沒用golang，因此沒有發現bug。

接着，就想看下gc相關的信息。或許可能透漏些東西。網上查了golang 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的輸出，發現當前堆上對象總數不斷增多，沒有下降的趨勢。這說明存在對象的泄露，從而致使內存泄露。

（2）memory profile

依據golang官網profile指南，在代碼中加入

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可以顯示所有分配的對象（包含垃圾對象）。

只是這兩種方式都沒有發現異常。

（3）監控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個數不斷添加，沒有銷燬的跡象。

（4）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泄露了。

（5）總結

- goroutine的管理很是重要，假設goroutine泄露，就會存在內存泄露

- 內嵌http server，用於查看程序執行狀態

- 眼下。go的gc還比較脆弱，儘可能下降對象的建立。能緩存的就緩存。由於對象多了的話，掃描的時間也會加長