这是我参与「第三届青训营 -后端场」笔记创作活动的的第二篇笔记。主要介绍Go内存管理。

大纲

优化

内存管理优化
编译器优化

背景

自动内存管理和Go内存管理机制
编译器优化的基本问题和思路

实践

字节跳动遇到的性能问题以及优化方案

前言

性能优化是什么？

提升软件系统处理能力，减少不必要的消耗，充分发掘计算机算力，从指标上有提高CPU占用率、减少内存消耗、减少IO的延时等。

为什么要做性能优化？

用户体验：带来用户体验的提升（刷抖音更丝滑，双十一购物不再卡顿）
资源高效利用：降低成本，提高效率（很小的优化乘以海量机器会是显著的性能提升和成本节约）

性能优化的层面

性能优化层面关于Go运行时的相关知识：深入浅出 Golang Runtime

性能优化与软件质量

性能优化与软件质量

1. 自动内存管理

基本概念

自动内存管理：由程序语言的运行时系统管理动态内存
避免手动内存管理，专注于实现业务逻辑
保证内存使用的正确性和安全性: double-free problem, use-after-free problem

三个任务

为新对象分配空间
找到存活对象
回收死亡对象的内存空间

概念

Mutator: 业务线程，分配新对象，修改对象指向关系
Collector: GC 线程，找到存活对象，回收死亡对象的内存空间
Serial GC: 只有一个 collector
Parallel GC: 并行 GC，支持多个 collectors 同时回收的 GC 算法
Concurrent GC: 并发 GC，支持 mutator(s) 和 collector(s) 同时执行的 GC 算法
- Collectors 必须感知对象指向关系的改变！

GCMARK

Golang中GC回收机制三色标记与混合写屏障可以解决Concurrent GC可能出现的情况。

推荐书籍：<<The Garbage Collection HandBook>>

基于追踪的垃圾回收

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

分代GC（Generational GC）

针对不同周期的内存对象制定不同的内存回收策略。分代GC

引用计数

每个对象都有一个与之关联的引用数目
对象存活的条件：当且仅当引用数大于 0

优点

内存管理的操作被平摊到程序运行中：指针传递的过程中进行引用计数的增减
不需要了解 runtime 的细节：因为不需要标记 GC roots，因此不需要知道哪里是全局变量、线程栈等，如C++的智能指针。

缺点

维护引用计数开销大，因为对象可能会被多线程访问，对引用计数的修改需要原子操作保证原子性和可见性
无法回收环形数据结构：使用weak reference
内存开销：每个对象都引入额外存储空间存储引用计数
虽然引用计数的操作被平摊到程序运行过程中，但是回收大的数据结构依然可能引发暂停

引用计数

总结

以上所述的技术的缺点并非是无法解决的问题。学术界和工业界在一直在致力于解决自动内存管理技术的不足之处。例如，最新的 PLDI'22 的文章 Low-Latency, High-Throughput Garbage Collection 。

2. Go内存管理及优化

Go内存分配——分块

目标：为对象在heap上分配内存
提前将内存分块
- 调用系统调用mmap()向OS申请一大块内存，例如4MB
- 先将内存划分成大块，例如8KB，称作mspan
- 再将大块继续划分成特定大小的小块，用作对象分配
- noscan mspan：分配不包括指针的对象——GC不需要扫描
- scan mspan：分配包含指针的对象——GC需要扫描
对象分配：根据对象大小，选择最合适的块返回

Go内存分配——缓存

Goroutine的并发编程模型基于GMP模型：

G: 表示goroutine，每个goroutine都有自己的栈空间，初始化栈大小为2k，主要保存 goroutine 的一些状态信息以及 CPU 上一些寄存器的值。

M: 表示machine，它代表一个工作线程，或者说系统内核线程。G 需要调度到 M 上才能运行，M 是真正工作的人

P: 表示processor，负责调度goroutine，维护一个本地goroutine队列，M从P上获得goroutine并执行，同时还负责部分内存的管理。

Go 内存管理构成了多级缓存机制，从 OS 分配得的内存被内存管理回收后，也不会立刻归还给 OS，而是在 Go runtime 内部先缓存起来，从而避免频繁向 OS 申请内存。

TCMalloc: TC is short for thread caching
每个p包含一个mcache用于快速分配，用于为绑定于p上的g分配对象
mcache管理一组mspan
当mchche中的mspan分配完毕，向mcentral申请带有未分配块的mspan
当mspan中没有分配的对象，mspan会被缓存在mcentral中，而不是立刻释放并归还给OS

内存分配的路线图如下： Go内存分配

Go内存管理问题

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

对象分配是非常高频的操作：每秒分配 GB 级别的内存
小对象分配占大多数
Go内存分配比较耗时
- 分配路径长：g -> m -> p -> mcache -> mspan -> memory block -> return pointer
- 线上 profiling 发现，对象分配的函数是最频繁调用的函数之一

