这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记

引言

什么是性能优化？
- 提升软件系统处理能力，减少不必要的消耗，充分发掘计算机算力
为什么要做性能优化？
- 用户体验：带来用户体验的提升 —— 让刷抖音更丝滑，让双十一购物不再卡顿
- 资源高效利用：降低成本，提高效率 —— 很小的优化乘以海量机器会是显著的性能提升和成本节约
性能优化
- 业务层优化
  - 针对特定场景，具体问题，具体分析（pprof）
  - 容易获得较大性能收益
- 语言运行时优化
  - 解决更通用的性能问题
  - 考虑更多场景
  - Tradeoffs
- 数据驱动
  - 自动化性能分析工具 —— pprof
  - 依靠数据而非猜测
  - 首先优化最大瓶颈
性能优化与软件质量
- 软件质量至关重要
- 保证接口稳定的前提下改进实现
- 测试驱动（用例）：覆盖尽可能多的场景，方便回归
- 通过清晰的文档告诉用户这一项优化做了什么，没做什么，能达到怎样的效果
- 隔离：优化代码用选项和原先的路径隔离，保证优化未启用时的行为同以前一致，通过选项控制是否开启优化
- 可观测：必要的日志输出，可灰度、可回滚
总结
- 性能优化的基本问题
- 性能优化的两个层面
- 性能优化的可维护性

自动内存管理

基本概念

动态内存：程序在运行时根据需求动态分配的内存：malloc()
自动内存管理（垃圾回收）：由程序语言的运行时系统管理动态内存
- 避免手动内存管理，专注于实现业务逻辑
- 保证内存使用的正确性和安全性: double-free problem, use-after-free problem
三个任务
- 为新对象分配空间
- 找到存活对象
- 回收死亡对象的内存空间

追踪垃圾回收

Tracing garbage collection: 追踪垃圾回收
- 对象被回收的条件：指针指向关系不可达对象
- 过程
  - Global Variables：全局变量
  - Stack：第一步将stack顶指向顶指针标记为黑色
  - Heap：对象的堆
  - 标记根对象 (GC roots): 静态变量、全局变量、常量、线程栈等
  - 标记：找到所有可达对象
  - 清理：回收所有不可达对象占据的内存空间，
    
    根据对象的生命周期，使用不同的标记和清理策略
    - Copying GC: 将存活对象从一块内存空间复制到另外一块内存空间，原先的空间可以直接进行对象分配
      - 刚开始在大区域，灰色为活着的对象，存活的对象复制到一个新的区域，然后大区域情况
    - Mark-sweep GC（标记清理GC）: 将死亡对象所在内存块标记为可分配，使用 freelist管理可分配的空间
      - freelist进行内存管理，分配的时候freelist里找可分配的内存块
    - Mark-compact GC（移动并整理对象）: 将存活对象复制到同一块内存区域的开头
    - 将存活对象复制内存区域开头，下一次内存分配从新开头开始，不是每次GC做压缩，有一定策略

分代GC

常见内存管理方式

分代假说(Generational hypothesis): most objects die young，大多数的对象很快就死去
Intuition（直觉）:很多对象在分配出来后很快就不再使用了
每个对象都有年龄:经历过GC的次数
目的:对年轻和老年的对象，放在不同的内存区域，制定不同的GC策略，降低整体内存管理的开销
不同年龄的对象处于heap的不同区域
Young Generation & Old Generation
- Young Generation
  - 常规的对象分配，（刚出来的时候）
  - 由于存活对象很少，可以采用copying collection
  - GC吞吐率很高
- Old Generation
  - 对象趋向于一直活着，反复复制开销较大
  - 可以采用Mark-sweep GC

引用计数

