这是我参与「第五届青训营 」伴学笔记创作活动的第 6 天
Go 内存管理
Go 内存管理
Go 内存分配
- 目标：为对象在 heap 上分配内存
- 实现：提前将内存分块，创建对象时返回尺寸最接近的块
分块
提前将内存分块
- 调用 系统调用 mmap() 向 OS 申请一大块内存，例如 4MB
- 先将内存划分成大块，例如 8KB，称作 mspan
- 再将大块继续划分成特定大小的小块，用于对象分配
- noscan mspan：分配不包含指针的对象，即 GC 不需要扫描
- scan mspan：分配包含指针的对象，即 GC 需要扫描
缓存
- TCMalloc: thread caching
- 每个 p 包含一个 mcache 用于快速分配，为绑定于 p 上的 g 分配对象
- mcache 管理一组 mspan
- 当 mcache 中的 mspan 分配完毕，向 mcentral 申请带有未分配块的 mspan
- 当 mspan 中没有分配的对象，mspan 会被缓存在 mcentral 中，而不是立刻释放并归还给 OS
优化
思路
-
对象的分配是非常高频的操作：每秒分配 GB 级别的内存（常见
-
同时，小对象占比非常高
-
Go 原本的内存分配比较耗时
- 原因是分配路径长：g -> m -> p -> mcache -> mspan -> memory block -> return pointer
Balanced GC
-
给每个 g 绑定一大块内存（1KB），称作 goruntine allocation buffer (GAB)
-
GAB 用于 noscan 类型的小对象（< 128B）分配
-
使用三个指针维护 GAB:
- base
- top
- end
-
指针碰撞（Bump pointer）风格对象分配
-
无须和其他请求互斥
-
分配动作简单高效
if top + size <= end { addr := top top += size return addr }
-
-
细节
-
GAB 对于 Go 内存管理而言是一个大对象
-
本质：将多个小对象的分配合并成一次大对象的分配
-
问题：GAB 的对象分配方式会导致内存被延迟释放
-
方法：移动 GAB 中存活的对象
-
当 GAB 总大小超过一定阈值时，将 GAB 中存活的对象复制到另外分配的 GAB 中
-
原先的 GAB 可以释放，避免内存泄漏
-
本质：用 copying GC 的算法管理小对象（根据对象的生命周期，使用不同的标记和清理策略）
-
-
我的疑惑
GAB 相当于提前注册了一大块内存，如果 GAB 不饱和是否意味着浪费一大块内存（当时课还没讲到 GAB 延迟释放相关的东西
