自古以來，JSON序列化就是兵家必爭之地
上文講到使用ioutil.ReadAll讀取大的Response Body，出現(xiàn)讀取Body超時的問題。
01前人引路
Stackoverflow[1]的morganbaz的看法是：
使用iotil.ReadAll去讀取go語言里大的Response Body，是非常低效的; 另外如果Response Body足夠大，還有內(nèi)存泄漏的風險。
data,err:= iotil.ReadAll(r)
if err != nil {
return err
}
json.Unmarshal(data, &v)
有一個更有效的方式來解析json數(shù)據(jù)，會用到Decoder類型
err := json.NewDecoder(r).Decode(&v)
if err != nil {
return err
}
這種方式從內(nèi)存和時間角度，不但更簡潔，而且更高效。
- Decoder不需要分配一個巨大的字節(jié)內(nèi)存來容納數(shù)據(jù)讀取——它可以簡單地重用一個很小的緩沖區(qū)來獲取所有的數(shù)據(jù)并漸進式解析。這為內(nèi)存分配節(jié)省了大量時間，并消除了GC的壓力
- JSON Decoder可以在第一個數(shù)據(jù)塊進入時開始解析數(shù)據(jù)——它不需要等待所有東西完成下載。
02后人乘涼
我針對前人的思路補充兩點。
①.官方ioutil.ReadAll是通過初始大小為512字節(jié)的切片來讀取reader，我們的response body大概50M， 很明顯會頻繁觸發(fā)切片擴容，產(chǎn)生不必要的內(nèi)存分配，給gc也帶來壓力。
go切片擴容的時機：需求小于256字節(jié)，按照2倍擴容;超過256字節(jié)，按照1.25倍擴容。
② .怎么理解morganbaz所說的帶來的內(nèi)存泄漏的風險?
內(nèi)存泄漏是指程序已動態(tài)分配的堆內(nèi)存由于某種原因未釋放，造成系統(tǒng)內(nèi)存浪費，導(dǎo)致程序運行速度減慢升職系統(tǒng)崩潰等嚴重后果。
ioutil.ReadAll讀取大的Body會觸發(fā)切片擴容，講道理這種做法只會帶來內(nèi)存浪費，最終會被gc釋放，原作者為什么會強調(diào)有內(nèi)存泄漏的風險?
我咨詢了一些童靴，對于需要長時間運行的高并發(fā)服務(wù)器程序，不及時釋放內(nèi)存也可能導(dǎo)致最終耗盡系統(tǒng)所有內(nèi)存，這是一種隱式內(nèi)存泄漏。
03JSON序列化是兵家必爭之地
morganbaz大佬提出使用標準庫encoding/json來邊讀邊反序列化， 減少內(nèi)存分配， 加快反序列化速度。
自古以來，JSON序列化就是兵家必爭之地[2]，各大語言內(nèi)部均對序列化有不同的實現(xiàn)思路，性能相差較大。
下面使用高性能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("服務(wù)端處理結(jié)束, 準備接收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("客戶端讀取+解析結(jié)束:" + 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
內(nèi)存對比
非單純序列化對比，前者對后者優(yōu)化的效果反饋。
--- json-iterator邊讀 邊反序列化 ---
--- io.ReadAll + json.Unmarshal 反序列化---
我們可以點進去看io.ReadAll + json.Unmarshal內(nèi)存耗在哪里?
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字節(jié)的切片不斷擴容， 產(chǎn)生常駐內(nèi)存59M。
你還可以對比alloc_space 分配內(nèi)存 ，(alloc_space、inuse_space 的差值可粗略理解為gc釋放的部分)。
從結(jié)果看json-iterator相比io.ReadAll + json.Unmarshal 動態(tài)分配的內(nèi)存還是比較小的。
ref：排查go開發(fā)的HttpClient讀取Body超時
04我的收獲
- ioutil.ReadAll 讀取大的response.body的風險：性能差且有內(nèi)存泄漏的風險。
- 隱式內(nèi)存泄漏：對于高并發(fā)、長時間運行的web程序，不及時釋放內(nèi)存最終也會導(dǎo)致內(nèi)存耗盡。
- json 序列化是兵家必爭之地， json-iterator 是兼容標準encode/json api 用法的高性能序列化器。
- pprof 內(nèi)存診斷的姿勢 & 調(diào)試指標的意義。
引用鏈接
[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
