【Go语言内存管理详解】自动内存管理-Go内存管理及优化 | 青训营笔记

Asan3
118 阅读8分钟

这是我参与「第五届青训营」伴学笔记创作活动的第 5 天，今天学习的内容是自动内存管理、Go内存管理及优化，整理学习笔记如下。

5.1 引言

  • 什么是性能优化？

    • 提升软件系统处理能力，减少不必要的消耗，充分发掘计算机算力

  • 为什么要做性能优化？

    • 用户体验：带来用户体验的提升 —— 让刷抖音更丝滑，让双十一购物不再卡顿
    • 资源高效利用：降低成本，提高效率 —— 很小的优化乘以海量机器会是显著的性能提升和成本节约

  • 性能优化的层面

    结构： 业务代码，SDK，基础库，语言运行时，OS

    • 业务层优化

      • 针对特定场景，具体问题，具体分析
      • 容易获得较大性能收益

    • 语言运行时优化

      • 解决更通用的性能问题
      • 考虑更多场景
      • Tradeoffs

    • 数据驱动

      • 自动化性能分析工具 —— pprof
      • 依靠数据而非猜测
      • 首先优化最大瓶颈

  • 性能优化与软件质量

    • 软件质量至关重要，保证接口稳定的前提下改进实现

    • 测试用例/测试驱动： 覆盖尽可能多的场景，方便回归

    • 文档： 通过清晰的文档告诉用户这一项优化做了什么，没做什么，能达到怎样的效果

    • 隔离： 优化代码用选项和原先的路径隔离，保证优化未启用时的行为同以前一致，通过选项控制是否开启优化

    • 可观测（必要的日志输出）、可灰度、可回滚

image.png

5.2 自动内存管理

5.2.1 基本概念

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

  • 自动内存管理（Garbage Collection 垃圾回收-GC）：由程序语言的运行时系统管理动态内存

    • 避免手动内存管理，专注于实现业务逻辑
    • 保证内存使用的正确性和安全性： double-free problem , use-after-free problem

  • 三个任务

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

  • 概念

    Mutator： 业务线程，分配新对象，修改对象指向关系

    Collector： GC 线程，找到存活对象，回收死亡对象的内存空间

Serial GC： 只有一个 collector进行回收（有暂停）

image.png

Parallel GC： 并行 GC，支持多个 collectors 同时回收的 GC 算法（有暂停）

image.png

Concurrent GC： 并发 GC，支持 mutator(s) 和 collector(s) 同时执行的 GC 算法（不需暂停）

image.png

Collectors 必须感知对象指向关系的改变！

image.png

  • 评价GC算法

    • 安全性（Safety）： 不能回收存活的对象（基本要求）
    • 吞吐率（Throughput）： 1−GC时间程序执行总时间1-\frac{GC时间}{程序执行总时间} （花在GC上的时间）
    • 暂停时间（Pause time）： stop the world（STW）（业务是否感知）
    • 内存开销（Space overhead） （GC元数据开销）

  • 追踪垃圾回收（Tracing garbage collection）

  • 引用计数（Reference counting）

5.2.1 追踪垃圾回收

Tracing garbage collection：追踪垃圾回收

  • 对象被回收的条件：指针指向关系不可达对象

    image.png

  • 过程

    • 标记根对象 (GC roots)： 静态变量、全局变量、常量、线程栈等

    • 标记： 找到所有可达对象

      求指针指向关系的传递闭包 - 从根对象出发，找到所有可达对象

    • 清理： 回收所有不可达对象占据的内存空间

      • Copying GC： 将存活对象从一块内存空间复制到另外一块内存空间，原先的空间可以直接进行对象分配

      image.png

      • Mark-sweep GC： 将死亡对象所在内存块标记为“可分配”，使用 free list 管理可分配的空间 image.png
      • Mark-compact GC： 移动并整理存活对象，将存活对象复制到同一块内存区域的开头 image.png

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

5.2.2 分代GC（Generational GC）

  • 分代假说（Generational hypothesis）：most objects die young
  • Intuition： 很多对象在分配出来后很快就不再使用了
  • 每个对象都有年龄：经历过GC的次数
  • 目的： 对年轻和老年的对象，制定不同的GC策略，降低整体内存管理的开销
  • 不同年龄的对象处于heap的不同区域