字节跳动优化方案：Balanced GC

核心：将 noscan 对象在 per-g allocation buffer (GAB) 上分配，并使用移动对象 GC 管理这部分内存，提高对象分配和回收效率

GAB

每个 g 会附加一个较大的 allocation buffer (例如 1 KB) 用来分配小于 128 B 的 noscan 小对象
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 指针并返回，快速完成一次对象分配(指针碰撞策略)
每个GoRoutine占用一块GAB，无须和其他分配请求互斥
同原先调用 mallocgc() 进行对象分配的方式相比，balanced GC 缩短了对象分配的路径，减少了对象分配执行的指令数目，降低 CPU 使用

从 Go runtime 内存管理模块的角度看，一个 allocation buffer 其实是一个大对象。本质上 balanced GC 是将多次小对象的分配合并成一次大对象的分配。因此，当 GAB 中哪怕只有一个小对象存活时，Go runtime 也会认为整个大对象（即 GAB）存活。为此，balanced GC 会根据 GC 策略，将 GAB 中存活的对象移动到另外的 GAB 中，从而压缩并清理 GAB 的内存空间，原先的 GAB 空间由于不再有存活对象，可以全部释放(Copying GC)，如下图所示:

上图上方是两个 GAB，其中虚线表示 GAB 中对象的分界线。黑色表示 GAB 中存活的对象，白色表示死掉的对象。由于 GAB 中有存活对象，整个 GAB 无法被回收。 Balanced GC 会将 GAB 中存活的对象移动到下面的 GAB 中，这样原先的两个 GABs 就可以被释放，压缩并清理 GAB 的内存空间。 Balanced GC 只负责 noscan 对象的分配和移动，对象的标记和回收依然依赖 Go GC 本身，并和 Go GC 保持兼容。

小知识：

为什么GAB只针对noscan？因为GAB本身就带有延迟释放的特点，如果GAB存放了scan对象，就会把一连串的对象标活了，同时即使该scan对象是死了的，但由于GAB的延迟特性导致一大块内存无法尽快释放。
Go对象没有对象头，是用额外的内存空间来存放对象的大小的。
GMP：Go调度思路
更多Go内存管理参考资料：详解Go语言的内存模型及堆的分配管理

3. 编译器和静态分析

编译器的结构

静态分析

静态分析：不执行代码，推导程序的行为，分析程序的性质。
控制流（control flow）：程序的执行流程
数据流（data flow）：数据在控制流上的传递
通过分析控制流和数据流，我们可以知道更多关于程序的性质(properties) ，这些事实可以帮助我们做编译优化。

过程内分析和过程间分析

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

4. Go编译器优化

目的

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

现状

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

思路

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

Beast Mode

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

函数内联

定义：将被调用函数的函数体(callee)的副本替换到调用位置(caller)上，同时重写代码以反映参数的绑定
优点
- 消除调用开销
- 将过程间分析的问题转换为过程内分析，帮助其他优化，例如逃逸分析
- 使用micro-benchmark能快速验证和对比性能优化结果
缺点
- 函数体变大
- 编译生成的 Go 镜像文件变大
函数内联在大多数情况下是正向优化，即多内联，会提升性能
采取一定的策略决定是否内联
- 调用和被调用函数的规模

Beast Mode

Go 内联的限制
- 语言特性：interface, defer 等等，限制了内联优化
- 内联策略非常保守
字节跳动的优化方案
- 修改了内联策略，让更多函数被内联
- 增加了其他优化的机会：逃逸分析
开销
- Go 镜像大小略有增加
- 编译时间增加
- 运行时栈扩展开销增加

逃逸分析

定义：分析代码中指针的动态作用域，即指针在何处可以被访问

大致思路

从对象分配处出发，沿着控制流，观察数据流。
若发现指针 p 在当前作用域 s:
- 作为参数传递给其他函数；
- 传递给全局变量；
- 传递给其他的 goroutine;
- 传递给已逃逸的指针指向的对象；
则指针 p 逃逸出 s，反之则没有逃逸出 s.

Beast Mode：内联函数拓展了函数边界，更多对象不逃逸

优化：未逃逸出当前函数的指针指向的对象可以在栈上分配

对象在栈上分配和回收很快：移动 sp 即可完成内存的分配和回收；
减少在堆上分配对象，降低 GC 负担。

课程总结

性能优化：

自动内存管理
Go内存管理
编译器与静态分析
编译器优化

落地实践：

Balanced Gc优化对象分配（GAB）
Beast Mode 提升代码性能

课后思考

从业务层和语言运行时层进行优化分别有什么特点？

业务层优化针对特定的业务场景，具体问题具体分析，容易获得较大的性能收益。

