这是我参与「第五届青训营 」伴学笔记创作活动的第 5 天
性能优化
-
宗旨:提升软件系统处理能力,减少不必要的消耗,充分发掘计算机算力
-
为什么要做性能优化?
- 用户体验:带来用户体验的提升 —— 让刷抖音更丝滑,让双十一购物不再卡顿
- 资源高效利用:降低成本,提高效率 —— 很小的优化乘以海量机器会是显著的性能提升和成本节约
-
性能优化层面
-
业务层优化
- 针对特定场景,具体问题,具体分析
- 容易获得较大性能收益
-
语言运行时优化——涉及全公司,需要考虑通用与全面
- 解决更通用的性能问题
- 考虑更多场景
- Tradeoffs
-
数据驱动(与文章04性能优化 | 青训营笔记类似)
性能调优原则
- 要依据数据而不是猜测
- 要定位最大瓶颈而不是细枝末节
- 不要过早优化
- 不要过度优化
- 自动化性能分析工具 —— pprof,可见07性能优化分析工具
- 依靠数据而非猜测
- 首先优化最大瓶颈
-
软件质量
-
尽量保证接口稳定的前提下改进实现
-
-
用更多更全面的测试用例来测试,用测试来驱动开发
-
通过清晰的文档告诉用户这一项优化做了什么,没做什么,能达到怎样的效果,方便用户针对场景来开启优化
-
隔离,优化代码用选项和原先的路径隔离,保证优化未启用时的行为同以前一致——保证产品的稳定性
-
可观测、可灰度、可回滚——对必要的日志、统计数据等进行输出,保证可观测性。
自动内存管理
基本概念
-
自动内存管理:由程序语言的运行时系统管理动态内存,例如
malloc -
避免手动内存管理,专注于实现业务逻辑
-
自动内存管理需要保证内存使用的正确性和安全性
-
三个任务
- 为新对象分配空间
- 找到存活对象——之后还会使用到的对象
- 回收死亡对象的内存空间
-
一些基础概念
-
Mutator: 业务线程,分配新对象,修改对象指向关系
-
Collector: GC 线程,找到存活对象,回收死亡对象的内存空间
-
Serial GC: 只有一个 collector,会有暂停
-
Parallel GC: 并行 GC,支持多个 collectors 同时回收的 GC 算法,同样有暂停,性能比serial GC高一些
-
Concurrent GC: 并发 GC,支持 mutator(s) 和 collector(s) 同时执行的 GC 算法
Collectors 必须感知对象指向关系的改变!
-
追踪垃圾回收
-
Tracing garbage collection: 追踪垃圾回收
-
被回收的条件:不可达对象
-
过程
-
标记根对象 (GC roots): 静态变量、全局变量、常量、线程栈等
-
标记:找到所有可达对象
-
清理:回收所有不可达对象占据的内存空间
- Copying GC: 将存活对象从一块内存空间复制到另外一块内存空间,原先的空间可以直接进行对象分配
- Mark-sweep GC: 将死亡对象所在内存块标记为可分配,使用 free list 管理可分配的空间
- Mark-compact GC: 将存活对象复制到同一块内存区域的开头
- Copying GC: 将存活对象从一块内存空间复制到另外一块内存空间,原先的空间可以直接进行对象分配
-
-
引用计数
-
每个对象都有一个与之关联的引用数目
-
对象存活的条件:当且仅当引用数大于 0
-
优点
- 内存管理的操作被平摊到程序运行中:指针传递的过程中进行引用计数的增减
- 不需要了解 runtime 的细节:因为不需要标记 GC roots,因此不需要知道哪里是全局变量、线程栈等
-
缺点
- 开销大,因为对象可能会被多线程访问,对引用计数的修改需要原子操作保证原子性和可见性
- 无法回收环形数据结构
- 每个对象都引入额外存储空间存储引用计数
- 虽然引用计数的操作被平摊到程序运行过程中,但是回收大的数据结构依然可能引发暂停