有一段時間，咱們的推送服務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都沒法正常結束。在檢查代碼以後，咱們發現了一個可疑的地方，因爲咱們不光有本身的統計，還會將一些統計信息發送到咱們公司的統計平臺，代碼例如如下：socket
ch = make([]byte, 100000)
func send(msg []byte) {
ch <- msg
}
//在還有一個goroutine的地方，
msg <- msg
httpsend(msg)
咱們channel的緩存分配了10w，假設公司統計平臺出現了問題，可能會致使channel堵塞。但到底是不是這個緣由呢？函數
幸運的是，咱們先前已經在代碼裏面內置了pprof的功能，經過pprof goroutine的信息，發現大量的goroutine的當前執行函數在httpsend裏面，也就是說，公司的統計平臺在大併發如下服務不可用，儘管咱們有http超時的處理，但是因爲發送的數據量太頻繁，致使整體堵塞。ui
暫時的解決的方法就是關閉了統計信息的發送，興許咱們會考慮將其發送到本身的mq上面，儘管也可能會出現mq服務不可用的問題，但是說句實話，比起本身實現的mq，公司的統計平臺更讓我不可信。spa
這同一時候也給了我一個教訓，訪問外部服務必定要好優勢理外部服務不可用的狀況，即便可用，也要考慮壓力問題。code
對於pprof怎樣查看了goroutine的問題，可以經過一個簡單的樣例說明:it
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的信息，僅列出關鍵信息：class
goroutine profile: total 10004 10000 @ 0x186f6 0x616b 0x6298 0x2033 0x188c0 # 0x2033 main.f+0x33 /Users/siddontang/test/pprof.go:11
可以看到，在main.f這個函數中，有10000個goroutine正在運行，符合咱們的預期。test
在go裏面，還有很是多執行時查看機制，可以很是方便的幫咱們定位程序問題，不得不讚一下。