内存管理及优化 ｜ 青训营笔记

繁星点点85
101 阅读7分钟

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

引言

什么是性能优化

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

性能优化的原因

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

性能优化的层面

业务层优化

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

语言运行时优化

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

数据驱动

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

自动内存管理

基本概念

动态内存

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

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

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

三个任务

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

相关概念解析

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

image.png

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

追踪垃圾回收（Tracing garbage collection）

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

过程：

  • 标记根对象 (GC roots): 静态变量、全局变量、常量、线程栈等
  • 标记：找到所有可达对象：求指针指向关系的传递闭包，从根对象出发，找到所有可达对象
  • 清理：回收所有不可达对象占据的内存空间,具体形式如下：
    1.Copying GC: 将存活对象从一块内存空间复制到另外一块内存空间，原先的空间可以直接进行对象分配

image.png
2.Mark-sweep GC: 将死亡对象所在内存块标记为可分配，使用 free list 管理可分配的空间

image.png 3.Mark-compact GC: 将存活对象复制到同一块内存区域的开头

image.png

引用计数

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

优点

  • 内存管理的操作被平摊到程序运行中：指针传递的过程中进行引用计数的增减
  • 不需要了解 runtime 的细节：因为不需要标记 GC roots，因此不需要知道哪里是全局变量、线程栈等

缺点

  • 开销大，因为对象可能会被多线程访问，对引用计数的修改需要原子操作保证原子性和可见性
  • 无法回收环形数据结构
  • 每个对象都引入额外存储空间存储引用计数
  • 虽然引用计数的操作被平摊到程序运行过程中，但是回收大的数据结构依然可能引发暂停

GO语言内存管理的具体实现

内存池mheap

Golang 的程序在启动之初，会一次性从操作系统那里申请一大块内存作为内存池。这块内存空间会放在一个叫 mheap 的 struct 中管理，mheap 负责将这一整块内存切割成不同的区域，并将其中一部分的内存切割成合适的大小，分配给用户使用。
我们需要先知道几个重要的概念：

  • page : 内存页，一块 8K 大小的内存空间。Go 与操作系统之间的内存申请和释放，都是以 page 为单位的。
  • span : 内存块，一个或多个连续的 page 组成一个 span 。如果把 page 比喻成工人， span 可看成是小队，工人被分成若干个队伍，不同的队伍干不同的活。
  • sizeclass : 空间规格，每个 span 都带有一个 sizeclass ，标记着该 span 中的 page 应该如何使用。使用上面的比喻，就是 sizeclass 标志着 span 是一个什么样的队伍。
  • object : 对象，用来存储一个变量数据内存空间，一个 span 在初始化时，会被切割成一堆等大的 object 。假设 object 的大小是 16B ， span 大小是 8K ，那么就会把 span 中的 page 就会被初始化 8K / 16B = 512 个 object 。所谓内存分配，就是分配一个 object 出去。
    示意图如下：

image.png
上图中，不同颜色代表不同的 span ，不同 span 的 sizeclass 不同，表示里面的 page 将会按照不同的规格切割成一个个等大的 object 用作分配。
内部的整体内存布局如下图所示：

image.png

  • mheap.spans ：用来存储 page 和 span 信息，比如一个 span 的起始地址是多少，有几个 page，已使用了多大等等。

  • mheap.bitmap 存储着各个 span 中对象的标记信息，比如对象是否可回收等等。

  • mheap.arena_start : 将要分配给应用程序使用的空间。

再说明下，图中的空间大小，是 Go 向操作系统申请的虚拟内存地址空间，操作系统会将该段地址空间预留出来不做它用；而不是真的创建出这么大的虚拟内存，在页表中创建出这么大的映射关系。

mcentral

用途相同的 span 会以链表的形式组织在一起。 这里的用途用 sizeclass 来表示，就是指该 span 用来存储哪种大小的对象。比如当分配一块大小为 n 的内存时，系统计算 n 应该使用哪种 sizeclass ，然后根据 sizeclass 的值去找到一个可用的 span 来用作分配。其中 sizeclass 一共有 67 种，如图所示：

image.png
找到合适的 span 后，会从中取一个 object 返回给上层使用。这些 span 被放在一个叫做 mcentral 的结构中管理。

mheap 将从 OS 那里申请过来的内存初始化成一个大 span (sizeclass=0)。然后根据需要从这个大 span 中切出小 span ，放在 mcentral 中来管理。大 span 由 mheap.freelarge 和 mheap.busylarge 等管理。如果 mcentral 中的 span 不够用了，会从 mheap.freelarge 上再切一块，如果 mheap.freelarge 空间不够，会再次从 OS 那里申请内存重复上述步骤。下面是 mheap 和 mcentral 的数据结构：

image.png
这种方式可以避免出现外部碎片（文章最后面有外部碎片的介绍），因为同一个 span 是按照固定大小分配和回收的，不会出现不可利用的一小块内存把内存分割掉。这个设计方式与现代操作系统中的伙伴系统有点类似。

mcache

mcentral 结构中有一个 lock 字段；因为并发情况下，很有可能多个线程同时从 mcentral 那里申请内存的，必须要用锁来避免冲突。
但锁是低效的，在高并发的服务中，它会使内存申请成为整个系统的瓶颈；所以在 mcentral 的前面又增加了一层 mcache。

每一个 mcache 和每一个处理器(P) 是一一对应的，也就是说每一个 P 都有一个 mcache 成员。 Goroutine 申请内存时，首先从其所在的 P 的 mcache 中分配，如果 mcache 没有可用 span ，再从 mcentral 中获取，并填充到 mcache 中。

从 mcache 上分配内存空间是不需要加锁的，因为在同一时间里，一个 P 只有一个线程在其上面运行，不可能出现竞争。没有了锁的限制，大大加速了内存分配。

所以整体的内存分配模型大致如下图所示：

image.png

avatar
文章
阅读
粉丝