Go语言发行版优化 | 青训营笔记

57 阅读7分钟

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

只不过是字节给我的任务罢了

Go语言发行版优化

  • 优化

    • 内存管理优化
    • 编译器优化
  • 背景

    • 自动内存管理和Go内存管理机制
    • 编译器优化基本问题和思路
  • 字节跳动优化方案

性能优化的原因

性能优化是提升软件系统处理能力,减少不必要的消耗,充分发掘计算机算力

  • 提升用户体验
  • 提高资源利用率,降低成本,提高效率

性能优化的层面

  • 业务层优化:针对特定场景,容易获得较大收益
  • 语言运行时优化:解决更通用的性能问题,考虑更多场景
  • 数据驱动:使用pprof快速定位性能问题

性能优化与软件质量

  • 优化时,要在保证接口稳定的情况下改进
  • 测试用例,覆盖尽可能多的场景,方便回归
  • 文档:做了什么,没做什么,能达到的效果
  • 隔离:使用选项控制是否开启优化
  • 可观测:必要的日志输出

自动内存管理

自动内存管理,管理的是动态内存

  • 动态内存:程序运行时根据需求动态分配的内存malloc()

  • 自动内存管理:由程序语言运行时系统管理动态内存

    • 避免手动内存管理,专注于业务逻辑的实现
    • 保证内存使用的正确性和安全性
  • GC的三个任务

    • 为新对象分配空间
    • 找到存活对象
    • 回收死亡对象的内存空间

相关概念

  • Mutator:业务线程,分配新对象,修改对象指向关系
  • Collector:GC线程,找到存活对象,回收死亡对象的内存空间

GC算法

  • Serial GC:只有一个collector,会暂停mutator去执行collector

  • Parallel GC:支持多个collectors同时回收的GC算法,暂停mutator,去执行多个Collector

  • Concurrent GC:mutator(s)和collector(s) 同时执行,需要GC时,休眠n个mutator执行n个collector

    • collectors必须感知对象指向关系的改变,已标记对象指向的对象必须被标记

评价GC算法

  • 安全性(Safety):不能回收存活对象,这是基本要求
  • 吞吐率(Throughput):1 - ( GC时间 / 程序总执行时间 )
  • 暂停时间(Pause time):stop the world (STW) 业务是否感知
  • 内存开销(Space overhead) GC元数据开销

常见GC技术

追踪垃圾回收(Tracing garbage collection)
  • 对象回收的条件:指针指向关系不可达的对象

  • 标记根对象(静态变量、全局变量、常量、线性栈等)

  • 标记:找到可达对象

    • 求指针指向关系的传递闭包:从根对象出发,找到所有可达对象
  • 清理:所有不可达对象

    • 将存活对象复制到另外的内存空间(Copying GC)
    • 将死亡对象的内存标记为可分配(Mark-sweep GC)
    • 移动并整理存活对象(Mark-compact GC),原地整理对象(压缩)

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

  • 分代GC(Generational GC)

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

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

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

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

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

    • 年轻代(Young generation)

      • 常规的对象分配
      • 由于存活的对象少,可以使用Copying collection
      • GC吞吐率高
    • 老年代(Old generation)

      • 对象倾向于一直存活,反复复制开销会很大
      • 可以采用Mark-sweep collection
引用计数(Reference counting)
  • 每个对象都有一个关联的引用数目

  • 对象存活的条件:引用数 > 0

  • 优点

    • 内存管理的操作被平摊到程序执行过程中
    • 内存管理不需要了解runtime的实现细节(类似于C++的智能指针)
  • 缺点

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

Go内存分配-分块

  • 目标:为对象在heap上分配内存

  • 需要提前将内存分块

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

Go内存分配-缓存

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

img

