内存池及其他

最近在看nginx的代码，看了一下nginx内存池和字符串相关的代码。很简单的代码，就不分析啥了。

对类tcmalloc之类的内存分配库有一定了解的人，都知道其实这些库内部也都会做缓存，不会每次分配就找系统要每次释放就返回系统，因此我一直质疑有没有必要在应用层自己再做一次类似内存池这样的缓存。

回到nginx中，它的内存池算法及其简单，使用时是绑定在比如连接相关的结构体上，一个连接到来分配一个内存池，之后这个连接相关的内存分配操作都在这个内存池中进行，而在连接关闭之后与之相关的内存池就随之关闭。换言之，nginx试图通过内存池这个概念，将内存管理的粒度做的更小，比系统级的更小，这样也更易于管理。而nginx的字符串结构体，仅有一个指针指向字符串和一个保存字符串长度的整型变量，这个字符串在分配之后不可变，那么要分配可变字符串呢，首先使用内存池来分配内存，然后使用类sprintf的函数预先格式化好字符串，随后的事情就交由这个结构体管理。

说了这么多，我想说的是，这几个结构体的设计，将它们的功能尽可能的最小化，正交化：内存池只管内存，与特定的数据结构绑定，生死与它一起；字符串只关心自己的内容，一旦分配不可改变，也不关心内存分配问题。

而对比起来，我自己做的qnode项目，字符串相关的操作就做了以上的所有事情：内存分配，字符串内容管理，支持可变的API，等等等等。太多太多了。

以上，可以解释为什么需要在应用层设计一个内存池，和如何设计数据结构及相关API的好范例。

—————— 这里是分割线 ———————–
补充一下，我不认为nginx的内存池方案是可以应对任何业务的解决方案，正如nginx的很多做法也不是能应付所有业务的做法一样。理由是，nginx把内存管理的粒度细化到连接一层，原因是对于大部分HTTP请求而言，都是短连接，所以里面大可从内存池中分配，而等到连接关闭整体回收。nginx的内存池并没有分配之后返还的机制，只有连接关闭一起回收。那么，假如是处理长连接的请求，显然这样的做法会一直累加下去。所以，本身nginx内存管理与连接相关这个思路是没错，但是如果考虑到业务需要长连接那么还需要细化回收机制。