这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
part 1. 自动内存管理
自动内存管理
GC : Grabage collction
- Mutator: 业务线程
- Collector: GC 线程
有三种回收线程的方式:
- Serial GC : 单独一个collector 进行回收工作
- Parallel GC : 多collector 并行 GC
- Concurrent GC: 在多个collector进行回收的同时 业务线程仍然保持工作
如果采用Concurrent GC的方式 则必须保证collector能感知对象指向关系的改变
线程回收方式有两种:
-
追踪垃圾回收方法
-
首先标记根对象
-
扩展标记找到所有存活对象
-
删除所有未被标记的对象 清除过程:
- Copying GC: 复制对象 GC - Mark-sweep GC: 标记-清理 GC - Mark-compact GC: 标记-压缩 GC
-
-
引用计数
-
每个对象都有一个与之关联的引用数目
-
对象存活的条件:当且仅当引用数大于 0
-
优点
- 内存管理的操作被平摊到程序运行中:指针传递的过程中进行引用计数的增减
- 不需要了解 runtime 的细节:因为不需要标记 GC roots,因此不需要知道哪里是全局变量、线程栈等
-
缺点
-
开销大,因为对象可能会被多线程访问,对引用计数的修改需要原子****操作保证原子性和可见性
-
无法回收环形数据结构
-
每个对象都引入额外存储空间存储引用计数
-
虽然引用计数的操作被平摊到程序运行过程中,但是回收大的数据结构依然可能引发暂停
-
-
-
Generational GC: 分代 GC
- Young generation: 年轻代
- Old generation: 老年代
part 2. Go 内存管理及优化
内存管理:
- 类似于TC malloc的思想
- 首先 mmap()申请一大块空间
- 把内存从大块切割成为小块 称为mspan 分为scan mspan 和 noscan mspan
- noscan mspan: 分配不包含指针的对象 —— GC 不需要扫描
- scan mspan: 分配包含指针的对象 —— GC 需要扫描
- 根据申请的大小找到适合的块直接返回而不是每次都申请
内存缓存 :Go 内存管理构成了多级缓存机制,从 OS 分配得的内存被内存管理回收后,也不会立刻归还给 OS,而是在 Go runtime 内部先缓存起来,从而避免频繁向 OS 申请内存。内存分配的路线图如下。
-
mspan, mcache, mcentral mheap的区别:
Golang中内存管理的层级从最下到最上可以分为:mspan -> mcache -> mcentral -> mheap -> heapArena。golang中对象的内存分配流程如下:
小于16个字节的对象使用mcache的微对象分配器进行分配内存
大小在16个字节到32k字节之间的对象,首先计算出需要使用的span大小规格,然后使用mcache中相同大小规格的mspan分配
如果对应的大小规格在mcache中没有可用的mspan,则向mcentral申请
如果mcentral中没有可用的mspan,则向mheap申请,并根据BestFit算法找到最合适的mspan。如果申请到的mspan超出申请大小,将会根据需求进行切分,以返回用户所需的页数,剩余的页构成一个新的mspan放回mheap的空闲列表
如果mheap中没有可用span,则向操作系统申请一系列新的页(最小 1MB)
对于大于32K的大对象直接从mheap分配
- mspan:是一个双向链表结构。mspan是golang中内存分配管理的基本单位。
- mcache:mcache持有一系列不同大小的mspan。mcache属于per-P cache,由于M运行G时候,必须绑定一个P,这样当G中申请从mcache分配对象内存时候,无需加锁处理。
- mcentral: 一个mecentral只负责一个规格span,规格类型记录在mcentral的spanClass字段中。mcentral维护着两个双向链表,
- mheap :当mecentral没有可用的span时候,会向mheap申请。
内存管理优化:
- 对象分配是非常高频的操作:每秒分配 GB 级别的内存
- 线上 profiling 发现,Go 的内存分配占用很多 CPU 可以看到,
- 用于分配对象的函数 mallocgc() 占用 CPU 较高
不难得出 对于小空间的处理是关键
字节跳动的优化方案
-
Balanced GC
-
核心:将 noscan 对象在 per-g allocation buffer (GAB) 上分配,并使用移动对象 GC 管理这部分内存,提高对象分配和回收效率
-
每个 g 会附加一个较大的 allocation buffer (例如 1 KB) 用来分配小于 128 B 的 noscan 小对象
-
bump pointer 风格的对象分配。
-
分配对象时,根据对象大小移动
top指针并返回,快速完成一次对象分配 -
同原先调用
mallocgc()进行对象分配的方式相比,balanced GC 缩短了对象分配的路径,减少了对象分配执行的指令数目,降低 CPU 使用
从 Go runtime 内存管理模块的角度看,一个 allocation buffer 其实是一个大对象。本质上 balanced GC 是将多次小对象的分配合并成一次大对象的分配。因此,当 GAB 中哪怕只有一个小对象存活时,Go runtime 也会认为整个大对象(即 GAB)存活。为此,balanced GC 会根据 GC 策略,将 GAB 中存活的对象移动到另外的 GAB 中 ,从而压缩并清理 GAB 的内存空间,原先的 GAB 空间由于不再有存活对象,可以全部释放
Balanced GC 会将 GAB 中存活的对象移动到下面的 GAB 中,这样原先的两个 GABs 就可以被释放,压缩并清理 GAB 的内存空间。
Balanced GC 只负责 noscan 对象的分配和移动,对象的标记和回收依然依赖 Go GC 本身,并和 Go GC 保持兼容。
part 3. 编译器和静态分析
相关概念
- 静态分析:不执行代码,推导程序的行为,分析程序的性质。
- 控制流:程序的执行流程
- 数据流:数据在控制流上的传递
- 通过分析控制流和数据流,我们可以知道更多关于程序的性质(properties) ,这些事实可以帮助我们做编译优化。
- Intra-procedural analysis: 函数内分析:在函数内进行控制流和数据流的分析
- Inter-procedural analysis: 函数间分析:除了函数内的分析,还需要考虑跨函数的数据流和控制流,例如参数传递,函数返回值等
part 4. Go 编译器优化
函数内联
-
定义:将被调用函数的函数体的副本替换到调用位置上,同时重写代码以反映参数的绑定
-
优点
- 消除调用开销
- 将过程间分析的问题转换为过程内分析,帮助其他分析
-
缺点
- 函数体变大
- 编译生成的 Go 镜像文件变大
-
采取一定的策略决定是否内联: 调用和被调用函数的规模
-
字节跳动的优化方案
-
Go 内联的限制
- 语言特性:interface, defer 等等,限制了内联优化
- 内联策略非常保守
-
修改了内联策略,让更多函数被内联
-
增加了其他优化的机会:逃逸分析
-
开销
- Go 镜像大小略有增加
- 编译时间增加
- 运行时栈扩展开销增加
-
逃逸分析
- 定义:分析代码中指针的动态作用域,即指针在何处可以被访问
-
大致思路
-
从对象分配处出发,沿着控制流,观察数据流。若发现指针 p 在当前作用域 s:
- 作为参数传递给其他函数;
- 传递给全局变量;
- 传递给其他的 goroutine;
- 传递给已逃逸的指针指向的对象;
-
则指针 p 逃逸出 s,反之则没有逃逸出 s.
-
-
优化:未逃逸出当前函数的指针指向的对象可以在栈上分配
-
对象在栈上分配和回收很快:移动 sp 即可完成内存的分配和回收;
-
减少在堆上分配对象,降低 GC 负担。
-
参考资料
码风略丑 读者见谅 --2023/2/4