TCMalloc：线程缓存的Malloc [Webkit有其应用]

以你之姓@ 2022-06-12 12:49 174阅读 0赞

作者：Sanjay Ghemawat, Paul Menage

[原文 ][Link 1]

翻译：[ShiningRay ][ShiningRay]

TCMalloc要比glibc 2.3的`malloc`（可以从一个叫作ptmalloc2的独立库获得）和其他我测试过的`malloc`都快。ptmalloc在一台2.8GHz的P4机器上（对于小对象）执行一次`malloc`及`free`大约需要300纳秒。而TCMalloc的版本同样的操作大约只需要50纳秒。malloc版本的速度是至关重要的，因为如果`malloc`不够快，应用程序的作者就很有可能在`malloc`之上写一个自己的[自由列表 ][Link 2]。这就可能导致额外的代码复杂度，以及更多的内存占用――除非作者本身非常仔细地划分自由列表的大小并经常从自由列表中清除空闲的对象。

TCMalloc也减少了多线程程序中的锁争用情况。对于小对象，几乎已经达到了零争用。对于大对象，TCMalloc尝试使用粒度较好和有效的自旋锁。ptmalloc同样是通过使用每线程各自的场地来减少锁争用，但是ptmalloc2使用每线程场地有一个很大的问题。在ptmalloc2中，内存可能会从一个场地移动到另一个。这有可能导致大量空间被浪费。例如，在一个Google的应用中，第一阶段可能会为其URL标准化的数据结构分配大约300MB内存。当第一阶段结束后，第二阶段将从同样的地址空间开始。如果第二个阶段被安排到了一个与第一阶段什?用的场地不同的场地，这个阶段不会复用任何第一阶段留下的的内存，并会给地址空间添加另外一个300MB。类似的内存爆炸问题也可以在其他的应用中看到。

TCMalloc的另一个好处是小对象的空间最优表现形式。例如，分配N个8字节对象可能要使用大约`8N * 1.01`字节的空间。即，多用百分之一的空间。而ptmalloc2中每个对象都使用了一个四字节的头，（我认为）并将最终的尺寸规整为8字节的倍数，最后使用了`16N`字节。

要使用TCMalloc，只要将tcmalloc通过“-ltcmalloc”链接器标志接入你的应用即可。

你也可以通过使用LD\_PRELOAD在不是你自己编译的应用中使用tcmalloc：

$ LD_PRELOAD="/usr/lib/libtcmalloc.so"

LD\_PRELOAD比较讨巧，我们也不十分推荐这种用法。

TCMalloc还包含了一个[堆检查器 ][Link 3]以及一个[堆测量器 ][Link 4]。

如果你更想链接不包含堆测量器和检查器的TCMalloc版本（比如可能为了减少静态二进制文件的大小），你可以接入`libtcmalloc_minimal`。

TCMalloc给每个线程分配了一个线程局部缓存。小分配可以直接由线程局部缓存来满足。需要的话，会将对象从中央数据结构移动到线程局部缓存中，同时定期的垃圾收集将用于把内存从线程局部缓存迁移回中央数据结构中。

![overview][]

TCMalloc将尺寸小于<=  
32K的对象（“小”对象）和大对象区分开来。大对象直接使用页级分配器（一个页是一个4K的对齐内存区域）从中央堆直接分配。即，一个大对象总是页对齐的并占据了整数个数的页。

连续的一些页面可以被分割为一系列小对象，而他们的大小都相同。例如，一个连续的页面（4K）可以被划分为32个128字节的对象。

## 小对象的分配 ##

每个小对象的大小都会被映射到170个可分配的尺寸类别中的一个。例如，在分配961到1024字节时，都会归整为1024字节。尺寸类别这样隔开：较小的尺寸相差8字节，较大的尺寸相差16字节，再大一点的尺寸差32字节，如此类推。最大的间隔（对于尺寸 >= ~2K的）是256字节。

一个线程缓存对每个尺寸类都包含了一个自由对象的单向链表。

![thread heap][]

当分配一个小对象时：

1.  我们将其大小映射到对应的尺寸类中。
2.  查找当前线程的线程缓存中相应的自由列表。
3.  如果自由列表不空，那么从移除列表的第一个对象并返回它。当按照这个快速通道时，TCMalloc不会获取任何锁。这就可以极大提高分配的速度，因为锁/解锁操作在一个2.8GHz Xeon上大约需要100纳秒的时间。

如果自由列表为空：

1.  从该尺寸类别的中央自由列表（中央自由列表是被所有线程共享的）取得一连串对象。
2.  将他们放入线程局部的自由列表。
3.  将新获取的对象中的一个返回给应用程序。