Go内存管理优化

  • 对象分配是非常高频的操作:每秒分配GB级别的内存

  • 小对象的分配操作占比较高

  • Go内存分配比较耗时

    • 分配路径长: g -> m -> p -> mcache -> mspan -> memory block -> return pointer
    • pprof:对象分配的函数是最频繁调用的函数之一

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

  • 每个g都绑定一大块内存(1 KB),称作goroutine allocation buffer (GAB)

  • GAB用于noscan类型的小对象分配:< 128 B

  • 使用三个指针维护GAB: base, end, top

  • Bump pointer (指针碰撞)风格对象分配

    • 无须和其他分配请求互斥

    • 分配动作简单高效

       if top + size <= end {
           addr := top
           top += size
           return addr
       }
      
  • GAB对于Go内存管理来说是一个大对象

  • 本质:将多个小对象的分配合并成一次大对象的分配

  • 问题:GAB的对象分配方式会导致内存被延迟释放(GAB中仅有一个小对象也代表这个GAB存活)

  • 方案:移动GAB中存活的对象

    • 当GAB总大小超过一定阈值时,将GAB中存活的对象复制到另外分配的GAB中
    • 原先的GAB可以释放,避免内存泄漏
    • 本质:用copying GC的算法管理小对象

编译器和静态分析

编译器的结构

  • 重要的系统软件

    • 识别符合语法和非法的程序
    • 生成正确且高效的代码
  • 分析部分(前端front end)

    • 词法分析,生成词素(lexeme)
    • 语法分析,生成语法树
    • 语议分析,收集类型信息,进行语义检查
    • 中间代码生成,生成intermediate representation (IR)
  • 综合部分(后端back end)

    • 代码优化,机器无关优化,生成优化后的 IR
    • 代码生成,生成目标代码

image-20230119123807472.png

静态分析

  • 静态分析:不执行程序代码,推导程序的行为,分析程序的性质。

  • 控制流(Control flow):程序执行的流程

  • 数据流(Data flow):数据在控制流上的传递

     int a = 30;
     int b = 9 - (a/5);
     int c;
     c = b * 4;
     if (c > 10) {
         c = c - 10;
     }
     return c * (60/a);
    

    img

  • 根据分析数据流和控制流优化上面的代码

     int a = 30;
     int b = 9 - (a/5);
     int c;
     c = 12;
     if (ture) {
         c = 2;
     }
     return c * 2
    
  • 过程内分析(Intra-procedural analysis): 函数内分析:在函数内部进行分析

  • 过程间分析(Inter-procedural analysis): 函数间分析:考虑过程调用时参数传递和返回值的数据流和控制流

  • 只有通过数据流分析才可得知过程调用时的对象的类型和被调用的函数,再根据对象的类型,产生了新的控制流

  • 过程间分析需要同时分析数据流和控制流——联合求解,比较复杂

编译器优化

  • 编译优化的思路

    • 场景:面向后端长期执行任务
    • Tradeoff:用编译时间换取更高效的机器码
  • Beast mode

    • 函数内联
    • 逃逸分析

函数内联(Inline)

  • 内联:将被调用函数的函数体(callee)的副本替换到调用位置(caller).上,同时重写代码以反映参数的绑定

  • 优点

    • 消除函数调用开销,例如传递参数、保存寄存器等
    • 将过程间分析转化为过程内分析,帮助其他优化,例如逃逸分析
  • 缺点

    • 函数体变大,CPU指令缓存instruction cache (icache) 不友好
    • 编译生成的Go镜像变大
  • 大多数情况下,函数内联是正向优化

  • 内联策略

    • 调用和被调函数的规模
  • 函数内联能多大程度影响性能? —使用micro-benchmark验证一下

Beast Mode

  • Go函数内联受到的限制较多

    • 语言特性,例如interface, defer等,限制了函数内联
    • 内联策略非常保守
  • Beast mode:调整函数内联的策略,使更多函数被内联

    • 降低函数调用的开销
    • 增加了其他优化的机会:逃逸分析
  • 开销

    • Go镜像增加 ~10%
    • 编译时间增加

逃逸分析

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

  • 大致思路

    • 从对象分配处出发,沿着控制流,观察对象的数据流

    • 若发现指针p在当前作用域s:

      • 作为参数传递给其他函数
      • 传递给全局变量
      • 传递给其他的goroutine
      • 传递给已逃逸的指针指向的对象
  • 则指针p指向的对象逃逸出s,反之则没有逃逸出s

  • Beast mode:函数内联拓展了函数边界,更多对象不逃逸

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

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

参考

juejin.cn/post/718952…