NGINX内存池的设计

NGINX是存池高性能高并发服务器的典范，NGINX常被用来作为HTTP和反向代理Web服务器，存池作为HTTP服务器，存池NGINX的存池工作模式是：接收一个来自client的request，处理该request，存池然后向client吐出response 。存池

这样的存池工作模式非常适合用内存池优化动态内存分配，NGINX内存池也是存池其优秀设计的典型案例。

NGINX为每个连接创建一个内存池对象，源码下载存池在处理该连接请求的存池过程中，所有的存池动态内存分配请求 ，都向内存池提交 ，存池返回结果后 ，存池再清理该连接的存池内存池，清理内存池不会把内存真正返回系统，存池会根据策略把一定量的内存缓存起来复用 。

因为请求的处理过程都在一个线程内进行
，所以该连接的内存池不需要处理多线程同步（免锁） ，中途也不需要释放内存（返回结果后统一释放），云计算避免了内存泄漏的隐患，安全性也得到了提升  。

NGINX内存池的设计概要request处理过程中，所有动态内存分配 ，都向连接专属的内存池申请。大尺寸内存按需分配，走malloc/free或mmap/munmap ，大块内存块用链表串起来
。小尺寸内存从内存页分配 ，批发转零售 ：先通过malloc/mmap申请一个4K（大小可配）的内存页（批发） ，再从内存页里细分（零售），内存也也会用链表串起来
。服务器租用内存池记着当前页指针，下次分配先从当前页尝试 ，内存页多次不满足分配请求后 ，才会修改当前页指针。

NGINX内存池的设计考虑 

对动态内存分配请求，根据参数size，区别对待  ：

(1) 如果大于等于某个阈值，则被视为大块内存
，大块内存分配直接调用标准C的malloc函数或系统调用mmap，内存池为大块内存维护一个单独的链表，用于统一释放
，大块也支持单独释放 。

(2) 如果小于某个阈值
，源码库会先判断当前页剩余的内存大小能否满足本次分配的尺寸要求 ：

如果满足，则简单的移动游标（实际上会考虑对齐要求）
，并返回移动前的游标位置（地址） ，这种情况概率高、效率高如果不满足，再次通过底层接口分一内存页，并从该页划分一块满足本次分配请求
，新分配的内存页，会通过链表串起来。

关于当前页指针：

假设当前页还剩500字节，但接下来的建站模板分配请求512字节，因为剩余尺寸不够，那么内存池会分配一个4K的新内存页，从新内存页划分出512字节返回，并把新内存页串到内存页链表。当前页指针还是指向剩余500字节的内存页
 ，内存池下次分配请求依然从旧内存页开始尝试。只有一个内存页在多次不满足分配尺寸要求后，才会修改内存池的当前页指针，这样做是为了减少内存浪费
。因为如果多次尝试后
，高防服务器依然不满足 ，那么这个内存页的剩余空间大概率会比较小 ，这时候跳过它
，也就合情合理了
。大多数的分配是请求小块内存，这部分高频请求用简单的移动游标满足，性能非常高，因为分配出去的小块内存不支持中途释放
，所以它消除了通用内存分配器为每个内存块增加的头部/尾部，提高了有效载荷，内存利用率高。大块内存的分配是小概率事件，因为大块被单独的链表串起来
，所以既支持统一释放，也可以通过遍历链表的方式中途释放大内存块，因为大块数量不多 ，所以遍历不会很耗费  。之所以要支持大块内存的中途释放 
，是为了避免内存占用过度膨胀（大块内存的一块就可能很大）  ，提高内存复用 。NGINX内存池小结为每个连接配一个内存池，使得无锁成为可能 。NGINX内存池专注于做好小块内存的分配
，大块的分配只是简单转交给malloc/mmap ，它在处理当前内存页指针的细节上做的比较好
，提升了内存利用率。跟一般内存池一样，NGINX内存池通过牺牲小块内存的中途释放能力 ，换取通过移动游标分配内存的高性能和高内存利用率；通过缓存内存的提升复用，本质上是以空间换时间，这些都体现了TradeOff的思想  。NGINX用很少的代码量，达到了很好的实际效果，值得学习借鉴。