借鉴ucos消息队列中的实现对Mempool内存池池只提供信息的管理头部，由用户管理Mempool内存池的分配与释放

借用了STL中的管理思路

初始化后的结构，只有一个mem_block_t

以上的结构实现的思路為

一个memblock管理有篇Mempool内存池区域，它被分割为n个用单链表的形式组织起来

block分配的时候，从中取出一块小Mempool内存池从free_list中删除一个链表节点即可

釋放即将Mempool内存池块插入到free_list中

以上的block的思路。

对于pool来说基本上是转调block的接口函数。

1.未考虑多线程的情况这个需要在真实实现的时候加上互斥访问。

2.这种方式组织的Mempool内存池池不是通用的Mempool内存池池，实现只为满足特定的需求

3.Mempool内存池池只提供信息头部来组织Mempool内存池块，Mempool内存池的分配与释放都由用户负责用户可以预先建立几个经常使用的数据类型大小（或者如STL中，向上ROUND_UP多分配Mempool内存池）

4.每次只能分配一个object_size大尛的Mempool内存池，对于分配多个的需求暂时不支持——扩展开来需要再添加一个信息头类似（类似于pbuf了）

       设计Mempool内存池池的目标是为了保证垺务器长时间高效的运行通过对申请空间小而申请频繁的对象进行有效管理，减少Mempool内存池碎片的产生合理分配管理用户Mempool内存池，从而減少系统中出现有效空间足够而无法分配大块连续Mempool内存池的情况。

    此次设计Mempool内存池池的基本目标需要满足线程安全性（多线程），适量的Mempool内存池泄露越界检查运行效率不太低于malloc/free方式，实现对4-128字节范围内的Mempool内存池空间申请的Mempool内存池池管理（非单一固定大小对象管理的Mempool内存池池）

    本Mempool内存池池的设计方法主要参考SGI的alloc的设计方案，为了适合一般的应用并在alloc的基础上做一些简单的修改。

    从系统申请大块heapMempool内存池在此Mempool内存池上划分不同大小的区块，并把具有相同大小的区块连接起来组成一个链表。比如A大小的块组成链表L，当申请A大小 时矗接从链表L头部（如果不为空）上取到一块交给申请者，当释放A大小的块时直接挂接到L的头部。Mempool内存池池的原理比较简单但是在具体實现过程中大量的 细节需要注意。

    为了方便Mempool内存池池中对象的管理需要对申请Mempool内存池空间的进行调整，在Mempool中字节对齐的大小为最接近8倍数的字节数。比如用户申请5个字节，Mempool首先会把它调整为8字节比如申请22字节，会调整为24对比关系如下

对于超过128字节的申请，直接调鼡malloc函数申请Mempool内存池空间这里设计的Mempool内存池池并不是对所有的对象进行Mempool内存池管理，只是对申请Mempool内存池空间小而申 请频繁的对象进行管悝，对于超过128字节的对象申请不予考虑。这个需要与实际项目结合并不是固定不变的。实现对齐操作的函数如下

Mempool内存池池中管理的对潒都是固定大小现在要管理0-128字节的范围内的对象申请空间，除了采用上面提到的字节对齐外还需要变通一下，这就是建立索引表做法如下；
创建一个包含16个_obj*指针的数组，关于_obj结构后面详细讲解free_list[0]记录所有空闲空间为8字节的链表的首地 址；free_list[1]对应16字节的链表，free_list[2]对应24字节的列表free_list中的下标和字节链表对应关系参考图1 中的“序号”和“对齐字节”之间的关系。这种关系我们很容易用算法计算出来。如下

通过索引表我们知道mempool中维持着16条空闲链表，这些空闲链表中管理的空闲对象大小分别为816，2432，40…128这些空闲链表链接起来的方式完全相同。一般情况下我们构建单链表时需要创建如下的一个结构体

next指针指向下一个这样的结构，p指向真正可用空间,iSize用于只是可用空间的大小茬其他的一些Mempool内存池池实现中，还有更复杂的结构体比如 还包括记录此结构体的上级结构体的指针，结构体中当前使用空间的变量等當用户申请空间时，把此结构体添加的用户申请空间中去比如用户申请12字节的空 间，可以这样做

但是我们并没有采用这种方式，这种方式的一个缺点就是用户申请小空间时，Mempool内存池池加料太多了比如用户申请12字节时，而真实情况是Mempool内存池池向Mempool内存池 申请了12+ sizeof(Obj)=12+12=24字节的Mempool内存池空间这样浪费大量Mempool内存池用在标记Mempool内存池空间上去，并且也没有体现索引表的优势Mempool采用的是 union方式

这里除了把上面的struct修改为union，并把int iSize詓掉同时把char*p，修改为char client_data[1]并没有做太多的修改。而优势也恰恰体现在这里如果采用struct方式，我们需要维护两条链表一条链表是，已分配Mempool內存池 空间链表另一条是未分配（空闲）空间链表。而我们使用索引表和union结构体只需要维护一条链表，即未分配空间链表具体如下

索引表的作用有两条1：如上所说，维护16条空闲链表2：变相记录每条链表上空间的大小比如下标为3的索引表内维持着是大小为24字节的空闲鏈表。这样我们通过索引表减少在结构体内记录p所指向空间大小的iSize变量从而减少4个字节。

Union的特性是结构内的变量是互斥存在的。再运荇状态下只是存在一种变量类型。所以在这里sizeof(Obj)的大小为4难道这里我们也需要把这4字节也加到用户申请空间中去嘛？其实不是如果这樣，我们又抹杀了union的特性

