这是我参与「第三届青训营 -后端场」笔记创作活动的的第3篇笔记
自动内存管理
追踪垃圾回收
对象被回收的条件：指针指向关系不可达的对象
-
标记根对象
- 包括：静态变量、全局变量、常量、线程栈等
-
标记：找到可达对象
- 求指针指向关系的传递闭包：从根对象触发，找到所有可达对象
-
清理：所有不可达对象（3种方式）
- 将存活对象复制到另外的内存空间（Copying GC）
- 将死亡对象的内存标记为“可分配”（Mark-sweep GC）
- 移动并整理存活对象（原地）（Mark-compact GC）
分代GC（优化追踪垃圾回收）
分代假说
- 很多对象在分配出来后很快就不再使用了
- 每个对象都有年龄：经历过GC的次数
- 目的：对年轻和老年（趋向于短期使用和长期使用） 的对象，制定不同的GC策略，降低整体内存管理的开销
- 不同年龄的对象处于heap堆内存的不同区域
管理方式
年轻代
- 常规的对象分配
- 由于存活对象很少，可以采用copying collection
- GC吞吐率很高
老年代
- 对象趋向于一直活着，反复复制开销较大
- 可以采用mark-sweep collection
引用计数
-
每个对象都有一个与之关联的引用数目
-
对象存活的条件：当且仅当引用数大于0
-
优点
- 内存管理的操作被平摊到程序执行过程中
- 内存管理不需要了解runtime的实现细节
-
缺点
- 维护引用计数的开销较大：通过原子操作（大开销）保证对引用计数操作的原子性和可见性
- 无法回收环形数据结构
- 内存开销：每个对象都引入额外内存空间存储引用数目
- 回收内存时依然可能引发暂停
Go内存分配
分块
-
目标：为对象在heap上分配内存
-
提前将内存分块
- 先将内存分为大块，例如8KB，再将大块划分为特定大小的小块，用于内存分配
- noscan mspan：分配不包含指针的对象——GC无需扫描
- scan mspan：分配包含指针的对象——GC需要扫描
-
对象分配：根据对象大小选择最合适的块返回
缓存
如图所示
- mcache中装有不同大小的mspan内存块，当p需要时分配给p
- 当mcache中的maspan分配完毕，向mecntral申请带未分配块的mspan
Go内存管理优化
-
对象分配是非常高频的操作：每秒分配GB级别的内存
-
小对象占比较高
-
Go内存分配比较耗时
- 分配路径长：g -> m -> p -> mcache -> mspan -> memory block -> return pointer
字节的优化方案：Balanced GC
-
每个g都绑定一大块内存（1 KB)，称作 goroutine allocation butfer (GAB)
-
GAB用于noscan类型的小对象分配:<128 B
-
使用三个指针维护GAB: base, end, t op
-
Bump pointer（指针碰撞）风格对象分配
- 无须和其他分配请求互斥
- 分配动作简单高效
-
GAB对于Go内存管理来说是一个大对象
-
本质：将多个小对象的分配合并成一次大对象的分配
-
问题：GAB的对象分配方式会导致内存被延迟释放
-
方案：移动 GAB中存活的对象
- 当GAB总大小超过一定阈值时，将GAB中存活的对象复制到另外分配的 GAB中
- 原先的 GAB 可以释放,避免内存泄漏
- 本质：用copying GC的算法管理小对象
编译器和静态分析
静态分析
- 不执行程序代码，推导程序的行为，分析程序的性质
- 控制流：程序执行的流程
- 数据流：数据在控制流上的传递
- 通过分析控制流和数据流，得知更多关于程序的性质，根据这些性质优化代码
过程内分析和过程间分析
过程内分析
- 仅在函数内部进行分析
过程间分析
- 考虑过程调用时参数传递和返回值的数据流和控制流
- 过程间分析是个问题，因为要同时分析控制流和数据流——联合求解，比较复杂
Go编译器优化
-
为什么做编译器优化
- 用户无感知，重新编译即可获得性能收益
- 通用性优化
-
现状
- 采用的优化少
- 编译时间较短，没有进行较复杂的代码分析和优化
-
编译优化的思路
- 场景:面向后端长期执行任务
- Tradeoff：用编译时间换取更高效的机器码
-
Beast mode
- 函数内联
- 逃逸分析
- 默认栈大小调整
- 边界检查消除
- 循环展开
函数内联
-
内联：将被调用函数的函数体(callee)的副本替换到调用位置(caller)上，同时重写代码以反映参数的绑定
-
优点
- 消除函数调用开销，例如传递参数、保存寄存器等
- 将过程间分析转化为过程内分析，帮助其他优化，例如逃逸分析
-
缺点
- 函数体变大，instruction cache (icache)不友好
- 编译生成的Go镜像变大
-
函数内联在大多数情况下是正向优化。
-
内联策略
- 调用和被调函数的规模
- .…
Beast Mode
-
Go函数内联受到的限制较多
- 语言特性，例如interface, defer 等，限制了函数内联
- 内联策略非常保守
-
Beast mode：调整函数内联的策略，使更多函数被内联
- 降低函数调用的开销
- 增加了其他优化的机会：逃逸分析
-
开销
- Go镜像增加~10%
- 编译时间增加
逃逸分析
-
分析代码中指针的动态作用域:指针在何处可以被访问
-
大致思路
-
从对象分配处出发，沿着控制流，观察对象的数据流
-
若发现指针p在当前作用域s:
- 作为参数传递给其他函数
- 传递给全局变量
- 传递给其他的goroutine
- 传递给已逃逸的指针指向的对象
-
则指针p指向的对象逃逸出s，反之则没有逃逸出s
-
-
Beast mode：函数内联拓展了函数边界，更多对象不逃逸
-
优化：未逃逸的对象可以在栈上分配
- 对象在栈上分配和回收很快：移动sp
- 减少在heap 上的分配，降低GC负担
总结
Beast mode调整了函数内联的策略，降低函数调用的开销，还拓展了函数边界，使更多对象不逃逸，从而使其在栈上分配
