Go 语言内存管理详解

本文来源于第五届字节跳动青训营活动，已收录到Go 语言内存管理详解 | 青训营笔记 - 掘金 (juejin.cn) ，主要记录了对golang内存管理的学习

内存管理详解

追求极致性能

性能优化：提升软件系统处理能力，减少不必要的消耗，充分发掘计算机算力。

性能优化的目的

用户体验：带来用户体验的提升
资源高效利用：降低成本。提高效率

性能优化的层面

业务层优化
- 针对特定场景，具体问题具体分析
- 容易获得较大性能收益
语言运行时优化
- 解决更通用的性能问题
- 考虑更多场景
- Tradeoffs权衡
数据驱动
- 自动化性能分析工具——pprof
- 依靠数据而非猜测
- 首先优化最大瓶颈

性能优化与软件质量

软件质量至关重要
在保证接口稳定的前提下改进具体实现
测试用例：覆盖尽可能多的场景，方便回归
文档：做了什么，没做什么，能达到怎样的效果
隔离：通过选项控制是否开启优化
可观测：必要的日志输出

总结

性能优化的基本问题
性能优化的两个层面
性能优化的可维护性

1.自动内存管理

1.1 自动内存管理

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

相关概念

Mutator：业务线程，分配新对象，修改对象的指向关系
Collector：GC线程，找到存活对象，回收死亡对象的内存空间
Serial GC：只有一个collector
Parallel GC：支持多个collector同时回收的GC算法
Concurrent GC：mutator(s)和collector(s)可以同时执行
Collectors必须感知对象指向关系的改变
评价GC算法
- 安全性（Safety）：不能回收存活的对象。这是基本要求
- 吞吐率（Throughput）： $1-\frac {GC时间}{程序执行总时间}$ 。花在GC上的时间
- 暂停时间（Pause time）：stop the world（STW）。业务是否感知
- 内存开销（Space overhead）：GC元数据开销
追踪垃圾回收（Tracing garbage collection）
引用计数（Reference counting）

1.2 追踪垃圾回收

对象被回收的条件：指针指向关系不可达的对象
标记根对象
- 静态变量、全局变量、常量、线程栈等
标记：找到可达对象
- 求指针指向关系的传递闭包：从根对象出发，找到所有可达对象
清理：所有不可达对象
- 将存活对象复制到另外的内存空间（Copying GC）
  Copying GC：将对象复制到另外的内存空间
- 将死亡对象的内存标记为“可分配”（Mark-sweep GC）
  Mark-sweep GC：使用free list管理空闲内存
- 移动并整理存活对象（Mark-compact GC）
  Compact GC：原地整理对象
根据对象的生命周期，使用不同的标记和清理策略

1.3 分代 GC（Generational GC）

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

1.4 引用计数

每个对象都有一个与之关联的引用数目
对象存活的条件：当且仅当引用数大于0
优点
- 内存管理的操作被平摊到程序执行过程中
- 内存管理不需要了解runtime的实现细节：C++智能指针（smart pointer）
缺点
- 维护引用计数的开销较大：通过原子操作保证对引用计数操作的原子性和可见性
- 无法回收环形数据结构——weak reference
- 内存开销：每个对象都引入的额外内存空间存储引用数目
- 回收内存时依然可能引发暂停

总结

自动内存管理的背景和意义
概念和评价方法
追踪垃圾回收
引用计数
分代 GC
学术界和工业界一直致力于解决自动内存管理技术的不足之处
- 相关信息Low-Latency, High-Throughput Garbage Collection (PLDI 2022 - PLDI Research Papers)
- 相关介绍PLDI’22 | June 13-17，编程语言顶级会议

2.Go管理及优化

2.1 Go 内存分配

分块

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

缓存

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

2.2 Go 内存管理优化

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

2.3 优化方案：Balanced GC

每个 g 都绑定一大块内存（1KB），称作 goroutine allocation buffer（GAB）
GAB 用于 noscan 类型的小对象分配：< 128 B
使用三个指针维护 GAB：base，end，top
Bump pointer（指针碰撞）风格对象分配
- 无须和其他分配请求互斥
- 分配动作简单高效
GAB 对于 Go 内存管理来说是一个大对象
本质：将多个小对象的分配合并成一次大对象的分配
问题：GAB的对象分配方式会导致内存被延迟释放
方案：移动 GAB 中存活的对象
- 当 GAB 总大小超过一定阈值时，将 GAB 中存活的对象复制到另外分配的 GAB 中
- 原先的 GAB 可以释放，避免内存泄漏
- 本质：用 copying GC 的算法管理小对象。根据对象的生命周期，使用不同的标记和清理策略。

性能收益（数据仅供参考）

高峰期 CPU usage 降低 4.6%，核心接口时延下降 4.5%~7.7%

总结

Go 内存管理 — 分块
Go 内存管理 — 缓存
Go 对象分配的性能问题
- 分配路径过长
- 小对象居多
Balanced GC
- 指针碰撞风格的对象分配
- 实现了 copying GC
- 性能收益

3.编译器和静态分析

3.1 编译器的结构

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

后端是优化重点，同时控制流和数据流分析是优化的基础。

3.2 静态分析

静态分析：不执行程序代码，推导程序的行为，分析程序的性质。
控制流（Control flow）：程序执行的流程
数据流（Data flow）：数据在控制流上的传递
通过分析控制流和数据流，可以知道更多关于程序的性质（properties）
根据这些性质优化代码

3.3 过程内分析和过程间分析

过程内分析（Intra-procedural analysis）
- 仅在函数内部进行分析
过程间分析
- 考虑函数调用时参数传递和返回值的数据流和控制流
过程间分析是个问题
- 需要通过数据流分析得知接口 i 的具体类型，才能知道有多个同名方法（比如func (a *A) foo()和func (b *B) foo()）存在时，接口 i 调用的是哪个foo()
- 根据接口的具体类型，产生了新的控制流，i.foo()，分析继续
- 过程间分析需要同时分析控制流和数据流——联合求解，比较复杂

总结

编译器的结构与编译的流程
编译器后端优化
数据流分析和控制流分析
过程内分析和过程间分析

4.Go编译器优化

为什么做编译器优化
- 用户无感知，重新编译即可获得性能收益
- 通用性优化
现状
- 采用的优化少
- 编译时间较短，没有进行复杂的代码分析和优化
编译优化的思路
- 场景：面向后端长期执行任务
- Tradeoff：用编译时间换取更高效的机器码
Beast mode
- 函数内联分析
- 逃逸分析
- 默认栈大小调整
- 边界检查消除
- 循环展开
- …

4.1 函数内联（Inlining）

内联：将被调用函数的函数体（callee）的副本替换到调用位置（caller）上，同时重写代码以反映参数的绑定
优点
- 消除函数调用开销，例如传递函数、保存寄存器等
- 将过程间分析转化为过程内分析，帮助其他优化，例如逃逸分析

函数内联对性能的影响程度——使用 micro-benchmark验证

示例

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
}

func genInteger() int {
	rand.Seed(time.Now().UnixNano())
	return rand.Intn(100)
}

注意这里的//go:noinline是一种编译指示，noinline表示不要内联，固定写法。这种编译指示类似于C语言中的#include。

使用 micro-benchmark快速验证和对比性能优化结果
使用以下命令进行性能测试
1
go test -bench .
缺点
- 函数体变大，instruction cache（icache）不友好
- 编译生成的 Go 镜像变大
函数内联在大多数情况下是正向优化
内联策略
- 调用和被函数的规模
- …

4.2 Beast Mode

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