jemalloc原理概览

jemalloc在linux的世界里声名鹊起，并被移植到多个平台。后起之秀的tcmalloc性能与之相近，虽有谷歌这个牛爹，但因jemalloc专美在前，tcmalloc的使用范围还是略逊一筹。网络上关于jemalloc的各种解读很多，不再一一赘述，这里 挑一些关键点来分析。

一、地址访问

malloc和free的第一个参数都是内存地址，如何快速定位到该地址所属的内存块基址呢，在高频内存分配中，这是第一 要务。jemalloc使用一个简单的技巧，chunk = addr & (~chunksize_mask) ，确保寻址O(1)就能完成。在这个公式中，有一个很隐晦的前提是，chunk的地址，必须能够满足类似0xaabb0000这样格式，其尾部0的数量要大于等于chunksize_mask的F的数量。

jemalloc在分配时，会做这样的尝试，alloc_size = size + aligment - PAGE_SIZE，然后去掉头部，保证chunk地址满足这样的条件。如果不能，则将多余的内存地址还给系统。

二、内存页管理

小对象可以用技巧映射到chunk，对于chunk寻址就没有办法用上面这招了。jemalloc用三层基数树，所以查找效率还是相当高的，只是增删除改查时，需要加锁。加锁会影响效率，当因为次数比较少，倒不会有太大的影响。需要注意的是，jemalloc的这个全局基数树的节点在分配之后，是不释放的，直到最终进程退出。jemalloc从系统中，每次都是以4M为基准申请的。

三、长度对齐

在实际场景中，请求分配字节大小是随机的，如果按照真实大小分配，容易引起内存页缺失中断，因此需要字节对齐。在jemalloc中，并不是固定字节对齐，而是按照如下表的逻辑：

序号	大小区间	字节对齐
0	[0--16]	8
1	(16 , 128]	16
2	(128 , 256]	32
3	(256 , 512]	64

四、线程竞争

在内存分配过程中，锁会造成线程等待，对性能影响巨大。jemalloc采用了两种措施避免线程竞争锁的发生，

1、使用线程变量，每个线程有自己的内存管理器，分配在这个线程内完成，就不需要和其他线程竞争。

2、竞技场，分配一个数组，每个线程通过线程号的映射，对应到一个数组元素中。这样，多个线程竞争一个元素的概率就下降。

有点令人诧异的是，jemalloc使用原子操作基本没有，锁都是用粒度较大的mutex。只有需要较长等待时，比如陷入系统时才有必要用这种粗粒度的锁。和竞技场相关的资料颇多，可以在网上找找。

五、分配流程

我们假设一个应用场景，要分配一个大小为SIZE的内存块，那么流程如下：

1、选定一个arena或者tcache。

2、计算对应的对齐长度，见第三节，根据对齐长度，计算出arena中bins的下标。

3、在一个bins中，如果runccur可用，则在runcur中分配，否则从runs中选择一个。

4、从选定的run中，计算bitmap，得到空闲的region，后返回。