优化
内存管理优化
自动内存管理
动态内存:程序在运行时根据需求动态分配的内存:malloc()
自动内存管理(垃圾回收):由程序语言的运行时系统管理动态内存
- 避免手动内存管理,专注于实现业务逻辑
- 保证内存使用的正确性和安全性:double-free problem, use-after-free problem
各种GC的区别
- Mutator:业务线程,分配新对象,修改对象指向关系
- Collector:GC 线程,找到存活对象,回收死亡对象的内存空间
- Serial GC:只有一个 collector
- Parallel GC: 支持多个 collectors 同时回收的GC 算法
- Concurrent GC: mutator(s) 和collector(s) 可以同时执行
如何评价GC算法
- 评价GC算法
- 安全性 (Safety):不能回收存活的对象 基本要求
- 吞吐率 (Throughput):
- 暂停时间 (Pause time): stop the world (STW) 业务是否感知
- 内存开销 (Space overhead) GC元数据开销
- 追踪垃圾回收 (Tracing garbage collection)
- 引用计数 (Reference counting)
追踪垃圾回收
- 对象被回收的条件:指针指向关系不可达的对象
- 标记根对象
- 静态变量、全局变量、常量、线程栈等
- 标记:找到可达对象
- 求指针指向关系的传递闭包:从根对象出发,找到所有可达对象
- 清理:所有不可达对象
- 将存活对象复制到另外的内存空间 (Copying GC)
- 将死亡对象的内存标记为"可分配” (Mark-sweep GC)
- 移动井整理存活对象 (Mark-compact GC)
- 根据对象的生命周期,使用不同的标记和清理策略
引用计数回收
- 每个对象都有一个与之关联的引用数目
- 对象存活的条件:当且仅当引用数大于0
- 优点
- 内存管理的操作被平摊到程序执行过程中
- 内存管理不需要了解 runtime 的实现细节:C++智能指针 (smart pointer)
- 缺点
- 维护引用计数的开销较大:通过原子操作保证对引用计数操作的原子性和可见性
- 无法回收环形数据结构—— weak reference
- 内存开销:每个对象都引1入的额外内存空间存储引用数目
- 回收内存时依然可能引发暂停
分代GC
- 分代假说 (Generational hypothesis):most objects die young,新生代里面的对象最容易进行GC。
- Intuition:很多对象在分配出来后很快就不再使用了。
- 每个对象都有年龄:经历过GC 的次数。
- 目的:对年轻代和老年代的对象,制定不同的GC策略,降低整体内存管理的开销。
- 不同年龄的对象处于 heap 的不同区域。
新生代 (Young generation)
- 常规的对象分配
- 由于存活对象很少,可以采用copying collection(标记-复制算法)
- GC吞吐率很高
老年代 (Old generation)
- 对象趋向于一直活着,反复复制开销较大
- 可以采用 mark-sweep collection(标记-清除算法)
内存分配
分块
- 目标:为对象在heap 上分配内存
- 提前将内存分块
- 调用系统调用mmap()向OS申请一大块内存,例如4MB
- 先将内存划分成大块,例如8KB,称作mspan
- 再将大块继续划分成特定大小的小块,用于对象分配
- noscan mspan: 分配不包含指针的对象——GC 不需要扫描
- scan mspan:分配包含指针的对象—— GC 需要扫描
- 对象分配:根据对象的大小,选择最合适的块返回
缓存
- TCMalloc: thread caching
- 每个p包含一个mcache用于快速分配,用于为绑定于口上的g分配对象
- mcache管理一组mspan
- 当mcache中的mspan分配完毕,向mcentral申请带有末分配块的mspan
- 当mspan中没有分配的对象,mspan 会被缓存在mcentral 中,而不是立刻释放并归还给OS
优化实例(Balanced GC)
编译器优化
基本介绍
编译器结构
- 重要的系统软件
- 识别符合语法和非法的程序
- 生成正确且高效的代码
- 分析部分(前端 frontend)
- 词法分析,生成词素 (lexeme)
- 语法分析,生成语法树
- 语义分析,收集类型信息,进行语义检查
- 中间代码生成,生成 intermediate representation (R)
- 综合部分(后端 backend)
- 代码优化,机器无关优化,生成优化后的 IR
- 代码生成,生成目标代码
静态分析
- 静态分析:不执行程序代码,推导程序的行为,分析程序的性质。
- 控制流 (Control flow):程序执行的流程
- 数据流 (Data flow):数据在控制流上的传递
- 通过分析控制流和数据流,我们可以知道更多关于 程序的性质 (properties)
- 根据这些性质优化代码
过程内和过程间分析
- 过程内分析 (ntra-procedural analysis)
- 仅在函数内部进行分析
- 过程间分析 (Inter-procedural analysis)
- 考虑过程调用时参数传递和返回值的数据流和控制流
- 为什么过程间分析是个问题?
- 需要通过数据流分析得知i的具体类型,才能知道i.foo()调用的是哪个foo()
- 根据i的具体类型,产生了新的控制流,A.foo(),分析继续
- 过程间分析需要同时分析控制流和数据流一一联合求解,比较复杂 对于代码:
type I interface {
foo()
}
type A struct {
}
type B struct {
}
func (a *A) foo() {
}
func (b *B) foo() {
}
func bar() {
i := &A{}
i.foo()
}
GO编译器优化
- 为什么做编译器优化
- 用户无感知,重新编译即可获得性能收益
- 通用性优化
- 现状
- 采用的优化少
- 编译时间较短,没有进行较复杂的代码分析和优化
- 编译优化的思路
- 场景:面向后端长期执行任务
- Tradeoff: 用编译时间换取更高效的机器码
- Beast mode
- 函数内联
- 逃逸分析
- 默认栈大小调整
- 边界检查消除
- 循环展开
函数内联(inlining)
- 内联:将被调用西数的函数体 (callee)的副本替换到调用位置(caller)上,同时重写代码以反映参数的绑定
- 优点
- 消除函数调用开销,例如传递参数、保存奇存器等
- 将过程间分析转化为过程内分析,帮助其他优化,例如逃逸分析
- 缺点
- 函数体变大,instruction cache (icache) 不友好
- 编译生成的 Go 镜像变大
逃逸分析
- 逃逸分析:分析代码中指针的动态作用域:指针在何处可以被访问
- 大致思路
- 从对象分配处出发,沿着控制流,观察对象的数据流
- 若发现指针p在当前作用域S:
- 作为参数传递给其他函数
- 传递给全局变量
- 传递给其他的 goroutine
- 传递给已逃逸的指针指向的对象
- 则指针p指向的对象逃逸出S,反之则没有逃逸出S