这是我参与「第五届青训营」伴学笔记创作活动的第 4 天

[ Go内存管理及性能与编译优化 | 青训营笔记 ]

零、前言：

本节课将主要介绍关于高性能 Go 语言发行版优化的内存管理，分享自动内存管理与 Go 内存管理知识，提供可行性的优化建议。

本文记录和整理了本人在跟随字节青训营学习的一些我个人感觉比较重要的内容和知识，也有一部分内容是我认为自己比较难理解或记忆的，也一并记录于此文。撰写本文的目的主要是方便我自己的复习和查阅，倘若各位读者有与我相似的问题，也可以参考之，如果对各位有帮助那就是我莫大的荣幸，也期望各位不吝赐教，多多指出我的问题，可以在下方留言或者私信我。

一、本堂课重点内容：

高性能Go语言发行版优化与落地实践
优化：内存管理优化 + 编译器优化
背景：自动内存管理和Go内存管理机制 & 编译器优化的基本问题和思路
实践：字节跳动公司遇到的性能问题以及优化方案简介

二、详细知识点介绍

0. 性能优化

性能优化 -> 提升软件处理系统的能力 -> 资源高效利用 -> 提升用户体验

性能优化的层面

由于自顶向下的是业务代码、SDK、基础库、语言运行时以及OS，所以性能优化有着针对不同层面的优化：

业务层优化：可以理解为做菜的时候学习菜谱，这道菜就会很好吃，很标准
- 针对特定场景，具体问题，具体分析
- 比较容易获得较大的性能收益
语言运行时优化：可以理解为磨刀，这样对于任何菜肴，切割食材就会变得容易
- 解决更通用的性能问题
- 考虑更多场景
- Tradeoffs

无论是哪种层面的性能优化，都需要数据作为驱动：

数据驱动
- 自动化性能分析工具——pprof
- 依靠数据而非猜测，实事求是
- 首先优化最大瓶颈

性能优化与软件质量

软件质量至关重要
在保证接口稳定的前提下，改进具体实现（不然变成屎山了）
测试用例：覆盖尽可能多的场景，方便回归
文档：说明清楚功能和效果
隔离：通过选项控制是否开启优化（省钱）
可观测：必要的日志输出（看清楚搞明白）

事实上，我们在实际工作中写代码，就是在写SDK里面的代码；

那么SDK究竟是什么呢？可能有的小伙伴很清楚，那就可以跳过这部分。

SDK：

即Software Development Kit的缩写，译作软件开发工具包。软件开发工具包是一个覆盖面相当广泛的名词，你甚至可以这么理解：辅助开发某一类软件的相关文档、范例和工具的集合都可以叫做SDK。

SDK的组成：

一个完整的SDK应该包括以下内容：

接口文件和库文件：笼统地说就是API。通过将底层的代码进行封装保护，提供给用户一个调用底层代码的接口。
帮助文档：用来解释接口文件和库文件（即API）的功能，以及介绍相关的开发工具，操作示例等。
开发示例：即简单的成品DEMO展示，包括源代码。
实用工具：通常是指用来协助用户进行二次开发的工具，比如二次开发向导、API 搜索工具、软件打包工具等。

avatar

1. 自动内存管理

自动内存管理的基本概念

动态内存：

程序在运行时根据需求动态分配的内存：类似于C语言的malloc()

自动内存管理（垃圾回收）：由程序语言的运行时系统管理动态内存

避免手动内存管理，专注于实现业务逻辑（勤奋的目的是为了懒）
保证内存使用的正确性和安全性，防止出现double-free problem & use-after-free problem

GC的三个任务：（战场清理大师）

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

接下来让我们先明确一些名词的概念，同样，如果你已经掌握了，那么可以直接跳过：

Mutator：业务线程，分配新对象，修改对象指向关系
Collector：GC线程，找到存活对象，回收死亡对象的内存空间
Serial GC：只有一个collector
Parallel GC：支持多个collectors同时回收的GC算法
Concurrent GC：mutator(s) 和 collector(s) 可以同时执行

avatar

特别地，Collectors 必须感知对象指向关系的改变；

如上图例子，最右边被红色箭头指向的b是在GC过程中被用户新创建出来的对象，但是这个时候没有被标记，Collectors必须标记它，这个时候如果存活就标记为存活，否则为不存活的话有可能会发生错误。

GC算法的一些补充：

安全性：不能回收存活的对象 基本要求
吞吐率：1 - GC时间 / 程序执行总时间 花在GC上的时间
暂停时间：stop the word (STW) 业务是否感知
内存开销：GC元数据开销

追踪垃圾回收

对象被回收的条件：指针指向关系不可达的对象

步骤：

标记root对象：包括静态变量、全局变量、常量和线程栈等等；
标记可达对象：求指针指向关系的传递闭包：从根对象出发，找到所有可达对象；
清理所有不可达对象：
- 将存活对象复制到另外的内存空间 (Copying GC)
- 将死亡对象的内存标记为"可分配" (Mark-sweep GC)
- 移动并整理存活对象 (Mark-compact GC)
根据对象的生命周期，使用不同的标记和清理策略

