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 <- msg
httpsend(msg)

咱們channel的緩存分配了10w，若是公司統計平臺出現了問題，可能會致使channel阻塞。但究竟是不是這個緣由呢？

幸運的是，咱們先前已經在代碼裏面內置了pprof的功能，經過pprof goroutine的信息，發現大量的goroutine的當前運行函數在httpsend裏面，也就是說，公司的統計平臺在大併發下面服務不可用，雖然咱們有http超時的處理，可是由於發送的數據量太頻繁，致使總體阻塞。

臨時的解決辦法就是關閉了統計信息的發送，後續咱們會考慮將其發送到本身的mq上面，雖然也可能會出現mq服務不可用的問題，可是說句實話，比起本身實現的mq，公司的統計平臺更讓我不可信。

這同時也給了我一個教訓，訪問外部服務必定要好好處理外部服務不可用的狀況，即便可用，也要考慮壓力問題。

對於pprof如何查看了goroutine的問題，能夠經過一個簡單的例子說明:

package main

import (
    "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 10004

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

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

在go裏面，還有不少運行時查看機制，能夠很方便的幫咱們定位程序問題，不得不讚一下。