协程-泄露
什么是goroutine leak
goroutine leak，是go協程泄漏，什么是go協程泄漏，通俗來說，開啟了一個goroutine，用完后，我們要正確讓其結束。如果它沒用了，還沒結束，那就是goroutine leak。
泄漏的goroutine占用一部分cpu，還可能占著一些其他資源，從而影響主協程效率，有時甚至產生異常。
我們看下面的一個例子。
例子中我們的主協程需要通過某遠程服務查詢到一個結果。使用一個multiQuery的函數啟動多個協程，分別向不同的服務器發起查詢，只要收到一個服務器返回，multiQeury就返回結果
package mainimport ("fmt""math/rand""time" )func queryFromSrc(src string) (ret string) {nanoSec := time.Now().Nanosecond()rand.Seed(int64(nanoSec))sec := (rand.Int31() % 10) + 1// time sleep simulates dns lookup and querytime.Sleep(time.Second * time.Duration(sec))ret = fmt.Sprintf("src=%s use sec=%d", src, sec)fmt.Println("a query ok, ret=", ret)return ret }func multiQuery() (ret string) {res := make(chan string, 3)go func() {res <- queryFromSrc("ns1.dnsserver.com")}()go func() {res <- queryFromSrc("ns2.dnsserver.com")}()go func() {res <- queryFromSrc("ns3.dnsserver.com")}()return <-res }func main() {fmt.Println("start multi query:")res := multiQuery()fmt.Println("res=", res)//time.Sleep(time.Second * 20) }本案例使用了一個帶緩沖區的channel，multiQuery中的三個并行go func不分先后從遠程獲取一個結果返回。獲取的結果寫入channel res，在第一個結果收到后，multiQuery就返回。返回的結果肯定是三個go func中最快返回的。(go func 中的queryFromSrc使用time.Sleep(random)來模擬不同請求延時)。顯然，當第一個結果返回后，multiQuery函數就結束了，而其他兩個go func還在等待返回。
如果我們使用不帶緩沖區的channel，兩個慢的goroutine將會卡在嘗試去發送他們的結果到同一個channel，而這個channel將沒有任何一個goroutine去讀。因為multiQeury已經執行結束。這種情況叫做goroutine leak。與gc回自動回收的變量不同，泄漏的goroutine不會自動被回收。
所以編程中一定要注意，不使用的goroutine要讓其正確地終止
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的輸出，發現當前堆上對象總數不斷增多，沒有減少的趨勢，這說明存在對象的泄露，從而導致內存泄露
memory profile
根據golang官網profile指南?http://blog.golang.org/profiling-go-programs?，在代碼中添加
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可以顯示所有分配的對象（包括垃圾對象）。不過這兩種方式都沒有發現異常
監控goroutine個數
通過runtime.NumGoroutine()可以獲取當前的goroutine的個數。通過給程序添加http server獲取一些統計信息來了解程序的運行狀態，這是Jeff Dean推崇的方法。通過添加下述代碼來實時查看goroutine的個數
// goroutine stats and pprofgo 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個數不斷增加，沒有銷毀的跡象
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泄露了
總結
