自古以來，JSON序列化就是兵家必爭之地
上文講到使用ioutil.ReadAll讀取大的Response Body，出現讀取Body超時的問題。
01前人引路
Stackoverflow[1]的morganbaz的看法是：
使用iotil.ReadAll去讀取go語言里大的Response Body，是非常低效的; 另外如果Response Body足夠大，還有內存泄漏的風險。
data,err:= iotil.ReadAll(r)
if err != nil {
return err
}
json.Unmarshal(data, &v)
有一個更有效的方式來解析json數據，會用到Decoder類型
err := json.NewDecoder(r).Decode(&v)
if err != nil {
return err
}
這種方式從內存和時間角度，不但更簡潔，而且更高效。
- Decoder不需要分配一個巨大的字節內存來容納數據讀取——它可以簡單地重用一個很小的緩沖區來獲取所有的數據并漸進式解析。這為內存分配節省了大量時間，并消除了GC的壓力
- JSON Decoder可以在第一個數據塊進入時開始解析數據——它不需要等待所有東西完成下載。
02后人乘涼
我針對前人的思路補充兩點。
①.官方ioutil.ReadAll是通過初始大小為512字節的切片來讀取reader，我們的response body大概50M， 很明顯會頻繁觸發切片擴容，產生不必要的內存分配，給gc也帶來壓力。
go切片擴容的時機：需求小于256字節，按照2倍擴容;超過256字節，按照1.25倍擴容。
② .怎么理解morganbaz所說的帶來的內存泄漏的風險?
內存泄漏是指程序已動態分配的堆內存由于某種原因未釋放，造成系統內存浪費，導致程序運行速度減慢升職系統崩潰等嚴重后果。
ioutil.ReadAll讀取大的Body會觸發切片擴容，講道理這種做法只會帶來內存浪費，最終會被gc釋放，原作者為什么會強調有內存泄漏的風險?
我咨詢了一些童靴，對于需要長時間運行的高并發服務器程序，不及時釋放內存也可能導致最終耗盡系統所有內存，這是一種隱式內存泄漏。
03JSON序列化是兵家必爭之地
morganbaz大佬提出使用標準庫encoding/json來邊讀邊反序列化， 減少內存分配， 加快反序列化速度。
自古以來，JSON序列化就是兵家必爭之地[2]，各大語言內部均對序列化有不同的實現思路，性能相差較大。
下面使用高性能json序列化庫json-iterator與原生ioutil.ReadAll+ json.Unmarshal方式做對比。
順便也檢驗我最近實踐pprof[3]的成果
# go get "github.com/json-iterator/go"
package main
import (
"bytes"
"flag"
"log"
"net/http"
"os"
"runtime/pprof"
"time"
jsoniter "github.com/json-iterator/go"
)
var cpuprofile = flag.String("cpuprofile", "", "write cpu profile to file.")
var memprofile = flag.String("memprofile", "", "write mem profile to file")
func main() {
flag.Parse()
if *cpuprofile != "" {
f, err := os.Create(*cpuprofile)
if err != nil {
log.Fatal(err)
}
pprof.StartCPUProfile(f)
defer pprof.StopCPUProfile()
}
c := &http.Client{
Timeout: 60 * time.Second,
// Transport: tr,
}
body := sendRequest(c, http.MethodPost)
log.Println("response body length:", body)
if *memprofile != "" {
f, err := os.Create(*memprofile)
if err != nil {
log.Fatal("could not create memory profile: ", err)
}
defer f.Close() // error handling omitted for example
if err := pprof.WriteHeapProfile(f); err != nil {
log.Fatal("could not write memory profile: ", err)
}
}
}
func sendRequest(client *http.Client, method string) int {
endpoint := "http://xxxxx.com/table/instance?method=batch_query"
expr := "idc in (logicidc_hd1,logicidc_hd2,officeidc_hd1)"
var json = jsoniter.ConfigCompatibleWithStandardLibrary
jsonData, err := json.Marshal([]string{expr})
log.Println("開始請求:" + time.Now().Format("2006-01-02 15:04:05.010"))
response, err := client.Post(endpoint, "application/json", bytes.NewBuffer(jsonData))
if err != nil {
log.Fatalf("Error sending request to api endpoint, %+v", err)
}
log.Println("服務端處理結束, 準備接收Response:" + time.Now().Format("2006-01-02 15:04:05.010"))
defer response.Body.Close()
var resp Response
var records = make(map[string][]Record)
resp.Data = &records
err= json.NewDecoder(response.Body).Decode(&resp)
if err != nil {
log.Fatalf("Couldn't parse response body, %+v", err)
}
log.Println("客戶端讀取+解析結束:" + time.Now().Format("2006-01-02 15:04:05.010"))
var result = make(map[string]*Data, len(records))
for _, r := range records[expr] {
result[r.Ins.Id] = &Data{Active: "0", IsProduct: true}
}
return len(result)
}
# 省略了反序列化的object type
內存對比
非單純序列化對比，前者對后者優化的效果反饋。
--- json-iterator邊讀 邊反序列化 ---
--- io.ReadAll + json.Unmarshal 反序列化---
我們可以點進去看io.ReadAll + json.Unmarshal內存耗在哪里?
Total: 59.59MB 59.59MB (flat, cum) 100%
626 . . func ReadAll(r Reader) ([]byte, error) {
627 . . b := make([]byte, 0, 512)
628 . . for {
629 . . if len(b) == cap(b) {
630 . . // Add more capacity (let append pick how much).
631 59.59MB 59.59MB b = append(b, 0)[:len(b)]
632 . . }
633 . . n, err := r.Read(b[len(b):cap(b)])
634 . . b = b[:len(b)+n]
635 . . if err != nil {
636 . . if err == EOF {
從上圖也可以印證io.ReadAll 為存儲整個Response.Body對初始512字節的切片不斷擴容， 產生常駐內存59M。
你還可以對比alloc_space 分配內存 ，(alloc_space、inuse_space 的差值可粗略理解為gc釋放的部分)。
從結果看json-iterator相比io.ReadAll + json.Unmarshal 動態分配的內存還是比較小的。
ref：排查go開發的HttpClient讀取Body超時
04我的收獲
- ioutil.ReadAll 讀取大的response.body的風險：性能差且有內存泄漏的風險。
- 隱式內存泄漏：對于高并發、長時間運行的web程序，不及時釋放內存最終也會導致內存耗盡。
- json 序列化是兵家必爭之地， json-iterator 是兼容標準encode/json api 用法的高性能序列化器。
- pprof 內存診斷的姿勢 & 調試指標的意義。
引用鏈接
[1] Stackoverflow: https://stackoverflow.com/questions/52539695/alternative-to-ioutil-readall-in-go
[2] 自古以來，JSON序列化就是兵家必爭之地: https://yalantis.com/blog/speed-up-json-encoding-decoding/
[3] 實踐pprof: https://segmentfault.com/a/1190000016412013
