这是我参与「第五届青训营」伴学笔记创作活动的第 10 天
下面相关内容仅供本人回顾使用。如有错误，烦请评论反馈，感激不尽！！！
追踪垃圾回收
对象被回收的条件：指针指向关系不可达的对象
步骤：
-
标记root对象：包括静态变量、全局变量、常量和线程栈等等；
-
标记可达对象：求指针指向关系的传递闭包：从根对象出发，找到所有可达对象；
-
清理所有不可达对象：
- 将存活对象复制到另外的内存空间 (Copying GC)
- 将死亡对象的内存标记为"可分配" (Mark-sweep GC)
- 移动并整理存活对象 (Mark-compact GC)
-
根据对象的生命周期，使用不同的标记和清理策略
分代GC (Generational GC)
-
分代假说：most objects die young
-
Intuition：很多对象在分配出来后很快就不再使用了（英年早逝）
-
每个对象都有年龄：经历过GC的次数
-
目的：对年轻和老年的对象，指定不同的GC策略，降低整个提内存管理的开销
-
不同年龄的对象处于heap的不同区域
-
年轻代
- 常规的内存分配
- 由于存活对象很少，可以采用copying GC
- GC吞吐率很高
-
老年代
- 对象趋向于一直活着，反复复制开销较大
- 可以采用mark-sweep GC
引用计数
每个对象都有一个与之关联的引用数目；
对象存活的条件：当且仅当引用数>0
这样做的优点是：
- 内存管理的操作被平摊到程序执行过程中
- 内存管理不需要了解runtime的实现细节：C++智能指针(smart pointer)
这样做的缺点也是有的：
- 维护引用计数的开销较大：通过原子操作保证对引用计数的原子性和可见性
- 无法回收环形数据结构——weak reference
- 内存开销：每个对象都引入的额外内存空间存储引用数目
- 回收内存时依然可能引发暂停
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
一图以释之：
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的算法管理小对象（根据对象的生命周期，使用不同的标记和清理策略）
-
