Go内存管理 性能优化 编译器优化｜青训营笔记

Illusionary
103 阅读5分钟

这是我参与「第五届青训营 」笔记创作活动的第1天

性能优化

  • 减少不必要的损耗，充分发掘计算机算力
  • 提升用户体验
  • 降低成本，提高效率

性能优化的层面

  • 业务代码
    • 业务层优化，针对特定场景、具体问题，具体分析
    • 容易获得较大性能收益
  • SDK
  • 基础库
  • 语言运行时
    • 语言运行时优化，解决更通用的性能问题
    • 考虑更多场景
    • Tradeoffs:需要结合数据权衡收益和代价，即权衡优化是否真的带来提升
  • OS
    • 数据驱动:自动化性能分析工具pprof
    • 依靠数据而非猜测
    • 首先优化最大瓶颈
  • 性能优化与软件质量 在保证接口稳定的前提下改进具体实现，测试用例尽可能覆盖多的场景，方便回归，写文档做了什么没做什么，能达到什么效果，通过选项控制是否开启优化，要有必要的日志输出。

1.自动内存管理

1.1自动内存管理

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

Mutator:业务线程，分配新对象，修改对象指向关系 Collector:GC线程，找到存活对象，回收死亡对象的内存空间 Serial GC:只有一个collector Parallel GC:支持多个collectors同时回收的GC算法 Concurrent GC:mutator(s)和collector(s)可以同时执行 Collectors必须感知对象指向关系的改变 concurrently:PG并发创建索引（CONCURRENTLY）

image.png

GC过程 image.png 必须标记，否则会认为是死亡对象

  • 评价GC算法
    • 安全性(Safety) 不能回收存活对象 --基本要求
    • 吞吐率(Throughput) 1-(GC时间/程序执行总时间) --花在GC上的时间
    • 暂停时间(Pause time) stop the world(STW) 业务是否感知
    • 内存开销(Space overhead) GC元数据开销
  • 追踪垃圾回收(Tracing garbage collection)
  • 引用计数(Reference counting)

1.2追踪垃圾回收

  • 对象被回收的条件:指针指向关系不可达的对象
  • 标记根对象
    • 静态变量、全局变量、常量、线程栈等
  • 标记 找到可达对象
  • 清理 所有不可达对象
    • 将存活对象复制到另外的内存空间(Copying GC)
    • 将死亡对象的内存标记为“可分配”(Mark-sweep GC)
    • 移动并整理存活对象(Mark-compact GC)

根据对象的生命周期，使用不同的标记和清理策略

image.png 图像分为三个区域 找到所有存活之后即完成标记

1.3分代GC(Generational GC)

  • 分代假说(Generational hypothesis):most objects die young

  • Intuition:很多对象在分配出来后很快就不再使用了

  • 每个对象都有年龄:经历过GC的次数

  • 目的:对年轻和老年的对象，制定不同的GC策略，降低整体内存管理的开销

  • 不同年龄的对象处于不同的heap

  • 年轻代(Young generation)

    • 常规的对象分配
    • 由于存活对象很少，可以采用copying collection
    • GC吞吐率很高

  • 老年代(Old generation)

    • 对象趋向于一只活着，反复复制开销较大
    • 可以采用mark- sweep collection

1.4 引用计数

  • 每个对象都有一个与之关联的引用数目
  • 对象存活的条件:当且仅当引用数大于0

image.png

  • 优点

    • 内存管理的操作被平摊到程序执行过程中

    • 内存管理不需要了解runtime的实现细节:C++智能指针(smart pointer)

image.png

image.png

image.png

  • 缺点
    • 维护引用计数的开销较大:通过原子操作保证对引用计数操作的原子性和可见性
    • 无法回收环形数据结构———weak reference
    • 内存开销:每个对象都引入的额外内存空间存储引用数目
    • 回收内存时依然可能引发暂停

image.png

2.Go内存管理及优化

2.1Go内存分配 - 分块

  • 目标:为对象在heap上分配内存
  • 提前将内存分块
    • 调用系统调用mmap()向OS申请一大块内存，如4MB
    • 先将内存划分成大块，例如8KB，称作mspan
    • 再将大块继续划分成特定大小的小块，用于对象分配
    • noscan mspan:分配不包含指针的对象 ——— GC不需要扫描
    • scan mspan:分配包含指针的对象 ——— GC需要扫描
  • 对象分配:根据对象的大小，选择最合适的块返回

image.png

2.1Go内存分配 - 缓存

  • TCMalloc:thread caching
  • 每个p包含一个mcache用于快速分配，用于为绑定于p伤的g分配对象
  • mcache管理一组mspan
  • 当mcache中的mspan分配完毕，向mcentral申请带有未分配块的mspan
  • 当mspan中没有分配的对象，mspan会被缓存在mcentral中，而不是立刻释放并归还给OS image.png

