自古以來(lái),JSON序列化就是兵家必爭(zhēng)之地

上文講到使用ioutil.ReadAll讀取大的Response Body，出現(xiàn)讀取Body超時(shí)的問(wèn)題。

01

前人引路

Stackoverflow[1]的morganbaz的看法是：

使用iotil.ReadAll去讀取go語(yǔ)言里大的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è)更有效的方式來(lái)解析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)存來(lái)容納數(shù)據(jù)讀取——它可以簡(jiǎn)單地重用一個(gè)很小的緩沖區(qū)來(lái)獲取所有的數(shù)據(jù)并漸進(jìn)式解析。這為內(nèi)存分配節(jié)省了大量時(shí)間，并消除了GC的壓力?JSON Decoder可以在第一個(gè)數(shù)據(jù)塊進(jìn)入時(shí)開(kāi)始解析數(shù)據(jù)——它不需要等待所有東西完成下載。

02

后人乘涼

我針對(duì)前人的思路補(bǔ)充兩點(diǎn)。

①.官方ioutil.ReadAll是通過(guò)初始大小為512字節(jié)的切片來(lái)讀取reader，我們的response body大概50M， 很明顯會(huì)頻繁觸發(fā)切片擴(kuò)容，產(chǎn)生不必要的內(nèi)存分配，給gc也帶來(lái)壓力。

go切片擴(kuò)容的時(shí)機(jī)：需求小于256字節(jié)，按照2倍擴(kuò)容；超過(guò)256字節(jié)，按照1.25倍擴(kuò)容。

? ? ②?.怎么理解morganbaz所說(shuō)的帶來(lái)的內(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ì)帶來(lái)內(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)存泄漏。

03

JSON序列化是兵家必爭(zhēng)之地

morganbaz大佬提出使用標(biāo)準(zhǔn)庫(kù)encoding/json來(lái)邊讀邊反序列化， 減少內(nèi)存分配， 加快反序列化速度。

自古以來(lái)，JSON序列化就是兵家必爭(zhēng)之地[2]，各大語(yǔ)言內(nèi)部均對(duì)序列化有不同的實(shí)現(xiàn)思路，性能相差較大。

下面使用高性能json序列化庫(kù)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("開(kāi)始請(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開(kāi)發(fā)的HttpClient讀取Body超時(shí)

04

我的收獲

1.ioutil.ReadAll 讀取大的response.body的風(fēng)險(xiǎn)：性能差且有內(nèi)存泄漏的風(fēng)險(xiǎn)。2.隱式內(nèi)存泄漏：對(duì)于高并發(fā)、長(zhǎng)時(shí)間運(yùn)行的web程序，不及時(shí)釋放內(nèi)存最終也會(huì)導(dǎo)致內(nèi)存耗盡。3.json 序列化是兵家必爭(zhēng)之地， json-iterator 是兼容標(biāo)準(zhǔn)encode/json api 用法的高性能序列化器。4.pprof 內(nèi)存診斷的姿勢(shì) & 調(diào)試指標(biāo)的意義。

引用鏈接

[1]?Stackoverflow:?https://stackoverflow.com/questions/52539695/alternative-to-ioutil-readall-in-go
[2]?自古以來(lái)，JSON序列化就是兵家必爭(zhēng)之地:?https://yalantis.com/blog/speed-up-json-encoding-decoding/
[3]?實(shí)踐pprof:?https://segmentfault.com/a/1190000016412013

有態(tài)度的馬甲建立了真●?高質(zhì)量交流群：大佬匯聚、無(wú)事靜默、有事激活、深度思考。

年終總結(jié)：2021技術(shù)文大盤(pán)點(diǎn) ?| ?打包過(guò)去，面向未來(lái)

項(xiàng)目總結(jié)：麻雀雖小，五臟俱全

理念總結(jié)：實(shí)話實(shí)說(shuō)：只會(huì).NET，會(huì)讓我們一直處于鄙視鏈、食物鏈的下游

云原生系列：?什么是云原生？

點(diǎn)“贊”戳“在看”

體現(xiàn)態(tài)度很有必要!