计算密集型的应用一定要关注小内存

      曾经开发计算密集型程序的时候，用内存泄漏工具检测程序无内存泄漏问题，但程序运行的时候内存还是越来越多，当时一开始不明白怎么回事，后来经过大量实验 和探索，发现是小内存在作怪，原来应用程序与os之间还存在着对内存的中间管理，也就是glibc fastbins，大致解释如下：

      一般的情况是, 程序在运行时会经常需要分配和释放一些较小的内存空间. 当 allocator 合并了相邻的几个小的 chunk 之后, 也许马上就会有另一个小块内存的请求,这样 allocator 又需要从大的空闲内存中分出一块出来, 这样无疑是比较低效的, 故而, ptmalloc 中在分配过程中引入了 fastbins, 不大于 max_fast (72 bytes) 的 chunk 被 free 后, 首先会被放到 fastbins 中, fastbins 中的 chunk 并不改变它的使用标志p. 这样也就无法将它们合并, 当需要给用户分配的 chunk 小于或等于 max_fast 时, ptmalloc 首先会在 fastbins 中查找相应的空闲块(具体的分配算法请参考第7节), 然后才会去查找 bins 中的空间 chunk. 在某个特定的时候, ptmalloc 会遍历 fastbins 中的 chunk, 将相邻的空闲 chunk 进行合并, 并将合并后的 chunk 放到 bins 中去.当分配单元为68时,不释放内存,但大于68时,就释放内存

       为了避免小内存问题，后来采用了分配大内存（当然也可以采用内存池），然后逐步消化的方法，就没有再出现上面古怪的问题。