上文讲到使用ioutil.ReadAll读取大的Response Body，出现读取Body超时的问题。
前人引路
Stackoverflow的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可以在第一个数据块进入时开始解析数据——它不需要等待所有东西完成下载。
后人乘凉
这里我针对前人的思路补充两点。
- 官方ioutil.ReadAll是通过初始大小为512字节的切片来读取reader，我们的response body大概50M， 很明显会频繁触发切片扩容，产生不必要的内存分配，给gc也带来压力。
go切片扩容的时机：需求小于256字节，按照2倍扩容；超过256字节，按照1.25倍扩容。
- 怎么理解morganbaz所说的带来的内存泄漏的风险？
内存泄漏是指程序已动态分配的堆内存由于某种原因未释放，造成系统内存浪费，导致程序运行速度减慢升职系统崩溃等严重后果。
ioutil.ReadAll读取大的Body会触发切片扩容，讲道理这种做法只会带来内存浪费，最终会被gc释放，原作者为什么会强调有内存泄漏的风险？
我咨询了一些童靴，对于需要长时间运行的高并发服务器程序，不及时释放内存也可能导致最终耗尽系统所有内存，这是一种隐式内存泄漏。
自古以来，JSON序列化就是兵家必争之地
morganbaz大佬提出使用标准库encoding/json来边读边反序列化，
减少内存分配， 加快反序列化速度。
自古以来，JSON序列化就是兵家必争之地，各大语言均对序列化有不同的实现思路，性能相差较大。
下面我们使用高性能json序列化库json-iterator与原生ioutil.ReadAll+ json.Unmarshal方式做对比。
顺便也检验我最近实践pprof的成果。
# 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 分配内存 和inuse_space常驻内存， 这两者的差值可粗略理解为gc释放的部分。
从结果看json-iterator相比io.ReadAll + json.Unmarshal 分配内存是比较小的。
我的收获
1.ioutil.ReadAll 读取大的response.body的风险：性能差且有内存泄漏的风险
2.隐式内存泄漏：对于高并发、长时间运行的web程序，不及时释放内存最终也会导致内存耗尽。
3.json 序列化是兵家必争之地， json-iterator 是兼容标准encode/json api 用法的高性能序列化器
4.pprof 内存诊断的姿势 & 调试指针的意义。
