Go参考TcMalloc内存分配

我发现搞懂 Go 语言内存对象分配，真的没有那么简单。为什么要搞懂 Go 语言的内存分配呢，吃饱了撑的呢！我计划多涉猎些博客，能弥补这块的知识缺失。但也可能中途就放弃了…

TCMalloc 图解

下图是截取自《Go语言变编程入门和实战技巧》这本书中的示例图，Go 语言使用了类似这样的内存分配实现。TCMalloc 内存管理体系分为三个层次：ThreadCache、CentralCache、PageHeap。采用了三级的内存管理，分配内存和释放内存都从 ThreadCache 开始，向上逐级尝试。

内存管理的整体思路：首先在 ThreadCache 分配内存，如果内存分配失败，则从下一层的 CentralCache 中补一批上来，如果还不够就从 PageHeap 申请，再不够就向操作系统申请。释放内存也类似，逐级归还。

这里重点强调一下 ThreadCache 这个对象，很容易让人想到 Go 调度中 M 对象，M 扮演线程的角色。在 P 对象的结构体中包含一个 mcahce 对象，虽然 mcache 没有声明在 M 结构体中，但 mcache 对应的其实就是图中的 ThreadCache 对象。

再次强调一下 mcache 对象，下面是源码库中对 mcache 的注释，关注到三个细节点：小对象、单线程、无锁操作。让我们思路重新回到 TCMalloc 这张图上。

// Per-thread (in Go, per-P) cache for small objects.
// This includes a small object cache and local allocation stats.
// No locking needed because it is per-thread (per-P).
//
// mcaches are allocated from non-GC'd memory, so any heap pointers
// must be specially handled.
//

如果只是看上面那张图，感觉已经把该囊括的都囊括了，但又觉得只是蜻蜓点水。

我查看了 TCMalloc : Thread-Caching Malloc 中对于 TCMalloc 的介绍，和第一张图相比，这张图在介绍的时候，拆成了三个模块：front-end 负责快速分配、回收内存；middle-end 用于补充 front-end 所需内存；back-end 用来从操作系统申请内存。

但是，我们依旧能看到 Per-thread、Center free list、page heap 这几个重复的角色，两者相互佐证一下，TCMalloc 可能真的就是这样子。图中提到的 Legacy page heap，我比较奇怪，为什么要使用 Legacy 这个形容词呢？

关于这三层结构，我有话要说：确定模块的边界非常重要，不同的模块有明确的不同职责。这样的设计其实很常见，我们在设计缓存架构时，常见的三层查询：本地内存 -> Redis -> DB，本质上其实差不多。

小对象申请

下面计划深入一些细节，TCMalloc 设计了两种内存管理形式，分别是 span 和 object。其中，span 是由一组连续 page 组成的内存块，它由 central 进行管理；object 是将 span 按照特定规格进行切割，固定尺寸的小块内存。

之所以再特别强调一下 object，是因为别把这个 object 理解错了，在这篇文章里，它就描述固定尺寸的小块内存。

接下里，我要开始翻另一篇 TCMalloc : Thread-Caching Malloc 文章，关于小块内存的的申请。ThreadCache 主要负责小块内存的分配，根据需要申请的内存大小计算对应的 size class，然后从对应的 object 链表中获取 object。

如下面这张图所示，每个 size class 都对应了一个 object 链表。如果查找到的 object 链表非空，我们直接移除链表的头结点并返回。如果为空，就向 central free list 申请一批该尺寸的的 object 加入到链表中，重新执行非空链表的获取逻辑。

关于提到的 object，该如何在代码中体现出来呢？每个 size class 对应一个 object 链表，类似于一个本地对象池。在这个池子为空的时候，可以申请向池子中添加 object。但是当池子满了的话，后续释放的 object 就无法放回池子，这部分 object 就需要被回收。池子的初始尺寸多大？该如何回收那行无法放回池子的 object？

正如上面提到的问题，通过阅读别人写的博客，是无法了解到具体细节的，主要还是看我们想了解到什么程度。

大对象申请

我们继续看大对象的申请，它和小对象的申请是明显区分的。针对超出 size class 范围的内存对象，会按照 page 为单位进行申请，如下图所示，它和小对象的 class size 类似，也是从小到大的等级链表。不过，这里的申请逻辑和小对象申请有明显的差异。

下图中不同数量的 page，其实表示的是不同尺寸的 span 对象。当所需尺寸的 span 没有空闲时，可以把更大尺寸的 span 进行拆分，如果大的 span也没有了，就需要向操作系统申请。

比如，我需要申请 3 pages 的内存，但是 3 pages 对应的链表为空，我会继续看 4 pages 是否有可用的内存，直到最终找到一个可用的等级内存。假设 4 pages 链表也为空，我最终匹配到了 5 pages 的内存。但我实际值需要 3 pages 的内容，那多出来的 2 pages 会被插入到合适的链表中。

因为申请到更大的尺寸，那多余出来的 pages，是如何分配插入其他合适链表的呢？这个也很重要，比如上面多出来的 2 pages，是插入到 2pages 对应的链表呢？还是拆分成 2 个独立的 page，插入到 1page 对应的链表？万一1 page 和 2 pages 链表中非空元素特别多怎么办？

我也不知道