每个对象都有一个与之关联的引用数目
对象存活的条件：当且仅当引用数大于 0
优点
- 内存管理的操作被平摊到程序运行中：指针传递的过程中进行引用计数的增减
- 不需要了解 runtime 的细节：因为不需要标记 GC roots，因此不需要知道哪里是全局变量、线程栈等
缺点
- 开销大，因为对象可能会被多线程访问，对引用计数的修改需要原子操作保证原子性和可见性
- 无法回收环形数据结构———weak reference
- 每个对象都引入额外存储空间存储引用计数
- 虽然引用计数的操作被平摊到程序运行过程中，但是回收大的数据结构依然可能引发暂停
说明
- 以上我们所讲述的技术的缺点并非是无法解决的问题。学术界和工业界在一直在致力于解决自动内存管理技术的不足之处。例如，最新的 PLDI'22 的文章 Low-Latency, High-Throughput Garbage Collection 感兴趣的同学可以阅读。

Go 内存管理及优化

Go 内存管理

TCMalloc: TC is short for thread caching
目标：为对象在 heap 上分配内存
提前将内存分块
- 调用系统调用 mmap() 向 OS 申请一大块内存，例如 4 MB
- 先将内存划分成大块，例如 8 KB，称作 mspan,mapan中的每个块可以进行对象内存分配
- 再将大块继续划分成特定大小的小块，用于对象分配
- noscan mspan: 分配不包含指针的对象 —— GC 不需要扫描
- scan mspan: 分配包含指针的对象 —— GC 需要扫描，有指针的话要找指针所指的对象叫做扫描。
- 第一个思想
对象分配：根据对象的大小，选择最合适的块返回
内存分配——缓存
- 步骤
  - TCMalloc：thread caching
  - 每个p包含一个mcache用于快速分配，用于为绑定于p上的g分配对象
  - mcache管理一组mspan，每个大小不同
  - 当mcache中的 mspan分配完毕，向mcentral申请带有未分配块的mspan（mspan的大小最合适）
  - 当mspan中没有分配的对象，mspan会被缓存在mcentral中，而不是立刻释放并归还OS
- Go 内存管理构成了多级缓存机制，从 OS 分配得的内存被内存管理回收后，也不会立刻归还给 OS，而是在 Go runtime 内部先缓存起来，从而避免频繁向 OS 申请内存。内存分配的路线图如下。

Go 内存管理的问题

mspan, mcache 和 mcentral 构成了内存管理的多级缓存机制。

对象分配是非常高频的操作：每秒分配 GB 级别的内存
线上 profiling 发现，Go 的内存分配占用很多 CPU

可以看到，用于分配对象的函数 mallocgc() 占用 CPU 较高

小对象分配占大多数

横轴是对象大小，纵轴是数目，可以看到绝大多数对象都小于 80 B。因此优化小对象分配是关键。

Go内存分配比较耗时
- 分配路径长：g-m-p-mcache-mspan-memory block-return pointer
- pprof：对象分配的函数是最频繁调用的函数之一

字节跳动的优化方案-Balanced GC

核心概念

将 noscan 对象在 per-g allocation buffer (GAB) 上分配，并使用移动对象 GC 管理这部分内存，提高对象分配和回收效率

基本步骤

每个g都绑定一大块内存(1 KB)，称作 goroutine allocation buffer(GAB)
GAB用于noscan类型的小对象分配：<128B，即每个 g 会附加一个较大的 allocation buffer (例如 1 KB) 用来分配小于 128 B 的 noscan 小对象
使用三个指针维护GAB: base, end, top
Bump pointer(指针碰撞)风格对象分配。
- 代码示例
```
if g.ab.end - g.ab.top < size {
    // Allocate a new allocation buffer
}
addr := g.ab.top
g.ab.top += size
return addr
```
- 分配对象时，根据对象大小移动 top 指针并返回，快速完成一次对象分配
- 同原先调用 mallocgc() 进行对象分配的方式相比，balanced GC 缩短了对象分配的路径，减少了对象分配执行的指令数目，无须和其他分配请求互斥，降低 CPU 使用
- 分配动作简单高效

深入理解

GAB对于GO内存管理来说是一个大对象
本质：将多个小对象的分配合并成一次大对象的分配（所有noscan对象，小对象一起做指针碰撞）
问题：GAB的对象分配方式会导致内存被延迟释放（当 GAB 中哪怕只有一个小对象存活时，Go runtime 也会认为整个大对象（即 GAB）存活）
方案：移动GAB中存活的对象，