image.png

1. 年轻代（Young generation）

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

2. 老年代（Old generation）

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

5.2.3 引用计数

  • 每个对象都有一个与之关联的引用数目

  • 对象存活的条件：当且仅当引用数大于 0

    image.png

  • 优点：

    • 内存管理的操作被平摊到程序运行中：指针传递的过程中进行引用计数的增减

      image.png

    • 不需要了解 runtime 的细节：因为不需要标记 GC roots，因此不需要知道哪里是全局变量、线程栈等（类似C++智能指针）

  • 缺点：

    • 维护的开销大：因为对象可能会被多线程访问，对引用计数的修改需要通过原子操作保证引用计数操作的原子性和可见性

    • 无法回收环形数据结构（语言上解决方法 - weak reference）

      image.png

    • 内存开销： 每个对象都引入额外存储空间存储引用数目

    • 虽然引用计数的操作被平摊到程序运行过程中，但是回收大的数据结构依然可能引发暂停

5.3 Go 内存管理及优化

5.3.1 Go 内存管理

1. Go内存分配 - 分块

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

  • 提前将内存分块

    • 调用系统调用 mmap() 向 OS 申请一大块内存，例如 4 MB

    • 先将内存划分成大块，例如 8 KB，称作 mspan

    • 再将大块继续划分成特定大小的小块，用于对象分配

    • noscan mspan：分配不包含指针的对象 —— GC 不需要扫描

    • scan mspan：分配包含指针的对象 —— GC 需要扫描

      image.png

  • 对象分配：根据对象的大小，选择最合适的块返回

2. Go内存分配 - 缓存

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

  • 借鉴TCMalloc: thread caching

  • 每个p包含一个mcache用于快速分配，用于为绑定于p上的g分配对象

  • mcache管理一组mspan

  • 当mcache中的mspan分配完毕，向mcentral申请带有未分配块的mspan

  • 当mspan中没有分配的对象，mspan会被缓存在mcentral中，而不是立即释放并归还给OS

  • Go 内存管理构成了多级缓存机制，从 OS 分配得的内存被内存管理回收后，也不会立刻归还给 OS，而是在 Go runtime 内部先缓存起来，从而避免频繁向 OS 申请内存。内存分配的路线图如下。

    image.png

5.3.2 Go 内存分配存在的问题

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

  • Go内存分配比较耗时

    • 分配路径长： g -> m -> p -> mcache -> mspan -> memory block -> return pointer

    • pprof：对象分配函数是最频繁调用的函数之一，占用很多CPU

      image.png

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

  • 小对象分配占大多数

    image.png

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

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

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

    image.png

  • 每个 g 会附加一个较大的 allocation buffer (例如 1 KB) 用来分配小于 128 B 的 noscan 小对象

  • 指针碰撞(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 使用

细节分析：

  • 从 Go runtime 内存管理模块的角度看，一个 allocation buffer 其实是一个大对象

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

  • 问题： GAB的对象分配方式会导致内存被延迟释放

    因此，当 GAB 中哪怕只有一个小对象存活时，Go runtime 也会认为整个大对象（即 GAB）存活。

  • 方法： 移动GAB中存活的对象

    • balanced GC 会根据 GC 策略，当GAB总大小超过一定阈值时，将 GAB 中存活的对象移动到另外的 GAB 中，从而压缩并清理 GAB 的内存空间

    • 原先的 GAB 空间由于不再有存活对象，可以全部释放，避免内存泄漏

      image.png

      上图上方是两个 GAB，其中虚线表示 GAB 中对象的分界线。黑色表示 GAB 中存活的对象，白色表示死掉的对象。由于 GAB 中有存活对象，整个 GAB 无法被回收。

      Balanced GC 会将 GAB 中存活的对象移动到下面的 GAB 中，这样原先的两个 GABs 就可以被释放，压缩并清理 GAB 的内存空间。

      Balanced GC 只负责 noscan 对象的分配和移动，对象的标记和回收依然依赖 Go GC 本身，并和 Go GC 保持兼容。

    • 本质： 用 copying GC 的算法管理小对象（根据对象的生命周期，使用不同的标记和清理策略）

avatar
文章
阅读
粉丝