「高性能 Go 语言发行版优化与落地实践」学习笔记｜青训营学习笔记六篇。总共第九篇一、本堂课重点内容：本堂课主要

学习笔记六篇。总共第九篇

一、本堂课重点内容：

本堂课主要介绍了自动内存管理、Go 内存管理及优化、编译器和静态分析、Go编译器优化（函数内联、逃逸分析）

二、详细知识点介绍：

业务层优化

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

语言运行时优化

解决更通用的性能问题
考虑更多场景
Tradeoffs数据驱动

自动化

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

自动内存管理

自动内存管理：由程序语言的运行时系统管理动态内存
避免手动内存管理，专注于实现业务逻辑
保证内存使用的正确性和安全性: double-free problem, use-after-free problem
三个任务
- 为新对象分配空间
- 找到存活对象
- 回收死亡对象的内存空间

GC领域术语：

线程角色
- Mutator: 业务线程，分配新对象，修改对象指向关系
- Collector: GC 线程，找到存活对象，回收死亡对象的内存空间
- Collectors 必须感知对象指向关系的改变！
不同的GC算法种类
- Serial GC: 只有一个 collector
- Parallel GC: 并行 GC，支持多个 collectors 同时回收的 GC 算法
- Concurrent GC: 并发 GC，支持 mutator(s) 和 collector(s) 同时执行的 GC 算法
- 前两者都会STW(Stop The World)再GC，区别是collector数量。第三种业务代码和垃圾回收同时执行

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

追踪垃圾回收 Tracing garbage collection

被回收的条件：不可达对象
- 过程
  - 标记根对象 (GC roots): 静态变量、全局变量、常量、线程栈等（这些必然是存活的）
  - 标记：找到所有可达对象（求指针指向关系的传递闭包：从根对象出发，找到所有可达对象）
  - 清理：回收所有不可达对象
    - 根据对象的生命周期,使用不同的标记和清理策略
    - Copying GC: 将存活对象从一块内存空间复制到另外一块内存空间，原先的空间可以直接进行对象分配
    - Mark-sweep GC: 将死亡对象所在内存块标记为可分配，使用 free list 管理可分配的空间
    - Mark-compact GC: 将存活对象复制到同一块内存区域的开头

分代GC Generational GC

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

引用计数 Reference Couting

每个对象都有一个与之关联的引用数目
对象存活的条件：当且仅当引用数大于 0
优点
- 内存管理的操作被平摊到程序运行中：指针传递的过程中进行引用计数的增减
- 不需要了解 runtime 的细节：因为不需要标记 GC roots，因此不需要知道哪里是全局变量、线程栈等。如C++智能指针（Smart Pointer）
缺点
- 开销大，因为对象可能会被多线程访问，对引用计数的修改需要原子操*保证原子性和可见性（因为可能有多个线程访问）
- 无法回收环形数据结构
- 每个对象都引入额外存储空间存储引用计数
- 虽然引用计数的操作被平摊到程序运行过程中，但是回收大的数据结构依然可能引发暂停

Go 内存管理及优化

提前将内存分块

调用系统调用 mmap() 向 OS 申请一大块内存，例如 4 MB
先将内存划分成大块，例如 8 KB，称作 mspan
再将大块继续划分成特定大小的小块，用于对象分配
noscan mspan: 分配不包含指针的对象 —— GC 不需要扫描
scan mspan: 分配包含指针的对象 —— GC 需要扫描

缓存

TCMalloc: TC is short for thread caching
Go 内存管理构成了多级缓存机制。
每个p包含一个mcache用于快速分配，用于为绑定于p上的g分配对象。mcache管理一组mspan。
当mcache中的 mspan 分配完毕，向mcentral申请带有未分配块的mspan
从当mspan中没有分配的对象，mspan 会被缓存在mcentral中，而不是立刻释放并归还给OS。（从而避免频繁向 OS 申请内存）

内存分配的路线图如下。

mspan, mcache 和 mcentral 构成了内存管理的多级缓存机制。

对象分配是非常高频的操作：每秒分配 GB 级别的内存
线上 profiling 发现，Go 的内存分配占用很多 CPU

（用于分配对象的函数 mallocgc() 占用 CPU 较高）

小对象分配占大多数（横轴是对象大小，纵轴是数目，可以看到绝大多数对象都小于 80 B。因此优化小对象分配是关键。）

字节跳动的优化方案：Balanced GC

核心：每个g都绑定一大块内存（1KB），称作goroutine allocation buffer(GAB)，用来分配小于 128B 的 noscan 小对象，并使用移动对象 GC 管理这部分内存，提高对象分配和回收效率

bump pointer 风格的对象分配。

if g.ab.end - g.ab.top < size {
// Allocate a new allocation buffer
}
addr := g.ab.top
g.ab.top += size
return addr

分配对象时，根据对象大小移动 top 指针并返回，快速完成一次对象分配
同原先调用 mallocgc() 进行对象分配的方式相比，balanced GC 缩短了对象分配的路径，减少了对象分配执行的指令数目，降低 CPU 使用（同时，由于是每个g都有自己的GAB，所以分配操作不必进行同步互斥）