语言运行时优化解决更通用的性能问题，考虑了更多场景。
从软件工程的角度出发，为了保证语言 SDK 的可维护性和可拓展性，在进行运行时优化时需要注意什么？
- 保证软件的质量
- 在保证接口稳定的前提下改进具体实现
- 编写的测试用例要覆盖尽可能多的场景，方便回归
- 做了什么、没做什么、能达到什么样的效果都需要用文档记录下来
- 优化的部分和未优化的部分要隔离起来，通过选项控制是否开启优化
- 性能优化的结果要可观测的，可通过日志记录这些结果
自动内存管理技术从大类上分为哪两种，每一种技术的特点以及优缺点有哪些？

自动内存管理技术可分为基于追踪的垃圾回收和引用计数。

基于追踪的垃圾回收：对象被回收的条件：指针指向关系不可达对象，有如下步骤：
1. 标记根对象：静态变量、全局变量、常量、线程栈等
2. 求指针指向关系的传递闭包：从根对象出发，找到所有可达对象
3. 清理：回收所有不可达对象占据的内存空间，有以下策略
  - Copying GC：将存活对象从一块内存空间复制到另外一块内存空间，原先的空间可以直接进行对象分配
    
    优点：实现简单，运行高效且不容易产生内存碎片。
    
    缺点：对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。
  - Mark-sweep GC: 将死亡对象所在内存块标记为可分配，使用 free list 管理可分配的空间
    
    优点：实现简单
    
    缺点：容易产生内存碎片，碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作。
  - Mark-compact GC: 将存活对象复制到同一块内存区域的开头，原地整理对象
    
    优点：不会产生内存碎片，同时解决了Copying GC导致的内存开销大的问题。
    
    缺点：实现较复杂
总结：基于追踪的垃圾回收效率不高，垃圾回收时需要stop the world，导致用户体验差

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

分代假说认为很多对象在分配出来后很快就不再使用了，目的是针对不同周期的内存对象制定不同的GC策略，从而降低整体内存管理的开销。例如对于年轻代对象，由于存活周期短，可采用Copying GC策略，而对于老年代对象，趋向于一直活着，反复复制开销较大，可以采用Mark-sweep GC策略。
Go 是如何管理和组织内存的？

Go基于分块以及由mspan, mcache 和 mcentral 构成的多级缓存机制实现内存管理和组织。
为什么采用 bump-pointer 的方式分配内存会很快？
- bump-pointer方式在分配对象时，根据对象大小移动 top 指针并返回，可快速完成一次对象分配。
- 同原先调用 mallocgc() 进行对象分配的方式相比，缩短了对象分配的路径，减少了对象分配执行的指令数目，降低 CPU 使用
- 每个Go Routine占用一块GAB，无须和其他分配请求互斥
为什么我们需要在编译器优化中进行静态代码分析？
- 静态代码分析通过才去不执行代码的方式，推导程序的行为，分析程序的性质。
- 通过分析控制流和数据流，我们可以知道更多关于程序的性质，这些性质可以帮助我们做编译优化。牺牲一些编译时间，换取运行时性能的提高。
函数内联是什么，这项优化的优缺点是什么？

函数内联：将被调用函数的函数体(callee)的副本替换到调用位置(caller)上，同时重写代码以反映参数的绑定
优点
- 消除调用开销
- 将过程间分析的问题转换为过程内分析，帮助其他优化，例如逃逸分析
- 使用micro-benchmark能快速验证和对比性能优化结果
缺点
- 函数体变大
- 编译生成的 Go 镜像文件变大
函数内联在大多数情况下是正向优化，即多内联，会提升性能，需要采取一定的策略决定是否内联。

什么是逃逸分析？逃逸分析是如何提升代码性能的？

逃逸分析：分析代码中指针的动态作用域，即指针在何处可以被访问
- 从对象分配处出发，沿着控制流，观察数据流。
- 若发现指针 p 在当前作用域 s:
  - 作为参数传递给其他函数；
  - 传递给全局变量；
  - 传递给其他的 goroutine;
  - 传递给已逃逸的指针指向的对象；
- 则指针 p 逃逸出 s，反之则没有逃逸出 s.
由于Beast Mode使内联函数拓展了函数边界，更多对象不逃逸，未逃逸出当前函数的指针指向的对象可以在栈上分配，对象在栈上分配和回收很快，同时减少在堆上分配对象，降低 GC 负担，从而提高性能。

高性能Go语言发行版优化与落地实践课堂笔记+课后思考题 | 青训营笔记

大纲

前言

1. 自动内存管理

基于追踪的垃圾回收

分代GC（Generational GC）

引用计数

总结

2. Go内存管理及优化

Go内存分配——分块

Go内存分配——缓存

Go内存管理问题

字节跳动优化方案：Balanced GC

3. 编译器和静态分析

编译器的结构

静态分析

过程内分析和过程间分析

4. Go编译器优化

函数内联

Beast Mode

逃逸分析

课程总结

课后思考