golang使用pprof檢查goroutine泄露

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

有一段時間，我們的推送服務socket佔用非常不正常，我們自己統計的同一時候線上就10w的使用者，可是佔用的socket居然達到30w，然後查看goroutine的數量，發現已經60w+。

每一個使用者佔用一個socket，而一個socket，有read和write兩個goroutine，簡化的代碼例如以下：

c, _ := listerner.Accept()go c.run()func (c *conn) run() {    go c.onWrite()    c.onRead()}func (c *conn) onRead() {    stat.AddConnCount(1)    //on something    stat.AddConnCount(-1)    //clear    //notify onWrite to quit}

當時我就懷疑，使用者同一時候線上的統計是正確的，也就是之後的clear階段出現了問題，導致兩個goroutine都無法正常結束。在檢查代碼之後，我們發現了一個可疑的地方，由於我們不光有自己的統計，還會將一些統計資訊發送到我們公司的統計平台，代碼例如以下：

ch = make([]byte, 100000)func send(msg []byte) {    ch <- msg}//在還有一個goroutine的地方，msg <- msghttpsend(msg)

我們channel的緩衝分配了10w，假設公司統計平台出現了問題，可能會導致channel堵塞。但究竟是不是這個原因呢？

幸運的是，我們先前已經在代碼裡面內建了pprof的功能，通過pprof goroutine的資訊，發現大量的goroutine的當前執行函數在httpsend裡面，也就是說，公司的統計平台在大並發以下服務不可用，儘管我們有http逾時的處理，可是由於發送的資料量太頻繁，導致總體堵塞。

暫時的解決的方法就是關閉了統計資訊的發送，興許我們會考慮將其發送到自己的mq上面，儘管也可能會出現mq服務停用問題，可是說句實話，比起自己實現的mq，公司的統計平台更讓我不可信。

這同一時候也給了我一個教訓，訪問外部服務一定要好優點理外部服務停用情況，即使可用，也要考慮壓力問題。

對於pprof怎樣查看了goroutine的問題，能夠通過一個簡單的範例說明:

package mainimport (    "net/http"    "runtime/pprof")var quit chan struct{} = make(chan struct{})func f() {    <-quit}func handler(w http.ResponseWriter, r *http.Request) {    w.Header().Set("Content-Type", "text/plain")    p := pprof.Lookup("goroutine")    p.WriteTo(w, 1)}func main() {    for i := 0; i < 10000; i++ {        go f()    }    http.HandleFunc("/", handler)    http.ListenAndServe(":11181", nil)}

這上面的範例中，我們啟動了10000個goroutine，並堵塞，然後通過訪問http://localhost:11181/，我們就能夠得到整個goroutine的資訊，僅列出關鍵資訊：

goroutine profile: total 1000410000 @ 0x186f6 0x616b 0x6298 0x2033 0x188c0#   0x2033  main.f+0x33 /Users/siddontang/test/pprof.go:11

能夠看到，在main.f這個函數中，有10000個goroutine正在運行，符合我們的預期。

在go裡面，還有非常多執行時查看機制，能夠非常方便的幫我們定位程式問題，不得不贊一下。