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