本文轉自：http://studygolang.com/articles/2701
一、GC信息的信息收集
設置環境變量GODEBUG=gctrace=1。
使用方法，如果程序爲myserver。正常的啓動方法爲./myserver，如果需要收集GC信息啓動方式如下GODEBUG=gctrace=1 ./myserver。
二、GC信息分析
gc5(6): 11+12+357+77 us, 0 -> 1 MB, 4294 (5261-967) objects, 67/2/0 sweeps, 6(115) handoff, 6(9) steal, 170/56/5 yields
gc5(6)：表示第5次GC，共有6個線程參與GC。
11+12+357+77 us：表示停止各個goroutine花費時間是11us，釋放標記對象所有時間爲12us，掃描標記可回收對象花費時間爲257us，完成各個線程結束爲17us。GC總時間爲457us。
0 -> 1 MB：表示上次GC後堆佔用的空間爲0MB，本次GC前堆佔用的空間爲1MB。
4294 (5261-967) objects：表示剩餘未釋放對象個數爲4294個，GC之前擁有對象爲5261個，本次GC釋放對象967個。
基本規律是當前對象越多，掃描時間越長，需要釋放的對象越多，釋放過程越長。
三、GC需要注意的事情
因爲golang中GC過程中需要把程序中所有goroutine全部停止，造成程序就像夯住一樣，所以對於實時性要求比較高的程序要慎重使用golang語言。一個可以參考的建議，如果想要減少gc時間，就要減少對象數量，所以，如果可以儘量在代碼中將對象進行復用。以減少臨時對象數量，從而減少GC時間。
當然GC是可以關閉的，這樣對於實時性要求高的程序可以推薦一種實現模式：
用一個主進程fock出兩個子進程，兩個子進程輪流提供服務，先讓一個子進程提供服務，另一個子進程休眠。當提供服務的子進程工作一段時間後對象數量累計過多時，喚醒另一個子進程開始工作，本子進程開始GC，GC後進入休眠等待被喚醒。這樣就避免掉了因爲GC問題引起的不定時夯住的問題。
四、建議
對於實時性要求比較高的程序，一定要關注GC問題。因爲golang的GC非常稚嫩，與java相比還差的很遠，如果你不關心GC問題，很可能會引起項目的失敗。也許將來golang的GC做的像java一樣優秀，那上面所說的就沒用了。
五、參考：
https://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs
