这是我参与「第三届青训营 -后端场」笔记创作活动的的第3篇笔记
前言
性能优化两个基本问题
性能优化是什么？
提升软件系统处理能力，减少不必要的损耗，充分发掘计算机算力
为什么要做性能优化？
- 用户体验：带来用户体验的提升
- 资源高效利用：降低成本，提高效率。很小的优化乘以海量机器会是显著的性能提升和成本节约
性能优化的层面
业务层优化
- 针对特定场景，具体问题，具体分析
- 容易获得较大性能收益
语言运行时优化
- 解决更通用的性能问题
- 考虑更多场景
- Tradeoffs
数据驱动
- 自动化性能分析工具--pprof
- 依靠数据而非猜测
- 首先优化最大瓶颈
1 自动内存管理
1.1 相关概念
- 动态内存：程序在运行时根据需求动态分配内存：c语言的malloc()
- 自动内存管理（垃圾回收）：由程序语言的运行时系统回收动态内存
避免手动内存管理，专注于实现业务逻辑
保证内存使用的正确性和安全性 - 三个任务：为新对象分配空间；找到存活对象；回收死亡对象的内存空间
- Mutator：业务线程，分配新对象，修改对象指向关系
- Collector：GC线程，找到存活对象，回收死亡对象的内存空间
- Serial GC：只有一个collector
- Parallel GC：支持多个collectos同时回收的GC算法
- Concurrent GC：并行GC，mutator和collector可以同时执行
- 评价GC算法
- 安全性(Safety):不能回收存活的对象，基本要求
- 吞吐率(Throuhput):1-GC时间/程序执行总时间，花在GC上的时间
- 暂停时间(Pause time):STW stop the world，业务是否感知
- 内存开销(Space overhead):GC元数据开销
1.2 追踪垃圾回收
- 对象回收条件：指针指向关系不可达的对象
- 标记根对象GC Root
静态对象、全局变量、常量、线程等
3. 标记可达对象 从根对象出发，找到所有可达对象
4. 清理所有不可达对象
- Copying GC：将存活对象复制到另外的内存空间
- Mark-sweep GC：将死亡对象的内存标记为可分配
- Mark-compact GC：移动并整理存活对象
要根据对象的生命周期，选择不同的标记和清除策略
1.3 分代GC(Generation GC)
- 分代假说：most objects die young
- 很多对象在分配出来后很快就不再使用了
- 每个对象都有年龄：经过GC的次数
- 目的：针对年轻和老年的对象，制定不同的GC策略，降低整体内存管理的开销
- 不同对象处于内存中不同区域
年轻代
- 一般对象分配
- 由于存活对象少，可以采用Copying GC
- GC吞吐率高 老年代
- 对象存活时间长
- 可以采用Mark-sweep GC
1.4 引用计数法
- 每个对象都有一个与之关联的引用数目
- 对象存活的条件：当且仅当引用数大于0
- 优点
- 内存管理的操作被平摊到程序执行过程中
- 内存管理不需要了解runtime的实现细节：c++智能指针
- 缺点
- 维护引用计数的开销较大：通过原子操作保证引用计数操作的原子性和可见性
- 无法回收环形数据结构，即循环引用
- 内存开销：每个对象都引入额外存储空间存储引用数目
- 回收内存时依然可能引发暂停
2 Go 内存管理及优化
2.1 go内存分配-分块
- 目标：为对象在heap上分配内存
- 提前将内存分块
- 调用系统调用mmap()向OS申请一大块内存，例如4MB
- 先将内存划分成大块，例如8KB，称作mspan
- 再将大块继续划分成特定大小的小块，用于对象分配
- noscan mspan：分配不包含指针的对象---GC不需要扫描
- scan mspan：分配包含指针的对象---GC需要扫描
- 对象分配：根据对象的大小，选择合适的块返回
2.2 go内存分配-缓存
- TCMalloc：thread caching
- 每个p包含一个mcache用于快速分配，用于为绑定于p上的g分配对象
- mcache管理一组mspan
- 当mcache中的mspan分配完毕，向mcentral申请带有未分配块的mcentral
- 当mspan中没有分配的对象，mspan会被缓存再mcentral中，而不是立刻释放并归还给OS
2.3 Go内存管理优化
- 对象分配是非常高频的操作：每秒分配GB级别的内存
- 小对象占比较高
- Go内存分配比较耗时
- 分配路径：g --> m --> p --> mcache --> mspan --> memory block --> return pointer
- 对象分配函数是最频繁调用的函数之一
2.4 字节优化方案：Balance GC
- 每个g绑定一大块内存（1KB），称作GAB（goroutine allocation buffer)
- GAB用于noscan类型的小对象分配<128B
- 使用三个指针维护GAB：base，end，top
- 指针碰撞(Bump pointer)实现对象分配
- 无需和其他分配请求互斥 ，分配动作简单高效
- GAB对于Go内存管理来说是一个对象
- 本质：将多个小对象分配合并成一次大对象的分配
- 问题：GAB的对象分配方式会导致内存被延迟释放，如果GAB中只有很少的存活对象，会导致内存的浪费
解决方案：移动GAB中存活的对象
- 当GAB总大小超过一定阈值时，将GAB中存活的对象复制到另外分配的GAB中
- 原先的GAB可以释放，避免内存泄漏
- 本质：用Copying GC算法管理小对象
3 编译器和静态分析
3.1 编译器结构
编译器是重要的系统软件，可以识别符合语法和非法的程序，生成正确且高效的代码
3.2 静态分析
- 静态分析不执行程序代码，而是推导程序的行为，分析程序的性质
- 控制流（Control flow）：程序的执行流程
- 数据流（Data flow）：数据再控制流上的传递
- 通过分析控制流和数据流，我么可以知道更多关于程序的性质，根据性质优化代码
3.3 过程内分析和过程间分析
- 过程内分析（Intra-procedural analysis）：仅在过程内部进行分析
- 过程间分析（Inter-procedural analysis）：考虑过程调用时参数传递和返回值的数据流和控制流
- 为什么过程间分析是个问题？分析下面代码
- 需要通过数据流分析得知i的具体类型，才能知道i.foo()调用的是哪个foo()函数
- 根据i的具体类型，产生了新的控制流
- 过程间分析需要同时分析控制流和数据流，联合求解，比较复杂
Go 编译器优化
为什么做编译器优化?
- 用户无感知，重新编译即可获得性能收益
- 通用性优化 编译器优化现状
- 采用的优化少
- 编译时间较短，没有进行较复杂的代码分析和优化 编译器优化思路
- 场景：面向后端长期执行任务
- Tradeoff：用编译时间换取更高效的机器码 Best Mode 函数内联； 逃逸分析； 默认栈大小调整； 边界检查消除； 循环开展；
4.1 内联inline
内联：将被调用的函数体(callee)的副本替换到调用位置(caller)，同时重写代码以反映参数的绑定 优点:
- 消除函数调用开销，例如传递参数、保存寄存器等
- 将过程间分析转化为过程内分析，增加了其他的优化机会，例如逃逸分析
- 提升性能
缺点：
- 函数体变大，instruction cache 不友好
- 编译生成的Go镜像变大
4.2 逃逸分析
- 逃逸分析：分析代码中指针的动态作用域，指针在何处可以被访问
- 大致思路：
- 从对象分配处出发，沿着控制流，观察对象的数据流
- 若发现指针p在当前作用域s:
- 作为参数传递给其他函数
- 传递给全局变量
- 传递给其他的goroutine
- 传递给已逃逸的指针指向的对象
- 则指针p指向的对象逃逸出s,反之则没有逃逸出s
- Beast mode:函数内联拓展了函数边界，更多对象不逃逸
- 优化：未逃逸的对象可以在栈上分配
- 对象在栈上分配和回收很快：移动sp
- 减少在heap上的分配，降低GC负担
标题：「高性能 Go 语言发行版优化与落地实践」第三届字节跳动青训营 - 后端专场
