memcached源码分析之内存管理 -- Slab Allocator(2)

转自：http://slowsnail.com.cn/

Slab Allocator源码分析：

前言：虽然会对slab allocator的所有代码进行注释解说，但是slab allocator的很多代码都是与slab的状态获取相关，那些函数不是我们分析的重点，我们将重点放在其提供的功能性接口上。另外slab allocator存在一个自动平衡的机制，该部分由于牵扯到别的模块，读者如果现在接触可能反而会蒙圈，之后的文章中我将会单独对其进行讲解。这样有利于理清其脉络。

Slab Allocator 的源码结构：

Slabs.h //slab allocator头文件，定义了allocator的外部接口
Slabs.c //slab allocator的接口实现都写在里面
Memcached.h //定义了一些slab模块中用到的宏，以及功能性函数，一些数据结构的声明（不是此处的重点）
Memcached.c //对memcached.h中定义的函数的实现（不是此处的重点）。

实际上memcached.c中的内容远远比上面提及的多得多，单个文件的大小就达到了差不多6000行。但是里面与slab相关的函数很少，用户可以当做slab allocator模块相关的代码文件就位slabs.h、slabs.c即可，之所以将memcached.h、memcached.c也列入其中，是为了让读者真得要自己去找一个函数的话知道去哪里找。

Slab allocator相关的概念以及数据结构：

上图中列出了slabclass在程序代码中的表示，没错它肯定是一个结构体。在它的成员变量中，相信除了slabs与slab_list，list_size，perslab，killing成员以外，其它的成员大家都能够根据说明知道其意义。Killing成员关系到slab allocator的自动平衡这里暂时不做讨论，读者也可以将其直接忽略掉。为了说明剩下的slabs，slab_list，list_size，perslab四个成员属性，需要先介绍一个slab这个概念。

Slab：每一个slab可以当做是一个内存“页”，slabclass每次向系统（调用memory_allocate函数）申请新的chunk组的时候都是以“页”为单位进行的。每当slabclass中chunk集的chunk被请求耗尽的时候，slab allocator都会向系统请求一个“页”的内存，并将该“页”的内存划分为对应大小的chunk，并将这些新获得的chunk加入到chunk集中。

有了slab的概念读者大概可以明白perslab的意义了，没错perslab即指每次请求的“页”中能容纳的chunk数，slabs则记录了该slabclass一共请求的slab“页”的个数，slab_list则存储着所请求的slab的其实地址的数组，list_size标识了slab_list数组的大小。

那么slabclass的结构体是看到了，那么上图中的item结构体又是什么呢？没错！Item结构体便是我们上面一直说到的chunk!途中列出了Item中的3个成员属性，实际上还有别的一些重要属性为列出来，我将会在下一篇博文中专门介绍Items模块，其中会对Item结构体进行详细的介绍，此处我们只需要到Item存在着一个向前指针，一个向后指针，和一个数据块数组。
由上图读者也可以发现，其实每个slabclass中的chunk集是以双向链表的形式进行组织的！

slab allocator中的函数说明：

slab模块向外部提供的接口

slabs.c中的static函数（相当于面向对象中的私有函数）