用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 yieldsgc781：從程序啟動開始，第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還比較脆弱，盡量降低對象的創建。能緩存的就緩存。因為對象多了的話，掃描的時間也會加長