将 GAB 中存活的对象移动到另外的 GAB 中
- 当GAB总大小超过一定阈值时，将GAB中存活的对象复制到另外分配的GAB中
- 原先的 GAB 空间由于不再有存活对象，可以全部释放，避免内存泄漏
- 本质：用copying GC的算法管理小对象——根据对象的生命周期，使用不同的标记和清理策略

图像理解

下图上方是两个 GAB，其中虚线表示 GAB 中对象的分界线。黑色表示 GAB 中存活的对象，白色表示死掉的对象。由于 GAB 中有存活对象，整个 GAB 无法被回收。
Balanced GC 会将 GAB 中存活的对象移动到下面的 GAB 中，这样原先的两个 GABs 就可以被释放，压缩并清理 GAB 的内存空间。
Balanced GC 只负责 noscan 对象的分配和移动，对象的标记和回收依然依赖 Go GC 本身，并和 Go GC 保持兼容。

编译器和静态分析

编译器的结构

静态分析

静态分析：不执行代码，推导程序的行为，分析程序的性质。
控制流：程序的执行流程
数据流：数据在控制流上的传递
- 上图的程序转换成控制流图 (control-flow graph)
通过分析控制流和数据流，我们可以知道更多关于程序的性质(properties)
根据这些性质可以进行编译优化。
- 例如上面的程序。我们通过分析数据流和控制流，知道这个程序始终返回 4。编译器可以根据这个结果做出优化。

函数内分析：

Intra-procedural analysis：在函数内进行控制流和数据流的分析

函数间分析

Inter-procedural analysis: 除了函数内的分析，还需要考虑跨函数的数据流和控制流，例如参数传递，函数返回值等

Go 编译器优化

目的
- 用户无感知，重新编译即可获得性能收益
- 通用的优化手段
现状
- 采用的优化较少
- 追求编译时间短，因此没有进行复杂的代码分析和优化

编译优化的思路
- 场景：面向后端长期执行的任务
- Tradeoff：用适当增加编译时间换取更高性能的代码
Beast mode
- 函数内联
- 逃逸分析
- 默认栈大小调整
- 边界检查消除
- 循环展开
- ...

函数内联

定义：将被调用函数的函数体的副本替换到调用位置上，同时重写代码以反映参数的绑定
优点
- 消除调用开销（没有函数调用，直接替换）
- 将过程间分析的问题转换为过程内分析，帮助其他分析，例如逃逸分析
缺点
- 函数体变大，instruction cache（icache，CPU指令cache），不友好
- 编译生成的 Go 镜像文件变大，（相当于复制好多份）
函数内联在大多数情况下是正向优化，即多内联，会提升性能
内联策略
- 调用和被调用函数的规模
- ...

Beast Node

Go 内联的限制较多
- 语言特性：interface, defer 等等，限制了内联优化
- 内联策略非常保守
字节跳动的优化方案——Beast Node
- 修改了内联策略，让更多函数被内联
- 增加了其他优化的机会：逃逸分析
开销
- Go 镜像大小略有增加~10%
- 编译时间增加
- 运行时栈扩展开销增加

逃逸分析

定义：分析代码中指针的动态作用域，即指针在何处可以被访问
大致思路
- 从对象分配处出发，沿着控制流，观察数据流。
- 若发现指针 p 在当前作用域 s：
  - 作为参数传递给其他函数
  - 传递给全局变量
  - 传递给其他的 goroutine
  - 传递给已逃逸的指针指向的对象
- 则指针 p 逃逸出 s，反之则没有逃逸出 s.（即出不出这个作用域（函数））
Beast Node：函数内联扩展了函数边界，更多对象不逃逸
优化：未逃逸出当前函数的指针指向的对象可以在栈上分配
- 对象在栈上分配和回收很快：移动 sp 即可完成内存的分配和回收；
- 减少在堆上分配对象，降低 GC 负担。

课后