Balanced GC 只负责 noscan 对象的分配和移动，对象的标记和回收依然依赖 Go GC 本身，并和 Go GC 保持兼容。

balanced GC的问题

本质：balanced GC 是将多次小对象的分配合并成一次大对象的分配。
问题：从 Go runtime 内存管理模块的角度看，一个 allocation buffer 其实是一个大对象。因此，当 GAB 中哪怕只有一个小对象存活时，Go runtime 也会认为整个大对象（即 GAB）存活。
方案：为此，balanced GC 会根据 GC 策略，将 GAB 中存活的对象移动到另外的 GAB 中，从而压缩并清理 GAB 的内存空间，原先的 GAB 空间由于不再有存活对象，可以全部释放。
- 当GAB总大小超过一定阈值时，将GAB中存活的对象复制到另外分配的GAB中
- 原先的GAB可以释放，避免内存泄漏
- 本质：用Copying GC的方法管理小对象

其中虚线表示 GAB 中对象的分界线。黑色表示 GAB 中存活的对象，白色表示死掉的对象。由于 GAB 中有存活对象，整个 GAB 无法被回收。

Balanced GC 会将 GAB 中存活的对象移动到下面的 GAB 中，这样原先的两个 GABs 就可以被释放，压缩并清理 GAB 的内存空间。

编译器静态分析

静态分析：不执行代码，推导程序的行为，分析程序的性质。
控制流：程序的执行流程
数据流：数据在控制流上的传递

程序转换成控制流图CFG (control-flow graph)

Intra-procedural analysis: 函数内分析：在函数内进行控制流和数据流的分析
Inter-procedural analysis: 函数间分析：除了函数内的分析，还需要考虑跨函数的数据流和控制流，例如参数传递，函数返回值等

为什么过程间分析是个问题?

需要通过数据流分析得知i的具体类型，才能知道i.foo(）调用的是哪个foo()
根据i的具体类型，产生了新的控制流，i.foo()，分析继续。
过程间分析需要同时分析控制流和数据流——联合求解，比较复杂

type I interface {
    foo()
}
type A struct {}
type B struct {}

func (a *A) foo() {
  ...
}
func (b *B) foo() {
  ...
}
func bar() {
i = &A
i.foo() // A.foo() or B.foo()?

Go 编译器优化

目的：

用户无感知，重新编译即可获得性能收益
通用的优化手段

现状：

采用的优化较少
追求编译时间短，因此没有进行复杂的代码分析和优化

思路：

面向后端长期执行的任务
用适当增加编译时间换取更高性能的代码

Beast mode：

函数内联
逃逸分析
默认栈大小调整
边界检查消除
循环展开

函数内联

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

优点
- 消除调用开销（如传递参数、保存寄存器）
- 将过程间分析的问题转换为过程内分析，帮助其他分析（如逃逸分析）
缺点
- 函数体变大（对instruction cache(icache)不友好）
- 编译生成的 Go 镜像文件变大
函数内联在大多数情况下是正向优化，即多内联，会提升性能

根据不同的内联策略决定是否内联，如调用和被调函数的规模。

benchmark对比（利用go编译指令，一种特殊的注释）：

func BenchmarkInline(b *testing.B){
    x := genInteger()
    y := genInteger()
    for i :=0; i< b.N; i++ {
        addInline(x，y)
    }
}
func addInline(a,b int) int {
    return a + b
}
// ------------------
func BenchmarkInlineDisabled(b *testing.B){
    x := genInteger()
    y := genInteger()
    for i :=0; i< b.N; i++ {
        addNoInline(x，y)
    }
}

//go:noinline
func addNoInline(a,b int) int {
    return a + b
}

函数被内联后，性能数据提升4.58X!

字节跳动的优化方案 beast mode

Go函数内联受到的限制较多
- 语言特性，例如interface, defer等，限制了函数内联
- 内联策略非常保守
Beast mode:调整函数内联的策略，使更多函数被内联
- 降低函数调用的开销
- 增加了其他优化的机会:逃逸分析
开销
- Go镜像增加~10%
- 编译时间增加

逃逸分析

定义：分析代码中指针的动态作用域，即指针在何处可以被访问
大致思路
- 从对象分配处出发，沿着控制流，观察数据流。若发现指针 p 在当前作用域 s:
  - 作为参数传递给其他函数；
  - 传递给全局变量；
  - 传递给其他的 goroutine;
  - 传递给已逃逸的指针指向的对象；
- 则指针 p 逃逸出 s，反之则没有逃逸出 s.
字节跳动beast mode优化：未逃逸出当前函数的指针指向的对象可以在栈上分配
- 对象在栈上分配和回收很快：移动 sp 即可完成内存的分配和回收；
- 减少在堆上分配对象，降低 GC 负担。

「高性能 Go 语言发行版优化与落地实践」学习笔记 ｜ 青训营