这是我参与「第三届青训营 -后端场」笔记创作活动的的第 4 篇笔记。
本节课你能学到什么
- 自动内存管理
- 自动内存管理概念
-
Tracing garbage collection: 追踪垃圾回收
-
Copying GC: 复制对象 GC
-
Mark-sweep GC: 标记-清理 GC
-
Mark-compact GC: 标记-压缩 GC
-
Generational GC: 分代 GC
- Reference counting: 引用计数
- 总结
2. Go 内存管理及优化
- 编译器和静态分析
- 编译器的结构
- Go 编译器优化
-
Go 内联的限制
- 语言特性：interface, defer 等等，限制了内联优化
- 内联策略非常保守
-
字节跳动的优化方案
- 修改了内联策略，让更多函数被内联
- 增加了其他优化的机会：逃逸分析
-
开销
- Go 镜像大小略有增加
- 编译时间增加
- 运行时栈扩展开销增加
逃逸分析
课后
- 从业务层和语言运行时层进行优化分别有什么特点？ 业务层优化：针对具体场景，具体问题，具体分析，容易获得较大的收益 语言运行时优化：解决更通用的性能问题，考虑更多场景
- 从软件工程的角度出发，为了保证语言 SDK 的可维护性和可拓展性，在进行运行时优化时需要注意什么？
保证接口稳定的前提下改进实现
- 测试驱动
- 通过清晰的文档告诉用户这一项优化做了什么，没做什么，能达到怎样的效果
- 隔离，优化代码用选项和原先的路径隔离，保证优化未启用时的行为同以前一致
- 可观测、可灰度、可回滚
- 自动内存管理技术从大类上分为哪两种，每一种技术的特点以及优缺点有哪些？
- 追踪垃圾回收
- 引用计数
- 什么是分代假说？分代 GC 的初衷是为了解决什么样的问题？
- 针对年轻和老龄的对象，制定不同的GC策略，降低整体内存管理的开销
- Go 是如何管理和组织内存的？
-
提前将内存分块
- 调用系统调用 mmap() 向 OS 申请一大块内存，例如 4 MB
- 先将内存划分成大块，例如 8 KB，称作 mspan
- 再将大块继续划分成特定大小的小块，用于对象分配
- noscan mspan: 分配不包含指针的对象 —— GC 不需要扫描
- scan mspan: 分配包含指针的对象 —— GC 需要扫描
- 对象分配：根据对象的大小，选择最合适的块返回
-
内存缓存
- Go 内存管理构成了多级缓存机制，从 OS 分配得的内存被内存管理回收后，也不会立刻归还给 OS，而是在 Go runtime 内部先缓存起来，从而避免频繁向 OS 申请内存。内存分配的路线图如下。
- 为什么采用 bump-pointer 的方式分配内存会很快？
- 每个 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指针并返回，快速完成一次对象分配
- 同原先调用
mallocgc()进行对象分配的方式相比，balanced GC 缩短了对象分配的路径，减少了对象分配执行的指令数目，降低 CPU 使用
- 为什么我们需要在编译器优化中进行静态代码分析？**
- 静态分析：不执行代码，推导程序的行为，分析程序的性质。 通过分析控制流和数据流，我们可以知道更多关于程序的性质(properties) ，这些事实可以帮助我们做编译优化。
- 函数内联是什么，这项优化的优缺点是什么？
- 定义：将被调用函数的函数体的副本替换到调用位置上，同时重写代码以反映参数的绑定
-
优点
- 消除调用开销
- 将过程间分析的问题转换为过程内分析，帮助其他分析
-
缺点
- 函数体变大
- 编译生成的 Go 镜像文件变大
- 什么是逃逸分析？逃逸分析是如何提升代码性能的？
- 定义：分析代码中指针的动态作用域，即指针在何处可以被访问
-
大致思路
-
从对象分配处出发，沿着控制流，观察数据流。若发现指针 p 在当前作用域 s:
- 作为参数传递给其他函数；
- 传递给全局变量；
- 传递给其他的 goroutine;
- 传递给已逃逸的指针指向的对象；
-
则指针 p 逃逸出 s，反之则没有逃逸出 s.
-
-
优化：未逃逸出当前函数的指针指向的对象可以在栈上分配
- 对象在栈上分配和回收很快：移动 sp 即可完成内存的分配和回收；
- 减少在堆上分配对象，降低 GC 负担。
