『字节青训营-3rd』L4：高性能 Go 语言发行版优化与落地实践
自动内存管理
降低开发负担、解决安全性问题
三个任务：
- 为对象分配空间
- 找到存活对象
- 回收死亡对象的内存空间
相关概念
名词
Mutator: 业务线程，分配新对象，修改对象指向关系（用户启动的线程）
Collector: GC 线程，找到存活对象，回收死亡对象的内存空间
Serial GC: 只有一个 collector（暂停所有 Mutator ，回收后再继续运行）
Parallel GC: 并行 GC，支持多个 collectors 同时回收的 GC 算法（暂停时多个有多个回收线程）
Concurrent GC: 并发 GC，支持 mutator(s) 和 collector(s) 同时执行的 GC 算法
-
Collectors 必须感知对象指向关系的改变！
评价 GC 算法
- 安全（不能回收存活的对象）
- 吞吐率（花在 GC 上的时间）
- 暂停时间
- 内存开销
算法1： 追踪垃圾回收
对象被回收的条件：指针指向关系不可达的对象
从根对象出发，遍历并标记所有可达的对象，最后清理剩下的对象
清理的策略：
-
Copying GC ：把存活的对象分配到其他空间
-
Mark-sweep GC： 将死亡对象的内存标记为可分配
-
Mark-compact GC： 原地移动整理存活对象
-
分代 GC （Generational GC）
基于事实：很多对象分配出来后很快就不再使用了
每个对象都有年龄：经过 GC 的次数
然后把老的和年轻的分开，制定不同的 GC 策略
- 年轻代
- 由于存活对象很少，可以采用 Copying GC
- 吞吐率高
- 老年代
- 趋于一直活着，反复复制开销大
- 可采用 Mark-compact GC
- 年轻代
算法2：引用计数
-
每个对象都有一个与之关联的引用数目
-
对象存活的条件：当且仅当引用数大于 0
-
优点
- 内存管理的操作被平摊到程序运行中：指针传递的过程中进行引用计数的增减
- 不需要了解 runtime 的细节：因为不需要标记 GC roots，因此不需要知道哪里是全局变量、线程栈等
-
缺点
- 开销大，因为对象可能会被多线程访问，对引用计数的修改需要原子操作保证原子性和可见性
- 无法回收环形数据结构
- 每个对象都引入额外存储空间存储引用计数
- 虽然引用计数的操作被平摊到程序运行过程中，但是回收大的数据结构依然可能引发暂停
Go 内存管理及优化
Go 内存分配策略
策略1：分块
Go 会提前将内存分块
- 调用系统调用 mmap() 向 OS 申请一大块内存，例如 4 MB
- 先将内存划分成大块，例如 8 KB，称作 mspan
- 再将大块继续划分成特定大小的小块，用于对象分配
- noscan mspan: 分配不包含指针的对象 —— GC 不需要扫描
- scan mspan: 分配包含指针的对象 —— GC 需要扫描
根据对象的大小，选择最合适的块分配
策略2：缓存
根据对象的大小，在 mcache 上分配
如果分不了，就找下一层 mcentral ，分配好后与 mcache 中的相同大小块交换（毕竟年轻代用的多）
Go 内存管理的问题
- 对象分配是非常高频的操作：每秒分配 GB 级别的内存
- 线上 profiling 发现，Go 的内存分配占用很多 CPU
- 小对象分配占大多数
字节跳动的优化方案：Balanced GC
针对小于 128B 的对象的优化算法，自己直接改 Go SDK
本质：将多个小对象的分配合并成一次大对象的分配
每一个 g 都分配一个 GAB ，然后在 GAB 中分配小对象
问题：只要 GAB 里有一个对象是存活的，那么这个大对象会一直占内存
解决方法：当 GAB 大小超过阈值后，将 GAB 中存活的对象复制到另外的 GAB 中，原 GAB 释放（使用 copying GC 的算法管理小对象）
编译器和静态分析
编译器的结构
静态分析
不执行代码，推导程序的行为，分析程序的性质
- 控制流：程序执行的流程
- 数据流：数据在控制流上的传递
通过分析两个流得到性质，优化代码
过程内分析和过程间分析
-
内分析：在函数内进行控制流和数据流的分析
-
间分析：除了函数内的分析，还需要考虑跨函数的数据流和控制流，例如参数传递，函数返回值等
Go 编译器优化
-
目的
-
用户无感知，重新编译即可获得性能收益
-
通用的优化手段
-
-
现状
-
采用的优化较少
-
追求编译时间短，因此没有进行复杂的代码分析和优化
-
-
思路
-
面向后端长期执行的任务
-
用适当增加编译时间换取更高性能的代码
-
函数内联
将被调用函数的函数体的副本替换到调用位置上，同时重写代码以反映参数的绑定
（鄙人感觉和 C 中的 inline 一模一样）
-
优点
- 消除调用开销
- 将过程间分析的问题转换为过程内分析，帮助其他分析
-
缺点
- 函数体变大
- 编译生成的 Go 镜像文件变大
逃逸分析
分析代码中指针的动态作用域：指针在何处可以被访问
大致思路：
- 从对象分配处出发，沿着控制流，观察数据流。若发现指针 p 在当前作用域 s:
- 作为参数传递给其他函数；
- 传递给全局变量；
- 传递给其他的 goroutine;
- 传递给已逃逸的指针指向的对象；
- 则指针 p 逃逸出 s，反之则没有逃逸出 s.
字节跳动的优化方案：Beast Mode
-
修改了内联策略，让更多函数被内联
-
增加了其他优化的机会：逃逸分析
-
开销：文件更大，耗时更多
-
未逃逸出当前函数的指针指向的对象可以在栈上分配
-
对象在栈上分配和回收很快：移动 sp 即可完成内存的分配和回收；
-
减少在堆上分配对象，降低 GC 负担。
-