这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记
优化引入
性能优化是什么
- 提升软件系统处理能力，减少不必要的消耗
为什么要进行优化
- 用户体验
- 资源高效利用
性能优化的层面
- 业务代码
- SDK
- 基础库
- 语言运行时
- OS
从业务代码和语言运行时入手 通过数据驱动我们的优化
- 可以借助pprof
- 首先解决最大瓶颈
优化注意点
- 质量至关重要
- 测试用例要覆盖得广
- 文档要写明做了什么，没做什么，能达到什么效果
- 隔离：是否开启优化
- 可观性：必要的日志输出
01. 自动内存管理
三个任务
- 为新对象分配空间
- 找到存活对象
- 回收死亡对象内存空间
相关概念
- Mutator：业务线程，分配新对象，修改对象指向关系
- Collector：GC线程，找到存活对象，回收死亡对象的内存空间
- Serial GC：只有一个collector
- Parallel GC：支持多个collector
- Concurrent GC：mutator(s)和collector(s)可以同时运行
看图理解
评价GC算法
- 安全性：不回收存活对象是基本要求
- 吞吐率：1 - (GC时间/程序执行总时间)
- 暂停时间：业务是否感知
- 内存开销：GC元数据开销
追踪垃圾回收
回收条件：指针指向关系不可达对象
标记根对象
- 静态变量、全局变量、常量、线程栈
标记可达对象
- 从根对象出发，找到所有可达对象
清除不可达对象
将存活对象复制到另外的内存
将死亡对象内存标记为可分配
移动并整理存货对象
分代GC
每个对象都有年龄：经历GC的次数
目的：针对年轻和老年对象制定不同的GC策略，降低内存管理开销
年轻代
-
可以采用copying GC
- 因为存活对象少
老年代
引数计数
- 每个对象都有一个与之关联的引用数目
- 对象存活条件：当且仅当引用数大于0
优点
- 内存管理的操作被平摊到程序执行过程
- 内存管理不需要runtine实现细节：c++智能指针
缺点
-
维护引数的开销较大，因为需要原子操作保证引用计数的原子性和可见性，而原子操作开销较大
-
无法回收环形数据结构
-
内存开销：每个对象都引入了额外内存存储引用数目
-
回收内存依然可能引发暂停
- 如果牵连要释放的对象很多的化就会了
02 Go管理及优化
分块
向OS申请一大块内存，然后分块
目的
- 为对象在heap上分配内存
提前将内存分块
- 调用mmap()向OS申请一大块内存
- 先将内存划分为大块，例如：8KB称为mspan
- 再将大块分特定大小的小块用于对象分配
- noscan mspan：分配不包含指针对象，所以不需要GC扫描
- scan mspan分配包含指针的对象，需要GC扫描
缓存
每个p包含一个mchache用于快速分配，用于p上的g分配对象
mcache管理一组mspan
当mcache中的mspan分配完毕，向mcentral申请带有未分配的mspan
当mspan中没有分配对象，mspan会被缓存在mcentral中，而不是立刻释放并归还给OS
优化
根据堆内存图我们知道较大内存被分配的次数很少，分配次数很多的是小内存分配，而Go内存分配比较耗时 从g => m => p => mcache => mspan => memory block => return pointer
Balanced GC
做法：每一个g都绑定一大块内存(1KB)，简称GAB 用途：用于noscan类型的小对象分配：< 128 B 使用三个指针维护：base end top 指针碰撞风格对象分配
- 无须和其他分配请求互斥
- 分配动作简单高效
-
GAB对Go内存管理来说是一个对象
-
本质：将多个小对象的分配合并成一次达对象的分配
-
问题：GAB的对象分配方式会导致内存被延迟释放
-
方案：移动GAB中存活对象
-
当GAB总大小超过一定阈值时，将GAB中存活的对象复制到另外分配的GAB中
-
原先的GAB可以释放，这个释放交给GC就行了
-
本质：用copying GC算法管理小对象
-
03 编译器和静态分析
结构
静态分析
- 定义：不执行程序代码，推导程序的行为，分析程序的性质
控制流
- 程序执行的流程
数据流
- 数据流：数据在控制流上的传递
程序代码 控制流 数据流
过程内和过程间分析
过程内分析
- 仅在函数内部进行分析
过程间分析
- 考虑函数调用时参数传递和返回值的数据流和控制流
为什么过程间分析是个问题
- 需要通过数据流分析得知i的具体类型，才知道i.foo()调用的是哪个foo()
- 根据i的具体类型，产生了新的控制流，A.foo()，分析继续
- 过程间分析需要同时分析控制流和数据流=>联合求解，比较复杂
04 Go编译器优化
为什么做编译器优化
- 用户无感知，重新编译即可获得性能收益
- 通用性优化
现状
- 采用的优化少
- 编译时间较短，没有进行较复杂的代码分析和优化
编译优化思路
- 用编译时间换取更高效的机器码
Beast mode
- 函数内联
- 逃逸分析
函数内联
- 将被调用函数的函数体的副本替换到调用位置上，同时重写代码以反映参数的绑定
优点
- 消除函数调用开销
- 将过程间分析转化为过程内分析，帮助其他优化，例如逃逸分析
缺点
- 函数体变大，对icache不友好
- 编译生成Go镜像变大
Beast Mode
-
Go函数内联受到的限制较多
- 语言特性，例如interface,defer
- 内联策略非常保守
-
Beast Mode：调用函数内联的策略，使得更多函数被内联
- 降低函数调用的开销
- 增加了其他优化的机会：逃逸分析
-
开销
- Go镜像增加~10%
- 编译时间增加
逃逸分析
-
分析代码中指针的动态作用域，指针在何处被访问
-
大致思路
-
从对象分配处出发，沿着控制流，观察对象的数据流
-
若发现指针p在当前作用域s:
- 作为参数传递给其他函数
- 传递给全局变量
- 传递给其他的goroutinue
- 传递给已逃逸的指针指向的对象
-
则指针p指向的对象逃逸出s，反之则没有逃逸出s
-
-
Beast Mode：函数内联拓展了函数边界，更多对象不逃逸
-
优化：未逃逸对象可以在栈上分配
- 对象在栈上分配和回收很快：移动sp
- 减少在heap上的分配，降低GC负担