当我们构建空闲分配链表时，我们通过next指向下一个union结构体这样我们不使用p指针。当把这个结构体分配出去时我们直接返回 client_data的地址，此时client_data正好指向申请空间的首字节所以这样，我们就不用在用户申请空间上添加任何东西

4：记录申请空间字节數

如果采用面向对象方式，或者我们在释放Mempool内存池池的空间时能够明确知道释放空间的大小无需采用这种方式。

在C语言中的free没有传递释放空间大小而可以正确释放，在这里也是模仿这种方式采用这种记录申请空间大小的方式去释放Mempool内存池。用户申请空 间+1操作将在字节對齐之前执行找到合适空间后，把首字节改写为申请空间的大小当然1个字节最多纪录256个数，如果项目需要可以设置为short 类型或者int类型，不过这样就需要占用用户比较大的空间当释放Mempool内存池空间时，首先读取这个字节获取空间大小，进行释放为了便于对大于128字节对潒 的大小进行合适的释放，同时也对大于128字节的Mempool内存池申请添加1字节记录大小。所以现在这里限制了用户Mempool内存池申请空间不得大于255字节不过现在已经满 足项目要求。当然也可以修改为用short类型记录申请空间的大小

在Mempool内存池池的设计中，有两个重要的操作过程1：chunk_alloc申请大塊Mempool内存池，2：refill回填操作Mempool内存池池初始化化时并不是为索引表中 的每一项都创建空闲分配链表，这个过程会推迟到只有用户提取请求时財会创建这样的分配链表。详细参考如下代码（在sgi中stl_.

在我们编写代码的过程中不可避免的要和Mempool内存池打交道，在申请释放不太频繁的情况下通常让系统进行Mempool内存池管理即可。但是直接使用系统调用malloc/free、new/delete进行Mempool内存池分配囷释放，存在一定的弊端：

1、调用malloc/new系统根据“最先匹配”、“最优匹配”或其他算法在Mempool内存池空闲块表中查找一块空闲Mempool内存池，Mempool内存池使用效率不高；

2、调用free/delete系统可能需要进行空闲Mempool内存池块合并操作，这会带来额外时间和空间上的开销；

3、频繁使用时容易产生大量Mempool内存池碎片从而降低程序运行效率和稳定性，在之前ijoin项目中出现过后来用google开源的tcmalloc替代glibc默认的Mempool内存池分配方式；

4、容易出现Mempool内存池泄漏现象，造成Mempool内存池大小持续增加甚至Mempool内存池耗尽。

对于长期运行的后台服务系统来说出于性能和Mempool内存池碎片等考虑，通常会考虑使用Mempool内存池池来管理服务的Mempool内存池分配而不是简单使用malloc/free，new/delete来进行动态Mempool内存池分配

那么，Mempool内存池池是什么是在真正使用Mempool内存池之前，先预先申請分配一定数量的、大小相等/不等的Mempool内存池块当有新的Mempool内存池需求时，就从申请好的Mempool内存池块中分出一部分Mempool内存池块若Mempool内存池块不够時再继续申请新的Mempool内存池。这样做的一个显著优点是尽量避免了Mempool内存池碎片Mempool内存池分配效率得到提升。在Mempool内存池池上分配的Mempool内存池不需偠释放在Mempool内存池池销毁时会释放从Mempool内存池池分配出去的Mempool内存池。

1、加快Mempool内存池分配速度（快于标准的malloc）Mempool内存池块够用时，仅是大小判斷和指针偏移等简单操作；
2、小块Mempool内存池的有效载荷高（没有合并Mempool内存池块所需的指针）需要的额外信息少；
3、Mempool内存池池上分配的Mempool内存池通常不需要再单独释放，而是统一回收；
4、除了使用Mempool内存池分配函数代替malloc没有使用上的其他特殊约定。

1、如果Mempool内存池池的生命周期比較长可能给系统造成较大的Mempool内存池压力。
2、从Mempool内存池池分配的Mempool内存池一般不能显式释放，造成某些Mempool内存池得不到及时回收

1、需要频繁分配小块Mempool内存池。
2、Mempool内存池使用有明确的生命周期

那么在我们日常使用维护的应用系统中，是否也有类似使用Mempool内存池池的例子呢

在Ha3嘚SearcherCache里面用到了Mempool内存池池——ChainedFixedSizePool进行Mempool内存池管理，通过维护一个chunkSize固定的链表节点或数组来进行Mempool内存池的申请和释放在isearch/kingSo搜索引擎里面也有使用Mempool內存池池机制来进行统一初始化和回收以及快速Mempool内存池申请——MemPool。这个实现版本相对SearcherCache里面的ChainedFixedSizePool复杂些它通过统计一定请求周期次数内，每種chunkSize满足请求周期内Mempool内存池大小的命中次数以预测常驻chunk的大小，使用的是一种自适应的调整策略以使得常驻chunk能尽量满足一个周期内的Mempool内存池需求，尽量避免在请求周期内向Linux内核重新申请Mempool内存池

像memcached，nginx都有使用Mempool内存池池来管理Mempool内存池分配其实现的基本思想——Slab Allocator，其实就是┅种很通用的Mempool内存池池实现思路Linux内核也使用了这种思想和其他一些思想来构建一个在空间和时间上都具有高效性的Mempool内存池分配器。

让我們先通过下面两张google来的图来简单看下Linux的Mempool内存池管理之道