golang 内存管理

对象池

• 在每次开始执行垃圾回收时，都会清除所有已创建的临时对象池中的值
  
  
  
• 一个固定大小，不会被GC的内存池
  • 主要优势是不会被GC。缺点是少了收缩性，设置大了浪费内存，设置小了复用作用不明显
  • 适用于能够提前预估池子大小的场景
    • 在实践中，我们将其用在DB序列化层，其Worker数量固定，单个[]byte较大，也相对稳定

堆栈(逃逸分析）

• Go 有两个地方可以分配内存：
  • 全局堆空间用来动态分配内存
  • 每个 goroutine 都有的自身栈空间
• Go 更倾向于在栈空间上分配内存，因为它的代价更低
  • 只需要两个 CPU 指令：一个是把数据 push 到栈空间上以完成分配，另一个是从栈空间上释放
  • malloc（堆分配）必须找到一块足够大的内存来存放新的变量数据，后续垃圾回收器还需要扫描堆空间寻找不再被使用的对象
• 在栈上分配要求一个变量的生命周期和内存足迹能在编译时确定，否则就需要在运行时在堆空间上进行动态分配
  • 编译器使用逃逸分析来在这两者间做选择
  • 编译器会追踪变量在代码块上的作用域，如果它的整个生命周期是否在运行时完全可知，它就可以在栈上分配。否则就说它逃逸了，必须在堆上分配
• 逃逸到堆上的典型情况
  • 函数返回变量地址，或返回包含变量地址的struct
  • 发送指针或带有指针的值到 channel 或sync.Pool中
    • 编译时没有办法知道哪个 goroutine 会在 channel 上接收数据，所以编译器没法知道变量什么时候才会被释放
  • 在切片上存储指针或带指针的值，例如 []*string
    • 这会导致切片的内容逃逸，尽管数组可能是在栈上分配的，但其引用的值一定是在堆上
  • 在 interface 类型上调用方法
    • 在 interface 类型上调用方法都是动态调度的, 方法的真正实现只能在运行时知道
  • 闭包也可能导致闭包上下文逃逸
  • slice变量超过cap重新分配时，将在堆上进行
  • 将变量地址赋给可扩容容器(如map,slice)时
    

内存分配

指针

• 指针指向的数据都是在堆上分配的
  • 在程序中减少指针的运用可以减少堆分配
• 有时直接的值拷贝要比使用指针廉价的多
  
• 不要掉进过早优化的陷阱，养成一个按值传递的习惯，只在需要的时候用指针传递
  • 一个好处就是可以较少 nil 带来的安全问题
  • 另一个好处是如果可以证明它里面没有指针，垃圾回收器会直接越过这块内存
    • 例如一块作为 []byte 背后存储的堆上内存，是不需要进行扫描的
  • 减少指针的使用不仅可以降低垃圾回收的工作量，还能产生对 cache 更加友好的代码
    • 要把数据从主内存读到 CPU 的 cache 中，由此产生的 cache 抖动会引起线上服务的一些意外的和突然的抖动

内联

• 对Interface的方法调用不能被内联
  • 直接用Struct，借助于内联，字段访问会快一个数量级
• 过于激进的内联会导致生成的二进制文件更大，CPU instruction cache miss也可能会增加
• 内联可以减少逃逸到堆上的情况
  • 否则即使是简单函数，只要返回指针都会逃逸

参考

• https://mp.weixin.qq.com/s?__biz=Mzg2MDU1Mjc3MQ==&mid=2247489727&idx=1&sn=6191494e579eff35afdecf4bffc93fd6&source=41#wechat_redirect
• https://wudaijun.com/2019/09/go-performance-optimization/