Go 性能优化及自动内存管理 | 青训营笔记

这是我参与「第五届青训营」伴学笔记创作活动的第 4 天

目录

• 性能优化
• 自动内存管理
• GO内存管理及优化
• 编译器和静态分析
• Go编译器优化

0. 性能优化

• 即提升软件系统的处理能力，比如每秒可处理的数据量，在一些海量数据的处理场景下性能优化是极其重要的一个环节
• 通过性能优化，我们将用户的体验感提升了一个档次，比如双十一的购物，平常的直播观看体验等
• 同时对于拥有大量用户的公司来说，一小点的优化，乘以数万亿计的用户所节省的成本也是很显著的

性能优化的层面：

• 业务层优化

  • 针对特定的场景，具体的问题，具体分析，具体解决
  • 比较容易获得较大的性能收益

• 语言运行时优化

  • 解决更加通用的性能问题（比如日志输出的性能）
  • 考虑更多的场景
  • Tradeoffs

• 数据驱动

  • 自动性能分析工具--pprof
  • 依靠数据而非猜测
  • 首先优化最大瓶颈

性能优化与软件质量

• 软件质量至关重要
• 在保证接口稳定的前提下，改进具体实现（迭代升级）
• 测试用例：覆盖尽可能多的场景，方便回归
• 文档：具体做了什么功能，还欠缺什么功能，应该怎么使用，什么样的效果
• 隔离：通过选项控制是否开启优化
• 可观测：必要的日志输出

1. 自动内存管理

概念

动态内存：程序再运行时根据需求分配的内存：比如c 中 的malloc()
自动内存管理（GC）：由程序语言的运行时系统回收动态内存，避免手动呢次管理，保证安全和正确性，让开发人员专注于业务开发

• Mutator：业务线程，分配新对象，修改对象指向关系
• Collector：GC线程，找到存活对象，回收死亡对象的内存空间
• Serial GC：只有一个collector
• Parallel GC：支持多个collectors同时回收的GC算法
• Concurrent GC：mutator(s) 和 collector(s) 可以同时执行
  • Collectors 必须感知对象指向关系的改变

评价GC算法

• 安全性(Safety)：不能回收存活的对象 基本要求
• 吞吐率(Throughput)：1 - $\frac{GC时间}{程序执行总时间}$ 花在GC上的时间
• 暂停时间(Pause time)：stop the word (STW) 业务是否感知
• 内存开销(Space overhead)：GC元数据开销

追踪垃圾回收

对象被回收的条件：指针指向关系不可达的对象(也就是和根不在一个联通图内的点)

• 标记root对象：包括静态变量、全局变量、常量和线程栈等等；
• 标记可达对象：求指针指向关系的传递闭包：从根对象出发，找到所有可达对象；
• 清理所有不可达对象：
  • 将存活对象复制到另外的内存空间 (Copying GC)
  • 将死亡对象的内存标记为"可分配" (Mark-sweep GC)
  • 移动并整理存活对象 (Mark-compact GC)
• 根据对象的生命周期，使用不同的标记和清理策略

分代GC

• 分代假说(Generational hypothesis)：most objects die young
• Intuition：很多对象在分配出来后很快就不再使用了
• 每个对象都有年龄：经历过GC的次数
• 目的：对年轻和老年的对象，指定不同的GC策略，降低整个提内存管理的开销
• 不同年龄的对象处于heap的不同区域
• 年轻代(Young generation)
  • 常规的内存分配
  • 由于存活对象很少，可以采用copying collection
  • GC吞吐率很高
• 老年代(Old generation)
  • 对象趋向于一直活着，反复复制开销较大
  • 可以采用mark-sweep collection

引用计数

每个对象都有一个与之关联的引用数目 （cpp 中的 shared_ptr） 对象存活的条件：当且仅当引用数大于0

• 优点:
  • 内存管理的操作被平摊到程序执行过程中
  • 内存管理不需要了解runtime的实现细节：C++智能指针(smart pointer)
    这样做的缺点也是有的：
• 缺点：
  • 维护引用计数的开销较大：通过原子操作保证对引用计数的原子性和可见性
  • 无法回收环形数据结构——weak reference（下图红色部分）
  • 内存开销：每个对象都引入的额外内存空间存储引用数目
  • 回收内存时依然可能引发暂停

2. GO内存管理及优化

Go内存分配——分块