avatar

分代GC (Generational GC)

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

引用计数

每个对象都有一个与之关联的引用数目；

对象存活的条件：当且仅当引用数>0

这样做的优点是：

内存管理的操作被平摊到程序执行过程中
内存管理不需要了解runtime的实现细节：C++智能指针(smart pointer)

这样做的缺点也是有的：

维护引用计数的开销较大：通过原子操作保证对引用计数的原子性和可见性
无法回收环形数据结构——weak reference
内存开销：每个对象都引入的额外内存空间存储引用数目
回收内存时依然可能引发暂停

2. Go内存管理及优化

Go内存分配——分块

目标：提前为对象在heap上分配内存

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

Go内存分配——缓存

缓存过程：

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

一图以释之：

avatar

Go内存管理优化

一些须知：

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

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

每个g都绑定一大块内存（1KB），称作goroutine allocation buffer (GAB)
GAB用于noscan类型的小对象分配：< 128B
使用三个指针维护GAB：base基地址, end结束地址, top当前地址
Bump pointer（指针碰撞）风格对象分配：
- 无需和其他分配请求互斥
- 分配动作简单高效（移动top指针）
```
if top + size <= end {
	addr := top
	top += size
	return addr
}
```

Balanced GC的一些细节：

GAB对于Go内存来说是一个大对象
本质：将多个小对象的分配合并成一次大对象的分配
问题：GAB的对象分配方式会导致内存被延迟释放
方案：移动GAB中的存活对象
- 当GAB总大小超过一定阈值时，将GAB中存活的对象复制到另外分配的GAB中
- 原先的GAB可以释放，避免内存泄漏
- 本质：用copying GC的算法管理小对象（根据对象的生命周期，使用不同的标记和清理策略）

avatar

3. 编译器和静态分析

编译器的结构：

avatar

重要的系统软件
- 识别符合语法和非法的程序
- 生成正确且高效的代码
分析部分：（前端 front end）
- 词法分析：生成词素（lexeme）
- 语法分析：生成语法树
- 语义分析：收集类型信息，进行语义检查
- 中间代码生成：生成intermediate representation（IR）
综合部分：（后端 back end）
- 代码优化：机器无关代码，生成优化后的IR
- 代码生成：生成目标代码

静态分析

控制流和数据流

静态分析：不执行程序代码，推导程序的行为，分析程序的性质。

常见的两种分析：

控制流：程序执行的流程
数据流：数据在控制流上的传递

控制流图示：

avatar

通过分析控制流和数据流，我们可以知道更多关于程序的性质（properties），根据这些性质优化代码。

过程内分析和过程间分析

过程内分析：仅在函数内部进行分析

过程间分析：考虑过程调用时参数传递和返回值的数据流和控制流

过程间分析的难点：

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

4. Go编译器优化

编译优化的思路：

场景：面向后端长期执行任务
Tradeoff：用编译时间换取更高效的机器码

Beast mode：

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

函数内联 inlining

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

优点：

清除函数调用开销，例如传递参数、保存寄存器等
将过程间分析转化为过程内分析，帮助其他优化，例如逃逸分析

逃逸分析解释：分析代码中指针的动态作用域：指针在何处可以被访问

// 一个使用micro-benchmark的性能测试
func BenchmarkInline(b *testing.B) {
    x := genInteger()
    y := genInteger()
    for i := 0; i < n.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 < n.N; i++ {
        addNoInline(x, y)
    }
}

// go:noinline
func addNoInline(a, b int) int {
    return a + b
}
// 大约可以提升4.58倍的性能

缺点：

函数体变大，instruction cache不友好（大概就是会占用很多的意思）
编译生成的Go镜像变大（时间换空间的感觉）

函数内联在大多数情况下是正向优化

Beast Mode

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

相当于是一个折中的方法。

该种方法下的逃逸分析大致思路：

avatar

三、相关术语解读

自动内存管理

Auto memory management: 自动内存管理
Grabage collction: 垃圾回收
Mutator: 业务线程
Collector: GC 线程
Concurrent GC: 并发 GC
Parallel GC: 并行 GC
Tracing garbage collection: 追踪垃圾回收
- Copying GC: 复制对象 GC
- Mark-sweep GC: 标记-清理 GC
- Mark-compact GC: 标记-压缩 GC
Reference counting: 引用计数
Generational GC: 分代 GC
- Young generation: 年轻代
- Old generation: 老年代

Go 内存管理及优化

TCMalloc
mmap() 系统调用
scan object 和 noscan object
mspan, mcache, mentral
Bump-pointer object allocation: 指针碰撞风格的对象分配

编译器和静态分析

词法分析
语法分析
语义分析
Intermediate representation (IR) 中间表示
代码优化
代码生成
Control flow: 控制流
Data flow: 数据流
Intra-procedural analysis 过程内分析
Inter-procedural analysis: 过程间分析

Go 编译器优化

Function inlining: 函数内联
Escape analysis: 逃逸分析

未完待续...（随时补充修改）

谢谢大家的阅读，欢迎互动，也欢迎访问我的博客！

conqueror712.github.io/