如果中央自由列表也为空：(1) 我们从中央页分配器分配了一连串页面。(2) 将他们分割成该尺寸类的一系列对象。(4) 像前面一样，将部分对象移入线程局部的自由列表中。

## 大对象的分配 ##

一个大对象的尺寸(> 32K)会被除以一个页面尺寸（4K）并取整（大于结果的最小整数），同时是由中央页面堆来处理的。中央页面堆又是一个自由列表的阵列。对于`i < 256`而言，第`k`个条目是一个由`k`个页面组成的自由列表。第`256`个条目则是一个包含了长度`>= 256`个页面的自由列表：

![Page heap][]

`k`个页面的一次分配通过在第`k`个自由列表中查找来完成。如果该自由列表为空，那么我们则在下一个自由列表中查找，如此继续。最终，如果必要的话，我们将在最后一个自由列表中查找。如果这个动作也失败了，我们将向系统获取内存（使用`sbrk`、`mmap`或者通过在`/dev/mem`中进行映射）。

如果`k`个页面的一次分配行为由连续的长度> `k`的页面满足了，剩下的连续页面将被重新插回到页面堆的对应的自由列表中。

## 跨度（Span） ##

TCMalloc管理的堆由一系列页面组成。连续的页面由一个“跨度”（`Span`）对象来表示。一个跨度可以是*已被分配*或者是*自由*的。如果是自由的，跨度则会是一个页面堆链表中的一个条目。如果已被分配，它会是一个已经被传递给应用程序的大对象，或者是一个已经被分割成一系列小对象的一个页面。如果是被分割成小对象的，对象的尺寸类别会被记录在跨度中。

由页面号索引的中央数组可以用于找到某个页面所属的跨度。例如，下面的跨度*a*占据了2个页面，跨度*b*占据了1个页面，跨度*c*占据了5个页面最后跨度*d*占据了3个页面。

![spanmap.gif][]

在一个32位的地址空间中，中央阵列由一个2层的基数树来表示，其中根包含了32个条目，每个叶包含了 215个条目（一个32为地址空间包含了 220个 4K 页面，所以这里树的第一层则是用25整除220个页面）。这就导致了中央阵列的初始内存使用需要128KB空间（215\*4字节），看上去还是可以接受的。

在64位机器上，我们将使用一个3层的基数树。

当一个对象被解除分配时，我们先计算他的页面号并在中央阵列中查找对应的跨度对象。该跨度会告诉我们该对象是大是小，如果它是小对象的话尺寸类别是什么。如果是小对象的话，我们将其插入到当前线程的线程缓存中对应的自由列表中。如果线程缓存现在超过了某个预定的大小（默认为2MB），我们便运行垃圾收集器将未使用的对象从线程缓存中移入中央自由列表。

如果该对象是大对象的话，跨度会告诉我们该对象覆盖的页面的范围。假设该范围是`[p,q]`。我们还会查找页面`p-1`和页面`q+1`对应的跨度。如果这两个相邻的跨度中有任何一个是自由的，我们将他们和`[p,q]`的跨度接合起来。最后跨度会被插入到页面堆中合适的自由列表中。

## 小对象的中央自由列表 ##

就像前面提过的一样，我们为每一个尺寸类别设置了一个中央自由列表。每个中央自由列表由两层数据结构来组成：一系列跨度和每个跨度一个自由对象的链表。

通过从某个跨度中移除第一个条目来从中央自由列表分配一个对象。（如果所有的跨度里只有空链表，那么首先从中央页面堆中分配一个尺寸合适的跨度。）

一个对象可以通过将其添加到他包含的跨度的链表中来返回到中央自由列表中。如果链表长度现在等于跨度中所有小对象的数量，那么该跨度就是完全自由的了，就会被返回到页面堆中。

## 线程缓存的垃圾收集 ##

某个线程缓存当缓存中所有对象的总共大小超过2MB的时候，会对他进行垃圾收集。垃圾收集阈值会自动根据线程数量的增加而减少，这样就不会因为程序有大量线程而过度浪费内存。

我们会遍历缓存中所有的自由列表并且将一定数量的对象从自由列表移到对于得中央列表中。

从某个自由列表中移除的对象的数量是通过使用一个每列表的低水位线`L`来确定的。`L`记录了自上一次垃圾收集以来列表最短的长度。注意，在上一次的垃圾收集中我们可能只是将列表缩短了`L`个对象而没有对中央列表进行任何额外访问。我们利用这个过去的历史作为对未来访问的预测器并将`L/2`个对象从线程缓存自由列表中移到相应的中央自由列表中。这个算法有个很好的特性是，如果某个线程不再使用某个特定的尺寸时，该尺寸的所有对象都会很快从线程缓存被移到中央自由列表，然后可以被其他缓存利用。

