高性能Go语言发行版优化与落地实践｜青训营笔记
这是我参与「第五届青训营」伴学笔记创作活动的第4天。
一、本堂课重点内容
- 性能优化
- 垃圾回收策略
- 编译优化策略
二、详细知识点介绍
0. 高性能go语言优化
0.1 追求极致性能
- 性能优化：提升软件系统处理能力、减少不必要的消耗、充分发掘计算机算力
- 为何需要性能优化
- 用户体验：提升
- 资源高效利用，降低成本提高效率
0.2 性能优化的层面
- 层次
- 业务代码
- SDK
- 基础库
- 语言运行时
- OS
- 业务层优化
- 针对特定场景、具体问题具体分析
- 容易获得较大性能收益
- 语言运行时优化
- 解决更通用的性能问题
- 考虑更多场景：编译器、代码质量
- 权衡 tradeoffs
- 数据驱动
- 自动化性能分析工具-pprof
- 依靠数据而非猜测
- 首先优化最大瓶颈
0.3 性能优化与软件质量
- 软件质量至关重要：分享，使用量大
- 在保证接口稳定的情况下改进具体实现
- 测试用例：需要覆盖尽可能多的场景方便回归
- 文档：做了/没做什么 能达到什么效果
- 隔离：通过选项控制是否开启优化
- 可观测：log输出
1.自动内存管理
1.1 概念
- 动态内存：程序在运行时根据需求动态分配的内存malloc()
- 自动内存管理（垃圾回收）：由程序语言的运行时系统管理动态内存
- 避免手动内存管理，专注于实现业务逻辑
- 保证内存使用的正确性和安全性
- double-free
- use-after-free
- 三个任务
- 为新对象分配空间
- 找到存活对象
- 回收死亡对象的内存空间
1.2 相关概念
- Mutator：业务线程-分配新对象，修改对象指向关系
- Collector：GC线程，找到存活对象，回收死亡对象的内存空间
- 算法分类
- Serial GC：只有一个collector
- Parallel GC：支持多个collectors同时回收的GC算法
- Concurrent GC：mutators和collectors可以同时执行
- collectors必须感知对象指向关系的改变
- 已经标记过的对象需要感知其指向关系
- 评价GC算法
- 安全性 safety：不能回收存活的对象（基本要求）
- 吞吐率 throughput：1- （花在GC上的时间）
- 暂停时间 pause time：stop the world（STW） 业务是否感知
- 内存开销 space overhead：GC元数据开销
- 追踪垃圾回收（tracing garbage collection）
- 引用计数（reference counting）
1.2 Tracing garbage collection 追踪垃圾回收
- 逻辑
- 对象被回收的条件：指针指向关系不可达的对象
- 标记根对象
- 静态变量、全局变量、常量、线程栈
- 标记：找到可达对象
- 求指针指向关系的传递闭包：从根对象出发找到所有可达对象
- 清理所有不可达的对象
- 将存活对象复制到另外的内存空间（copying GC）
- 将死亡对象内存标记为可分配（mark-sweep GC）
- 移动并整理存活对象（Mark-compact GC）
- 根据对象的生命周期，使用不同的标记和清理策略
1.3 Generational GC 分代GC
- 分代假说：大多数的object很快就死亡了
- Intuition：很多对象在分配出来后很快就不再使用了
- 每个对象都有年龄：经历过GC的次数
- 目的：对年轻和老年的对象制定不同的GC策略，降低整体内存管理的开销
- 不同年龄的对象处于heap不同区域
- 年轻代
- 常规的对象分配
- 由于存活对象很少，可以采用copying collection
- GC吞吐率很高
- 老年代
- 对象趋于一直活着，反复复制开销较大
- 可以采用mark-sweep collection
- 年轻代
1.4 Reference counting 引用计数
- 每个对象有一个与之关联的引用计数，对象存活的条件是当且仅当引用数大于0
- 优点
- 内存管理操作被平摊到程序执行中
- 内存管理不需要了解runtime的实现细节
- c++智能指针
- 缺点
- 维护引用计数的开销较大：通过原子操作保证对引用计数操作的原子性和可见性
- 无法回收环形数据结构-weak reference
- 内存开销：每个对象都引入额外内存空间存储引用数目
- 回收内存时依然可能引发暂停
2. Go内存管理及优化
2.1 Go内存分配-分块
- 目标：为对象在heap上分配内存
- 提前将内存分块
- 调用系统调用mmap()向os申请一大块内存
- 先将内存划分成大块，称为mspan
- 再将大块继续划分为特定大小的小块用于对象分配
- noscan mspan：分配不包含指针的对象--GC不需要扫描
- scan mspan：分配包含指针的对象————GC需要扫描
- 对象分配：根据对象大小选择最合适的块返回
2.2 Go内存分配——缓存
- TCMalloc: thread catching
- 每个p包含一个mcache用于快速分配，用于为绑定于p上的g分配对象
- mcache管理一组mspan
- 当mcache中的mspan分配完毕，向mcentral申请带有未分配块的mspan
- 当mspan中没有分配对象，mspan会被缓存在mcentral中而不是立刻释放返回OS
2.3 Go内存管理优化
- 对象分配是非常高频的操作：每秒分配GB级别的内存
- 小对象占比较高
- Go内存分配比较耗时
- 分配路径长
- 对象分配的占比非常高
2.4 Balanced GC
- 每个g绑定一大块内存：gorouting allocation buffer
- GAB用于noscan类型小对象分配 <128B
- 使用三个指针维护GAB：base/end/top
- bump pointer指针碰撞 风格对象分配
- 无需和其他分配互斥
- 分配动作简单高效
- GAB对于GO内存管理来说是一个大对象
- 本质将多个小对象分配合并成一次大对象的分配
- 问题：延迟内存的释放
- 移动GAB中存活的对象
- 当GAB总大小超过阈值，将其中存活的对象复制到另外分配的GAB中
- 原先GAB释放，避免内存泄漏
- 本质用copy GC的算法管理小对象
- 根据对象生命周期选择不同的分配策略
- 移动GAB中存活的对象
3. 编译器和静态分析
3.1 基本介绍：编译器的结构
- 重要的系统软件
- 识别符合语法和非法的程序
- 生成正确且高效的代码
- 分析部分 前端
- 词法分析 生成语素（lexeme）
- 语法分析，生成语法树
- 语义分析，收集类型信息，进行语义检查
- 中间代码生成，生成intermediate representation（IR）
- 综合部分 后端
- 代码优化，机器无关优化，生成优化后IR
- 代码生成，生成目标代码
3.2 静态分析
- 不执行程序代码，推倒程序的行为，分析程序的性质
- 控制流（control flow）：程序执行的流程
- 数据流（data flow）：数据在控制流上的传递
- 通过分析控制流和数据流，得知程序的性质，优化代码
3.3 过程内和过程间分析
- 过程内分析：仅在过程内部进行分析
- 过程间分析：考虑过程调用时参数传递和返回值的数据和控制流
- 为何需要过程间分析
- 通过数据流分析得知i的具体类型
- 根据i的具体类型产生新的控制流
- 过程间分析需要同时分析控制流和数据流
4. go编译器优化
4.1 优化背景
- 为何需要优化
- 用户无感知，重新编译即可获得性能收益
- 通用性优化
- 现状
- 采用的优化少
- 编译时间较短，没有进行较复杂的代码分析和优化
- 思路
- 场景：面向后端长期执行任务
- tradeoff：用编译时间换取更高效率的机器码
- beast mode
- 函数内联
- 逃逸分析
- 默认栈大小调整
- 边界检查消除
- 循环展开
4.2 函数内联
- 内联：将被调用函数的函数体的副本替换到调用位置上，同时重写代码以反映参数绑定
- 优点
- 消除函数调用开销，例如传递参数、保存寄存器等
- 将过程间分析转化为过程内分析，帮助其他优化例如逃逸分析
- 影响大量性能
4.3 Beast mode
- go函数内联限制多
- 语言特性限制函数内联
- 策略保守
- beast mode调整内联策略，内联更多函数
- 降低函数调用开销
- 增加其他优化机会：逃逸分析
- 有代价：开销增加，编译时间增加
4.4 逃逸分析
- 分析代码中指针的动态作用域，指针指在何处可以被访问
- 从对象分配出发，沿着控制流，观察对象的数据流
- 若发现p在当前作用域s：
- 作为参数传递给其他函数
- 传递给全局变量
- 传递给其他gorouting
- 传递给已逃逸的指针指向的对象
- 则指针p指向的对象逃逸出s，反正未逃逸
- 若发现p在当前作用域s：
- beastmode 函数内联扩展了函数边界，更多对象不逃逸
- 优化：未逃逸的对象可以在栈上分配
- 对象在栈上分配和回收很快：移动sp
- 减少heap上的分配，降低GC负担
三、个人总结
本节课主要讲解了go性能优化的相关内容。课程的难点在于go的自动内存管理的不同模式优缺点，编译器、静态分析以及优化的相关方向。课后需要结合原代码加以理解。
