自古以来,JSON序列化就是兵家必争之地-轻识

上文讲到使用ioutil.ReadAll读取大的Response Body，出现读取Body超时的问题。

前人引路

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可以在第一个数据块进入时开始解析数据——它不需要等待所有东西完成下载。

后人乘凉

我针对前人的思路补充两点。

①.官方ioutil.ReadAll是通过初始大小为512字节的切片来读取reader，我们的response body大概50M，很明显会频繁触发切片扩容，产生不必要的内存分配，给gc也带来压力。

go切片扩容的时机：需求小于256字节，按照2倍扩容；超过256字节，按照1.25倍扩容。

② .怎么理解morganbaz所说的带来的内存泄漏的风险？

内存泄漏是指程序已动态分配的堆内存由于某种原因未释放，造成系统内存浪费，导致程序运行速度减慢升职系统崩溃等严重后果。

ioutil.ReadAll读取大的Body会触发切片扩容，讲道理这种做法只会带来内存浪费，最终会被gc释放，原作者为什么会强调有内存泄漏的风险？

我咨询了一些童靴，对于需要长时间运行的高并发服务器程序，不及时释放内存也可能导致最终耗尽系统所有内存，这是一种隐式内存泄漏。

JSON序列化是兵家必争之地

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超时

我的收获

1.ioutil.ReadAll 读取大的response.body的风险：性能差且有内存泄漏的风险。2.隐式内存泄漏：对于高并发、长时间运行的web程序，不及时释放内存最终也会导致内存耗尽。3.json 序列化是兵家必争之地， json-iterator 是兼容标准encode/json api 用法的高性能序列化器。4.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

有态度的马甲建立了真● 高质量交流群：大佬汇聚、无事静默、有事激活、深度思考。

年终总结：2021技术文大盘点 | 打包过去，面向未来

项目总结：麻雀虽小，五脏俱全

理念总结：实话实说：只会.NET，会让我们一直处于鄙视链、食物链的下游

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

点“赞”戳“在看”

体现态度很有必要!