2.2Go内存管理优化

  • 对象分配 高频 每秒分配GB级别内存
  • 小对象占比高
  • GO内存分配比较耗时
    • 分配路径长 g-> m -> pmcache -> mspan ->memory block ->return pointer
    • pprof:对象分配的函数时最频繁调用的函数之一

2.3我们的优化方案:Balanced GC

  • 每个g都绑定一大块内存(1KB)，称作goroutine allocation buffer(GAB)
  • GAB 用于noscan类型的小对象分配:<128B
  • 使用三个指针维护GAB:base，end，top
  • Bump pointer(指针碰撞)风格对象分配
    • 无须和其他分配请求互斥
    • 分配动作简单高效

image.png

image.png

  • GAB对于Go内存管理来说是一个大对象
  • 本质:将多个小对象的分配合并成一次大对象的分配
  • 问题:GAB的对象分配方式会导致内存被延迟释放
  • 方案:移动GAB中存活的对象
    • 当GAB总大小超过一定阈值时，将GAB中存活的对象复制到另外分配的GAB中
    • 原先的GAB可以释放，避免内存泄漏
    • 本质:用copying GC的算法管理小对象 根据对象的生命周期，使用不同的标记和清理策略

image.png

image.png

image.png

2.3Balanced GC —— 性能收益

cpu usage降低，核心接口时延下降

3.编译器和静态分析

3.1编译器的结构

  • 重要的系统软件
    • 识别符合语法和非法的程序
    • 生产正确高效代码
  • 分析部分(前端 front end)
    • 词法分析，生成词素
    • 语法分析，生成语法树
    • 语义分析，收集类型信息，语义检查
    • 生成intermediate representation(IR)
  • 综合部分(后端 back end)
    • 代码优化，机器无关优化，生成优化后的IR
    • 代码生成，生成目标代码

image.png

3.2静态分析

  • 不执行代码 推导程序行为
  • 控制流(Control flow):程序执行的流程
  • 数据流(Data flow):数据在控制流上的传递

image.png

image.png

  • 分析控制流和数据流，了解程序性质，由此优化代码

3.3过程内分析和过程间分析

  • 过程内分析
  • 过程间分析
  • 分析数据流得知调用情况，产生情况

image.png

4.Go编译器优化

  • 用户无需感知，重新编译即可获得性能优化
  • 通用性优化
  • 面向后端长期执行任务
  • Tradeoff 用编译时间换取更高效机器码
  • Beast mode
    • 函数内联
    • 逃逸分析

4.1函数内联

  • 内联:将被调用函数的函数体(callee)的副本替换到调用位置(caller)上，同时重写代码以反映参数的绑定
  • 优点
    • 消除函数调用开销 传递参数 保持寄存器
    • 将过程间分析转化为过程内分析，帮助其他优化 逃逸分析
  • micro- benchmark验证
	x := genInteger()
	y := genInteger()
	for i := 0; i < b.N; i++ {
		addInline(x, y)
	}
}

func addInline(a, b int) int {
	return a + b
}

func BenchmarkInline(b *testing.B) {
	x := genInteger()
	y := genInteger()
	for i := 0; i < b.N; i++ {
		addInline(x, y)
	}
}

func addInline(a, b int) int {
	return a + b
}
  • 缺点
    • 函数体变大，instruction cache(icache)不友好
    • 编译生成的Go镜像变大
  • 函数内联大多正向优化
  • 内联策略

4.2Beast Mode

  • 限制多
    • 语言特性，如interface，defer等
    • 内联策略保守
  • Beast mode 调整函数内联策略，使更多函数被内联
    • 降低函数调用开销
    • 增加其他优化机会 逃逸分析
  • 开销
    • 镜像增加
    • 编译时间增加

4.2逃逸分析

  • 分析代码中指针的动态作用域 指针在何处可被访问

  • 思路：从分配对象出发看控制流和数据流->若发现指针p在当前作用域s

    • 作为参数传递给其他函数
    • 传递给全局变量
    • 传递给其他的goroutine
    • 传递给已逃逸的指针指向的对象

  • 则指针p指向的对象逃逸出s，反之则没逃逸出s

  • Beast mode 函数内联扩展了函数边界，更多对象不逃逸

  • 优化 未逃逸的对象可以在栈上分配

    • 对象中栈上分配和回收很快:移动sp
    • 减少在heap伤的分配，降低GC负担

总结

课程进行了比较详细的介绍，个人还需多练代码，熟悉项目。

avatar
文章
阅读
粉丝