ppt链接： 高性能 Go 语言发行版优化与落地实践.pptx - 飞书文档 (feishu.cn)
自动内存管理（GC 垃圾回收）
管理的是动态内存（程序在运行时根据需要动态分配的内存） 自动内存管理由程序语言的运行时系统管理动态内存
避免手动内存管理，专注于实现业务逻辑
保证内存使用的正确性和安全性：double-free problem,use-after-free problem（重复释放内存、释放了之后又使用内存） 三个任务
为新对象分配空间
找到存活对象
回收死亡对象的内存空间
相关概念
Mutator：业务线程，分配新对象，修改对象指向关系
Collector：GC线程，找到存活对象，回收死亡对象的内存空间
Serial GC：只有一个collector
Parallel GC：支持多个collectors同时回收的GC算法
Concurrent GC：mutator(s)和collector(s)可以同时执行
Concurrent GC：垃圾回收时不会暂停Mutator 困难在于：
Collectors必须感知对象指向关系的改变
左边第一张图代表一个线程的执行对象 由o创建了一个基于他的对象a，GC过程当中用户进程Mutator也在执行，Collector将o a标记为存活对象。标记时进程又创建了一个对象b这时候b是没有被标记的对象。理应被标记所以collector GC必须要感知Mutator对象指向关系的改变
评价GC算法
追踪垃圾回收
对象被回收的条件：指针指向关系不可达的对象
标记根对象
静态变量、全局变量、常量、线程栈等
标记：找到可达对象
求指针指向关系的传递闭包：从根对象除法，找到所有可达对象
清理：所有不可达对象
将存活对象复制到另外的内存空间（Copying GC）
将死亡对象的内存标记为"可分配"（Mark-sweep GC）
移动并整理存活对象（Mark-compact GC） 根据对象的生命周期，使用不同的标记和清理策略
分代GC（Generational GC）
分代假说(Generational hypothesis):most objects die young
intuition:很多对象在分配出来后很快就不再使用了
每个对象都有年龄：经历过GC的次数
目的：对年轻和老年的对象，制定不同的GC策略，降低整体内存管理的开销
不同年龄的对象处于heap的不同区域
年轻代(Young generation)
常规的对象分配
由于存活对象很少，可以采用coping collection
GC 吞吐率很高
老年代（Old generation）
对象趋向于一直活着，反复复制开销较大
可以采用mark-sweep collection
引用计数
p=0，分配一个空间存放0并将它指向p，该空间被引用的次数变为1 q=p，q也指向这个空间，该空间的引用计数为2 q=null q指向空，该空间被引用的次数-1
每个对象都有一个与之关联的引用计数
对象存活的条件：当且仅当引用数大于0
优点
内存管理的擦欧总被平摊导程序执行过程中
内存管理不需要了解runtime的所实现细节：C++智能指针（smart pointer）
缺点
维护引用计数的开销较大：通过原子操作保证对引用计数操作的原子性和可见性
无法回收环形数据结构-（weak reference 用来解决）
>红色部分不可达，但是引用计数都为1不能被回收- 内存开销：每个对象都引入一个额外的内存空间存储引用计数- 回收内存时依然可能引发暂停>回收大型数据结构也有可能触发暂停
Go内存管理及优化
Go内存分配-分块
目标：为对象在heap上分配内存
提前将内存分块
调用系统调用mmap（）想OS申请一大块内存，例如4MB
先将内存划分成大块，例如8KB，称作mspan
再将大块继续划分成特定大小的小块，用于对象分配
noscan mspan：分配不包含指针的对象——GC不需要扫描
scan mspan：分配包含指针的对象——GC需要扫描 GC的扫描：当对象包含指针的时候，对象包含的指针所指向的对象也需要找到进行标记
对象分配：根据对象的大小，选择最合适的块返回
Go内存分配-缓存
TCMalloc：thread caching
每个p包含一个mcache用于快速分配，用于为绑定于p上的g分配对象
mcache管理一组mspan
当mcache中的mspan分配完毕，向mcentral申请带有未分配块的mspan
当mspan中没有分配的对象，mspan会被缓存在mcentral中，而不是立刻释放并归还给OS
详细请参考GO内存管理：内存组件之mspan、mcache、mcentral 和 mheap 数据结构
Go内存管理优化
对象分配是非常高频的操作：每秒分配GB级别的内存
小对象占比较高
Go内存分配比较耗时
分配路径长：g——>m——>p——>mcache——>mspan——>memory block——>return pointer
pprof：对象分配的函数是调用最频繁的函数之一
字节的优化策略 GAB（针对小对象）
每个g都绑定一大块内存（1KB），称作goroutine allocation buffer(GAB)
GAB用于noscan类型的小对象分配：<128B noscan:没有指针的对象
使用三个指针维护GAB：base，end，top
Bump pointer（指针碰撞）风格对象分配
无需和其他分配请求互斥
分配动作简单高效
缺点与改进
编译器和静态分析
编译器的结构
重要的系统软件
识别符合语法和非法的程序
生成正确且高效的代码
分析部分（前端 front end）
词法分析，生成词素（lexeme）
语法分析，生成语法树
语义分析，收集类型信息，进行语义检查
中间代码生成，生成intermediate representation（IR）
综合部份（后端 back end）
代码优化，机器无关优化，生成优化后的IR
代码生成，生成目标代码
静态分析
静态分析：不执行程序代码，推导程序的行为，分析程序的性质
控制流分析（Control flow）：程序执行的流程
数据流（Data flow）：数据在控制流上的传递 控制流分析
左边的程序转换为右边的control-flow graph：分析程序的流程 数据流分析 a=30这条数据自然就流到了第二条语句，发现第二条语句中有a，将数据带入，得到b=3这条数据 该数据又流到第三条语句，发现无a、b。按照编译的顺序来到第四条语句，发现其中有b将数据流b=3带入得到c=12 所以c>10一定成立，程序一定走if语句中的程序块 c=2,所以一定返回4 所以这个程序一定会返回4，在编译优化的时候对于这样一个函数我们就不会生成他的代码只会返回4即可
过程内分析和过程间分析
过程内分析（intra-procedural analysis）
仅在过程内部进行分析
过程间分析（Inter-procedural analysis）
考虑过程调用时参数传递和返回值的数据流和控制流 为什么过程间分析是个问题？
需要通过数据流分析得知i的具体类型，才能直到i.foo()调用的是哪个foo（）
根据i的具体类型，产生了新的控制流，A.foo(),分析继续
过程见分析需要同时分析控制流和数据流——联合求解，比较复杂
Go编译器优化
为什么做编译器优化
用户无感知，重新编译即可或的性能收益
通用性优化
现状
采用的优化少
编译时间较短，没有进行较复杂的代码分析和优化
编译优化的思路
场景：面向后端长期执行任务
Tradeoff：用编译时间换取更高效的机器码
Beast mode
函数内联
逃逸分析
默认栈大小调整
边界检查消除
循环展开
函数内敛（Inlining）
内联：将被调用函数的函数体（callee）的副本替换到调用位置（caller）上，同时重写代码以反映参数的绑定
优点
消除函数调用开销，例如传递参数、保存寄存器等
将过程见分析转化为过程内分析，帮助其他优化，例如 逃逸分析
缺点
函数体变大，instruction cache(icache)不友好
编译生成的Go镜像变大
函数内联在大多数情况下是正向优化
内联策略
调用和被调用函数的规模
Beast Mode
Go函数内联受到的限制较多
语言特性：例如interface，defer等，限制了函数内联
内联策略非常保守
Beast mode：调整函数内联的策略，使更多函数被内联
降低函数调用的开销
增加了其他优化的机会：逃逸分析
开销
Go镜像增加~10%
编译时间增加
逃逸分析
逃逸分析 分析代码中指针的动态作用域：指针在何处可以被访问
大致思路
作为参数传递给其他函数
传递给全局变量
传递给其他的goroutine
传递给已逃逸的指针指向的对象
从对象分配出发，沿着控制流，观察对象的数据流
若发现指针p在当前作用域s：
则指针p指向的对西安那个逃逸出s，反之则没有逃逸出s
Beast mode：函数内联拓展了函数边界，更多对象不逃逸
优化：未逃逸的对象可以在栈上分配
对象在栈上分配和回收很快：移动sp
减少在heap上的分配，降低GC负担
原文：https://juejin.cn/post/7100193088420724767