Go 性能优化&内存管理
1.性能优化
-
性能优化层面
- 业务层优化
- 针对特定场景,具体问题,具体分析
- 容易获得较大性能收益
- 语言运行时优化
- 解决更通用的性能问题
- 考虑更多场景
- Tradeoffs
语言运行时 : 提供语言时限, 比如 GC 、调度器等;典型的高级语言**「运行时系统」(运行时库包括标准库)**里大概需要这些基础组件:
- 一个解释执行字节码的虚拟机,多半得带个垃圾回收器。
- 如果语言是源码解释执行,那么需要一个编译器前端做词法分析和语法分析。
- 如果运行时支持 JIT 优化,那么还得藏着个编译器后端(动态生成机器码)。
- IO 相关能力,比如 Node.js 的
fs.readFile之类。

- 数据驱动
- 自动化性能分析工具 —— pprof
- 依靠数据而非猜测
- 首先优化最大瓶颈
2. 自动内存管理(垃圾回收)
GO 语言内存由程序语言的运行时系统管理动态内存,而不需要程序员手动内存管理,保证内存使用的正确性和安全性。
自动内存管理任务:
-
为新对象分配空间
-
找到存活对象
-
回收死亡对象的内存空间
-
相关概念
- Mutator: 业务线程,分配新对象,修改对象指向关
- Collector: GC 线程,找到存活对象,回收死亡对象的内存空间
- Serial GC: 只有一个 collector
- Parallel GC: 并行 GC,支持多个 collectors 同时回收的 GC 算法
- Concurrent GC: 并发 GC,支持 mutator(s) 和 collector(s) 同时执行的 GC 算法(要求更高)

垃圾回收算法:
1. 追踪垃圾回收
对象被回收的条件:指针指向关系不可达的对象
-
标记根对象 静态变量、全局变量、常量、线程栈等
-
标记:找到可达对象,求指针指向关系的传递闭包:从根对象出发,找到所有可达对象

-
清理策略: 所有不可达对象
- 将存活对象复制到另外的内存空间 (Copying GC)

- 将死亡对象的内存标记为“可分配”(Mark-sweep GC)

- 移动并整理存活对象,将存活对象复制到同一块内存区域的开头 (Mark-compact GC)

2. 引用计数法
C++ RAII资源自动管理 unique_ptr, share_ptr weak_ptr 使用的回收算法就是引用计数算法
-
每个对象都有一个与之关联的引用数目
-
对象存活的条件:当且仅当引用数大于 0
-
优点
- 内存管理的操作被平摊到程序运行中:指针传递的过程中进行引用计数的增减
- 不需要了解 runtime 的细节:因为不需要标记 GC roots,因此不需要知道哪里是全局变量、线程栈等
-
缺点
-
开销大,因为对象可能会被多线程访问,对引用计数的修改需要原子****操作保证原子性和可见性
-
无法回收环形数据结构
-
每个对象都引入额外存储空间存储引用计数
-
虽然引用计数的操作被平摊到程序运行过程中,但是回收大的数据结构依然可能引发暂停
-
3. 分代GC

评价GC算法指标

3. GO 内存管理及优化:
-
TCMalloc: TC is short for thread caching
-
目标:为对象在 heap 上分配内存
-
提前将内存分块
-
调用系统调用 mmap() 向 OS 申请一大块内存,例如 4 MB
-
先将内存划分成大块,例如 8 KB,称作 mspan
-
再将大块继续划分成特定大小的小块,用于对象分配
-
noscan mspan: 分配不包含指针的对象 —— GC 不需要扫描
-
scan mspan: 分配包含指针的对象 —— GC 需要扫描
-

对象分配:根据对象的大小,选择最合适的快返回。
-
内存缓存 – 后面再对比下 STL 内存分配池
Go 内存管理构成了多级缓存机制,从 OS 分配得的内存被内存管理回收后,也不会立刻归还给 OS,而是在 Go runtime 内部先缓存起来,从而避免频繁向 OS 申请内存。内存分配的路线图如下:(g – groutine )

-
GO 内存管理优化
mspan, mcache 和 mcentral 构成了内存管理的多级缓存机制。
-
对象分配是非常高频的操作:每秒分配 GB 级别的内存
-
线上 profiling 发现,Go 的内存分配占用很多 CPU
-
优化对象分配是关键
-
-
字节优化方案 – Balanced GC:
核心:将 noscan 对象在 per-g allocation buffer (GAB) 上分配,并使用移动对象 GC 管理这部分内存,提高对象分配和回收效率。

if g.ab.end - g.ab.top < size { // Allocate a new allocation buffer } addr := g.ab.top g.ab.top += size return addr从 Go runtime 内存管理模块的角度看,一个 allocation buffer 其实是一个大对象。本质上 balanced GC 是将多次小对象的分配合并成一次大对象的分配。因此,当 GAB 中哪怕只有一个小对象存活时,Go runtime 也会认为整个大对象(即 GAB)存活。为此,balanced GC 会根据 GC 策略,(coping GC 算法)将 GAB 中存活的对象移动到另外的 GAB 中,从而压缩并清理 GAB 的内存空间,原先的 GAB 空间由于不再有存活对象,可以全部释放,如下图所示:

未完待续…
图片均来自字节青训营课程,博客作为自己学习记录,如有侵权,麻烦联系删除。
1013

被折叠的 条评论
为什么被折叠?