• 目标：为对象在heap上分配内存
• 提前将内存分块
  • 调用系统调用mmap()向OS申请一大块内存，例如4MB
  • 先将内存划分成大块，例如8KB，称作mspan
  • 再继续将大块划分成特定大小的小块，用于对象的分配
  • noscan mspan：分配不包含指针的对象——GC不需要扫描
  • scan mspan：分配包含指针的对象——GC需要扫描
• 对象分配：根据对象的大小，选择最合适的块

Go内存分配——缓存

• TCMalloc：thread caching

• 每个p包含一个mcache用于快速分配，用于为绑定于p上的g分配对象

• mcache管理一组mspan

• 当mcache中的mspan分配完毕，向mcentral申请带有未分配块的mspan

• 当mspan中没有分配的对象，mspan会被缓存在mcentral中，而不是立刻释放并归还给OS

Go内存管理优化

• 对象分配是非常高频的操作：每秒分配GB级别的内存
• 较小的对象占比较高
• Go内存分配比较耗时
  • 分配路径长：g -> m -> p -> mcache -> mspan -> memory block -> return pointer
  • pprof：对象分配的函数是最频繁调用的函数之一

字节在GO SDK内部的优化方案：Balanced GC

• 每个g都绑定一大块内存（1KB），称作goroutine allocation buffer (GAB)
• GAB用于noscan类型的小对象分配：< 128B
• 使用三个指针维护GAB：base, end, top
• Bump pointer（指针碰撞）风格对象分配：
  • 无需和其他分配请求互斥
  • 分配动作简单高效（只需移动栈顶指针）

• GAB对于Go内存来说是一个对象
• 本质：将多个小对象的分配合并成一次大对象的分配
• 问题：GAB的对象分配方式会导致内存被延迟释放
• 方案：移动GAB中的存活对象
  • 当GAB总大小超过一定阈值时，将GAB中存活的对象复制到另外分配的GAB中
  • 原先的GAB可以释放，避免内存泄漏
  • 本质：用copying GC的算法管理小对象(不同的生命周期使用不同的GC算法)

3. 编译器和静态分析

编译器的结构

• 重要的系统软件
  • 识别符合语法和非法的程序
  • 生成正确且高效的代码
• 分析部分：（前端 front end）
  • 词法分析：生成词素（lexeme）
  • 语法分析：生成语法树
  • 语义分析：收集类型信息，进行语义检查
  • 中间代码生成：生成intermediate representation（IR）
• 综合部分：（后端 back end）
  • 代码优化：机器无关代码，生成优化后的IR
  • 代码生成：生成目标代码

静态分析

• 静态分析： 不执行程序代码，推导程序的行为，分析程序的性质
• 控制流（Control Flow）：程序执行流程
• 数据流（Data FLow）:数据在控制流上的传递
• 通过分析控制流和数据流，我们可以知道更多关于程序的性质 比如下方这个程序

程序的结果其实可以直接就得出结果的，所以我们可以减少中间过多的步骤，直接返回结果（当然这只是一个比较简单的例子）

过程内分析和过程间分析

过程内分析：仅在函数内部进行分析 过程间分析：考虑过程调用时参数传递和返回值的数据流和控制流 过程间分析的难点：

• 需要通过数据流分析得知i的具体类型，才能知道i.foo()调用的是哪个foo()（有点像cpp中的SFINAE）

• 根据i的具体类型，产生了新的控制流，A.foo()，分析继续

• 过程间分析需要同时分析控制流和数据流——联合求解，比较复杂

4. GO编译器优化

• 为什么做编译器优化
  • 用户无感知，重新编译即可获得性能上的收益（我们只需重新编译和上线产品即可）
  • 通用性优化（可以同时让多个产品提升性能）
• 现状
  • 采用的优化少
  • 编译时间较短，没有进行较复杂的代码分析和优化
• 编译优化的思路：
  • 场景：面向后端长期执行任务
  • Tradeoff：用编译时间换取更高效的机器码
• Beast mode：
  • 函数内联
  • 逃逸分析
  • 默认栈大小调整
  • 边界检查消除
  • 循环展开，等

函数内联 inlining

内联：将被调用函数的函数体(callee)的副本替换到调用位置(caller)上，同时重写代码以反映参数的绑定

• 优点
  • 清除函数调用开销，例如传递参数、保存寄存器等
  • 将过程间分析转化为过程内分析，帮助其他优化，例如逃逸分析 感觉和Cpp中的inline是一样的，大多数时候都是能提升程序的运行性能