性能优化-内存池的设计和实现，看这篇文章就够了

在之前的文章中，我们分析了glibc内存管理相关的内容，里面的是不是逻辑复杂，毕竟咱们用几十行代码完成的功能，glibc要用上百乃至上千行代码来实现，毕竟它的受众太多了，需要考虑跨平台，各种边界条件等。

其实，glibc的内存分配库ptmalloc也可以看做是一个内存池，出于性能考虑，每次内存申请都是先从ptmalloc中进行分配，如果没有合适的则通过系统分配函数进行申请；在释放的时候，也是将被释放内存先方式内存池中，内存池根据一定的策略，来决定是否进行shrink以归还OS。

那么，发现一个内存池？我们该怎么实现呢？今天，借助这篇文章，我们一起来设计和实现一个内存池(文末附有github地址)。

背景

首先需要说明的是，该内存池是笔者在10年前完成的，下面先说下当时此项目的背景。

09年，在某所的时候，参与了某个国家级项目，该项目是防DDOS攻击相关，因此更多的是跟IP相关，所以每次分配和释放内存都是固定大小，经过测试，性能不是很满意，所以，经过代码分析以及性能攻击分析，发现里面有大量的malloc/free，所以，当时就决定是否从malloc/free入手，能否优化整个项目的性能。

所以，决定实现一个Memory Pool，在做了调研以及研究了相关论文后，决定实现一个内存池，先试试水，所幸运的是，性能确实比glibc自带的malloc/free要高，所以也就应用于项目上了。

❝

本文所讲的Memory Pool为C语言实现，旨在让大家都能看懂，看明白(至少能够完全理解本文所讲的Memory Pool的实现原理)。

❞

概念

首先，我们介绍下什么是内存池？

❝

预先在内存中申请一定数量的内存块留作备用，当有新的内存需求时，就先从内存池中分配内存返回，在释放的时候，将内存返回给内存池而不是OS，在下次申请的时候，重新返回

❞

那么为什么要有内存池呢？这就需要从传统内存分配的特点来进行分析，传统内存分配释放的优点无非就是 通用性强，应用广泛，但是传统的内存分配、释放在某些特定的项目中，其不一定是最优、效率最高的方案。

传统内存分配、释放的缺点总结如下：

1、调用malloc/new,系统需要根据“最先匹配”、“最优匹配”或其他算法在内存空闲块表中查找一块空闲内存，调用free/delete,系统可能需要合并空闲内存块，这些会产生额外开销

2、频繁地在堆上申请和释放内存必然需要大量时间，降低了程序的运行效率。对于一个需要频繁申请和释放内存的程序来说，频繁调用new/malloc申请内存，delete/free释放内存都需要花费系统时间，频繁的调用必然会降低程序的运行效率。

3、经常申请小块内存，会将物理内存“切”得很碎，导致内存碎片。申请内存的顺序并不是释放内存的顺序，因此频繁申请小块内存必然会导致内存碎片，造成“有内存但是申请不到大块内存”的现象。

内存分配

从上图中，可以看出，应用程序会调用glibc运行时库的malloc函数进行内存申请，而malloc函数则会根据具体申请的内存块大小，根据实际情况最终从sys_brk或者sys_mmap_pgoff系统调用申请内存，而大家都知道，跟os打交道，_性能损失_是毋庸置疑的。

其次，glibc作为通用的运行时库，malloc/free需要满足各种场景需求，比如申请的字节大小不一，多线程访问等。

没有比传统malloc/free性能更优的方案呢？

答案是：有。

在程序启动的时候，我们预分配特定数量的固定大小地块，这样每次申请的时候，就从预分配的块中获取，释放的时候，将其放入预分配块中以备下次复用，这就是所谓的_内存池技术_，每个内存池对应特定场景，这样的话，较传统的传统的malloc/free少了很多复杂逻辑，性能显然会提升不少。

结合传统malloc/free的缺点，我们总结下使用内存池方案的优点：

1、比malloc/free进行内存申请/释放的方式快

2、不会产生或很少产生堆碎片

3、可避免内存泄漏

分类

根据分配出去的字节大小是否固定，分为 固定大小内存池 和 可变大小内存池 两类。

而可变大小的内存池，可分配任意大小的内存池，比如ptmalloc、jemalloc以及google的tcmalloc。

固定大小的内存池，顾名思义，每次申请和释放的内存大小都是固定的。每次分配出去的内存块大小都是程序预先定义的值，而在释放内存块时候，则简单地挂回内存池链表即可