这是我参与「第五届青训营 」伴学笔记创作活动的第5天
背景知识
-
性能优化层面:
- 业务层优化:
- 针对特定场景、具体问题具体分析
- 容易获得较大的性能收益
- 语言运行时优化
- 解决更通用的性能问题
- 考虑更多场景
- Tradeoffs
- 业务层优化:
-
数据驱动
-
自动化性能分析工具——pprof
-
依靠数据而非猜测
-
首先优化最大瓶颈
-
-
优化SDK原则、注意事项
- 保证接口稳定的情况下改进具体实现
- 测试样例尽可能覆盖多场景
- 文档说明做了什么,没做什么,能达到什么效果
- 隔离性:通过选项控制是否开启这项优化(不影响不开启优化的用户)
- 可观测性:必要的日志输出
内存管理优化
自动内存管理
1.背景
自动内存管理管理的是动态内存(程序运行时根据需求动态分配的内存)。
好处主要有两点:
- 避免手动内存管理,让程序员专注于实现业务逻辑
- 保证内存使用的正确性和安全性(如C、C++语言多次释放同一块内存,访问释放后的内存)
自动内存管理的任务:
- 为新对象分配内存
- 找到存活的对象
- 回收死亡对象的内存空间
相关概念:
- Mutator:业务线程,分配新对象,修改对象指向关系
- Collector: GC 线程,找到存活对象,回收死亡对象的内存空间
2.常见管理方式
a. Serial GC:
只有一个Collector
b. Parallel GC
支持多个Collector同时回收的GC算法。
c. Concurrent GC
Mutator和Collector可以同时执行。
难度:因为Mutator和Collector同时执行,导致标记存活对象时Mutator可能会申请新的内存空间,这时候需要感知对象指向关系的改变。
3. 评价GC算法
-
安全性:不能回收存活的对象
-
吞吐率:
-
暂停时间(Pause time)
-
内存开销(Space overhead)
4. 常见管理内存方法
a. 追踪垃圾回收
- 对象被回收的条件:指针指向关系不可达的对象
步骤:
-
标记根对象
- 静态变量、全局变量、常量、线程栈等
-
标记:找到可达对象
- 求指针指向关系的传递闭包:从根对象出发找到所有可达对象
-
清理所有不可达对象
- 将存活对象复制到另外的内存空间(Copying GC)
- 将死亡对象的内存标记为可分配(Mark-sweep GC)
- 移动并整理存活对象(Mark-compact GC)
-
根据对象的声明周期使用不同的标记和清理策略
例子:分代GC(generational GC)
- 分代假说:许多对象的生命周期都很短
- 计算对象经过GC的次数作为每个对象的年龄
- 对年轻代和老年代对象使用不同的GC策略
- 年轻代
- 常规的对象分配
- 由于存活对象少,可以使用Copying GC
- GC吞吐率很高
- 老年代
- 对象趋于一致活着,Copying GC开销很大
- 使用Mark-sweep GC
- 年轻代
b. 引用计数
- 每个对象都有一个与之相关联的引用计数
- 对象存活的条件:当且仅当引用数大于0
- 优点:
- 内存管理的操作被平摊到程序执行过程中
- 内存管理不需要了解runtime的实现细节:C++智能指针
- 缺点:
- 维护引用计数开销较大:通过原子操作保证对引用计数操作的原子性和可见性
- 无法回收环形数据结构
- 内存开销:每个对象都要引入额外的内存空间存储引用数目
- 回收内存时依然可能引发暂停(回收大数据结构时可能会引发暂停)
Go内存管理与优化
1. Go内存分配方式
目标:为对象在heap上分配内存
方法:
- 提前将内存分块
- 调用系统调用
mmap()向OS申请一大块内存,eg:4MB - 将内存划分成大块,eg:8kb,称作mspan(分成两种)
- noscan mspan:分配不包括指针的对象——GC不需要扫描
- scan mspan:分配包括指针的对象——GC需要扫描
- 再将大块继续划分成特定大小的小块,用于对象分配
- 调用系统调用
- 对象分配:根据对象大小,选取最合适的块分配
2. Go内存分配——缓存
借鉴TCMalloc(thread caching)的实现
Go 内存管理构成了多级缓存机制,从 OS 分配得的内存被内存管理回收后,也不会立刻归还给 OS,而是在 Go runtime 内部先缓存起来,从而避免频繁向 OS 申请内存。内存分配的路线图如下。
3. Go内存管理优化
- 对象分配时非常高频的操作
- 大多数对象都是小对象
- Go内存分配是非常消耗时间的
- 分配路径长(参考上图)
优化方案(字节跳动的优化方案):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来管理小对象
编译器和静态分析
编译器结构
静态分析
-
静态分析:不执行代码,推导程序的行为,分析程序的性质。
-
控制流:程序的执行流程
-
数据流:数据在控制流上的传递
上图的程序转换成控制流图 (control-flow graph)
- 通过分析控制流和数据流,我们可以知道更多关于程序的性质(properties) ,这些事实可以帮助我们做编译优化。
- 例如上面的程序。我们通过分析数据流和控制流,知道这个程序始终返回 4。编译器可以根据这个结果做出优化。
过程内分析和过程间分析
-
过程内分析(Intra-procedural analysis):
- 函数内分析:在函数内进行控制流和数据流的分析
-
过程间分析(Inter-procedural analysis):
- 函数间分析
- 除了函数内的分析,还需要考虑跨函数的数据流和控制流,例如参数传递,函数返回值等
eg:分析
i.foo()是啥
Go编译器优化
背景
- 为什么做编译优化
- 用户无感知,重新编译即可获得性能收益
- 通用性优化
- 现状
- 采用的优化少
- 编译时间较短,没有进行较复杂的代码分析和优化
- 编译优化思路:
- 场景:面向后端长期执行的任务
- 权衡利弊,提高编译时间,优化编译后程序性能
- 字节跳动优化beast mode
- 函数内联
- 逃逸分析
- 默认栈大小调整
- 边界检查消除
- 循环展开
- ...
函数内联
-
定义:将被调用函数的函数体的副本替换到调用位置上,同时重写代码以反映参数的绑定
-
优点
- 消除调用开销
- 将过程间分析的问题转换为过程内分析,帮助其他分析
-
缺点
- 函数体变大
- 编译生成的 Go 镜像文件变大
-
函数内联在大多数情况下是正向优化,即多内联,会提升性能
-
采取一定的策略决定是否内联
- 调用和被调用函数的规模
- ...
-
Go 内联的限制
- 语言特性:interface, defer 等等,限制了内联优化
- 内联策略非常保守
-
字节跳动的优化方案
- 修改了内联策略,让更多函数被内联
- 增加了其他优化的机会:逃逸分析
-
开销
- Go 镜像大小增加:10%
- 编译时间增加
- 运行时栈扩展开销增加
逃逸分析
- 定义:分析代码中指针的动态作用域,即指针在何处可以被访问
-
大致思路
-
从对象分配处出发,沿着控制流,观察数据流。若发现指针 p 在当前作用域 s:
- 作为参数传递给其他函数;
- 传递给全局变量;
- 传递给其他的 goroutine;
- 传递给已逃逸的指针指向的对象;
-
则指针 p 逃逸出 s,反之则没有逃逸出 s.
-
-
字节跳动的优化方案:通过函数内联拓展了函数边界,使更多对象不逃逸
- 优化:未逃逸出当前函数的指针指向的对象可以在栈上分配
- 对象在栈上分配和回收很快:移动 sp 即可完成内存的分配和回收;
- 减少在堆上分配对象,降低 GC 负担。