tmalloc概述

转自：

和 http://hi.baidu.com/rodimus/blog/item/65cbbd17f080661ac83d6d7b.html

TCMalloc () 是用于优化C++写的多线程应用(请谨记是多线程)

背景和策略

不可能所有的长度都对应一个链表。很多内存池是假设，A释放掉一块内存后，B会申请类似大小的内存，但是A释放的内存跟B需要的内存不一定完全相等，可能有一个小的误差，如果严格按大小分配，会导致复用率很低，这样各个拉链上都会有很多释放了，但是没有复用的内存，导致利用率很低。这个问题也是可以解决的，可以回收这些空闲的内存，但是这样就变成传统的内存管理，不停地对内存块作切割和合并，会导致效率低下。所以通常的做法是只分配有限种类的长度。一般的内存池只提供几十种选择。

tcmalloc在这点做得比较激进，对于小内存，按8的整数次倍分配，对于大内存，按4K的整数次倍分配。这样做有两个好处，一是分配的时候比较快，那种提供几十种选择的内存池，往往要遍历一遍各种长度，才能选出合适的种类，而tcmalloc则可以简单地做几个运算就行了。二是短期的收益比较大，分配的小内存至多浪费7个字节，大内存则4K。但是长远来说，tcmalloc分配的种类还是比别的内存池要多很多的，可能会导致复用率很低。

所以tcmalloc还要有一套高效的机制回收这些空闲的内存。当一个线程的空闲内存比较多的时候，会交还给进程，进程可以把它调配给其他线程使用；如果某种长度交还给进程后，其他线程并没有需求，进程则把这些长度合并成内存页，然后切割成其他长度。如果进程占据的资源比较多呢，据说不会交回给操作系统。

优势

1.分配内存页的时候，直接跟OS打交道，而常用的内存池一般是基于别的内存管理器上分配，如果完全一样的内存管理策略，明显tcmalloc在性能及内存利用率上要省掉第三方内存管理的开销。之所以会出现这种情况，是因为大部分写内存池的coder都不太了解OS

2.大部分的内存池只负责分配，不管回收。当然了，没有回收策略，也有别的方法解决问题。比如线程之间协调资源，模索模块一般是一写多读，也就是只有一个线程申请、释放内存，就不存在线程之间协调资源；为了避免某些块大量空闲，常用的做法是减少内存块的种类，提高复用率，这可能会造成内部碎片比较多，如果空闲的内存实在太多了，还可以直接重启。

3.对比glibc可以发现，两者的思想其实是差不多的，差别只是在细节上，细节上的差别，对工程项目来说也是很重要的，至少在性能与内存使用率上tcmalloc是领先很多的。glibc在内存回收方面做得不太好，常见的一个问题，申请很多内存，然后又释放，只是有一小块没释放，这时候glibc就必须要等待这一小块也释放了，也把整个大块释放，极端情况下，可能会造成几G的浪费

使用

要使用TCMalloc，只要将tcmalloc通过“-ltcmalloc”链接器标志接入你的应用即可。
你也可以通过使用LD_PRELOAD在不是你自己编译的应用中使用tcmalloc：
$ LD_PRELOAD=”/usr/lib/libtcmalloc.so”
LD_PRELOAD比较讨巧，我们也不十分推荐这种用法。
TCMalloc还包含了一个堆检查器以及一个堆测量器。
如果你更想链接不包含堆测量器和检查器的TCMalloc版本（比如可能为了减少静态二进制文件的大小），你可以接入libtcmalloc_minimal。

内存分配策略

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

TCMalloc将尺寸小于<=
32K的对象（“小”对象）和大对象区分开来。大对象直接使用页级分配器（一个页是一个4K的对齐内存区域）从中央堆直接分配。即，一个大对象总是页对齐的并占据了整数个数的页。
连续的一些页面可以被分割为一系列小对象，而他们的大小都相同。例如，一个连续的页面（4K）可以被划分为32个128字节的对象。