### PTMalloc2单元测试 ###

PTMalloc2包（现在已经是glibc的一部分了）包含了一个单元测试程序`t-test1.c`。它会产生一定数量的线程并在每个线程中进行一系列分配和解除分配；线程之间没有任何通信除了在内存分配器中同步。

`t-test1`（放在`tests/tcmalloc/`中，编译为`ptmalloc_unittest1`）用一系列不同的线程数量（1～20）和最大分配尺寸（64B～32KB）运行。这些测试运行在一个2.4GHz 双核心Xeon的RedHat 9系统上，并启用了超线程技术， 使用了Linux glibc-2.3.2，每个测试中进行一百万次操作。在每个案例中，一次正常运行，一次使用`LD_PRELOAD=libtcmalloc.so`。

下面的图像显示了TCMalloc对比PTMalloc2在不同的衡量指标下的性能。首先，现实每秒全部操作（百万）以及最大分配尺寸，针对不同数量的线程。用来生产这些图像的原始数据（`time`工具的输出）可以在`t-test1.times.txt`中找到。

*  TCMalloc要比PTMalloc2更具有一致地伸缩性——对于所有线程数量>1的测试，小分配达到了约7～9百万操作每秒，大分配降到了约2百万操作每秒。单线程的案例则明显是要被剔除的，因为他只能保持单个处理器繁忙因此只能获得较少的每秒操作数。PTMalloc2在每秒操作数上有更高的方差——某些地方峰值可以在小分配上达到4百万操作每秒，而在大分配上降到了<1百万操作每秒。
 *  TCMalloc在绝大多数情况下要比PTMalloc2快，并且特别是小分配上。线程间的争用在TCMalloc中问题不大。
 *  TCMalloc的性能随着分配尺寸的增加而降低。这是因为每线程缓存当它达到了阈值（默认是2MB）的时候会被垃圾收集。对于更大的分配尺寸，在垃圾收集之前只能在缓存中存储更少的对象。
 *  TCMalloc性能在约32K最大分配尺寸附件有一个明显的下降。这是因为在每线程缓存中的32K对象的最大尺寸；对于大于这个值得对象TCMalloc会从中央页面堆中进行分配。

下面，CPU时间的每秒操作数（百万）以及线程数量的图像，最大分配尺寸64B～128KB。

这次我们再一次看到TCMalloc要比PTMalloc2更连续也更高效。对于<32K的最大分配尺寸，TCMalloc在大线程数的情况下典型地达到了CPU时间每秒约0.5～1百万操作，同时PTMalloc通常达到了CPU时间每秒约0.5～1百万，还有很多情况下要比这个数字小很多。在32K最大分配尺寸之上，TCMalloc下降到了每CPU时间秒1～1.5百万操作，同时PTMalloc对于大线程数降到几乎只有零（也就是，使用PTMalloc，在高度多线程的情况下，很多CPU时间被浪费在轮流等待锁定上了）。

对于某些系统，TCMalloc可能无法与没有链接`libpthread.so`（或者你的系统上同等的东西）的应用程序正常工作。它应该能正常工作于使用glibc 2.3的Linux上，但是其他OS/libc的组合方式尚未经过任何测试。

TCMalloc可能要比其他malloc版本在某种程度上更吃内存，（但是倾向于不会有其他malloc版本中可能出现的爆发性增长。）尤其是在启动时TCMalloc会分配大约240KB的内部内存。

不要试图将TCMalloc载入到一个运行中的二进制程序中（例如，在Java中使用JNI）。二进制程序已经使用系统malloc分配了一些对象，并会尝试将它们传递到TCMalloc进行解除分配。TCMalloc是无法处理这种对象的。

[Link 1]: http://goog-perftools.sourceforge.net/doc/tcmalloc.html
[ShiningRay]: http://shiningray.cn
[Link 2]: http://en.wikipedia.org/wiki/Free_list
[Link 3]: http://google-perftools.googlecode.com/svn/trunk/doc/heap_checker.html
[Link 4]: http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html
[overview]: /images/20220612/710b8570e2f9451cb9934a95df42b1aa.png
[thread heap]: /images/20220612/8fba87816e374b62b0ba4518147777fe.png
[Page heap]: /images/20220612/893697b7008346e1ba4b83c1c81140f2.png
[spanmap.gif]: /images/20220612/08b74f7f17d348a6b9cca7a6efcf96bb.png