从业务层和语言运行时层进行优化分别有什么特点？
从软件工程的角度出发，为了保证语言 SDK 的可维护性和可拓展性，在进行运行时优化时需要注意什么？
自动内存管理技术从大类上分为哪两种，每一种技术的特点以及优缺点有哪些？
什么是分代假说？分代 GC 的初衷是为了解决什么样的问题？
Go 是如何管理和组织内存的？
为什么采用 bump-pointer 的方式分配内存会很快？
为什么我们需要在编译器优化中进行静态代码分析？
函数内联是什么，这项优化的优缺点是什么？
什么是逃逸分析？逃逸分析是如何提升代码性能的？

参考文献

The Garbage Collection Handbook – the art of automatic memory management 自动内存管理领域的集大成之作。把自动内存管理的问题、动机、方案、以及最新研究进展和方向进行了非常详尽的阐述。整个书很好读，参考文献非常充实，推荐阅读英文版。
JEP 333: ZGC: A Scalable Low-Latency Garbage Collector openjdk.java.net/jeps/333 目前 HotSpot JVM 上 pauseless GC 实现的 proposal，可以看作 GC 领域比较新的工程方面的进展。
数据密集型应用系统设计 Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems 通过例子带大家理解互联网产品需要解决的问题以及方案。
编译原理 The Dragon book, Compilers: Principles, Techniques, and Tools 在编译器前端着墨较多。本书第二版的第九章机器无关优化，推荐大家反复仔细阅读。这一章主要讲述的是编译优化中常见的数据流分析问题，建议大家跟随书本仔细推导书中的例子，会帮助你对数据流分析有个大致的认识。这一章给出的引用文献大多是编译和静态分析领域非常有影响力的论文，有兴趣的同学可以阅读。
编译原理 Principles and Techniques of Compilers silverbullettt.bitbucket.io/courses/com… 南京大学编译原理课程。
静态程序分析 Static Program Analysis pascal-group.bitbucket.io/teaching.ht… 南京大学静态程序分析课程。参考文献 4 数据流分析读不懂的地方可以参考本课程的课件。
编译器设计 Engineering a Compiler 在编译器后端优化着墨较多。可以帮助大家理解后端优化的问题。
JVM Anatomy Quark #4: TLAB allocation shipilev.net/jvm/anatomy… Goroutine allocation buffer (GAB) 的优化思路在 HotSopt JVM 也能找到类似的实现。
Constant folding, en.wikipedia.org/wiki/Consta… 常量折叠数据流分析。
Choi, Jong-Deok, et al. “Escape analysis for Java.” Acm Sigplan Notices 34.10 (1999): 1-19. 逃逸分析的 Java 实现。
Zhao, Wenyu, Stephen M. Blackburn, and Kathryn S. McKinley. “Low-Latency, High-Throughput Garbage Collection.” (PLDI 2022).

学术界和工业界在一直在致力于解决自动内存管理技术的不足之处，感兴趣的同学可以阅读。

高性能 Go 语言发行版优化与落地实践｜青训营笔记

引言

自动内存管理

基本概念

相关概念

追踪垃圾回收

分代GC

引用计数

Go 内存管理及优化

Go 内存管理

Go 内存管理的问题

字节跳动的优化方案-Balanced GC

核心概念

基本步骤

深入理解

图像理解

编译器和静态分析

静态分析

函数内分析：

函数间分析

Go 编译器优化

函数内联

Beast Node

逃逸分析

课后

参考文献

高性能 Go 语言发行版优化与落地实践 ｜ 青训营笔记

引言

自动内存管理

基本概念

相关概念

追踪垃圾回收

分代GC

引用计数

Go 内存管理及优化

Go 内存管理

Go 内存管理的问题

字节跳动的优化方案-Balanced GC

核心概念

基本步骤

深入理解

图像理解

编译器和静态分析

静态分析

函数内分析：

函数间分析

Go 编译器优化

函数内联

Beast Node

逃逸分析

课后

参考文献

高性能 Go 语言发行版优化与落地实践｜青训营笔记