剖析内存的一点补充

内存就好像稀缺资源，永远也没法满足需求，只能对其进行高效而合理的配置和使用。要用好内存好的管理方法必不可少，现在比较广泛的方法是内存池。不同的内存池管理方法的实现各有其特点，SGI allocator分配器也不例外。SGI分配器没有适时调用原始的free释放一些blocks，侯捷老师对此说法是“这是 SGI allocator 值得加强的部分”。但是现有SGI分配器代码对此能不能加强？有没有必要加强？真是值得探讨。

      研读SGI分配器代码得知，SGI分配器的实现已决定了它很难做到适时调用原始的free释放一些blocks。

假设现在是初次进入系统，要申请20字节的内存。SGI分配器会用原始的malloc分配一块连续的内存，一半作为下标为”#2”的内存链表，一半被用于start_free、end_free所管理的空闲内存。空闲的字节数为20 * 24 = 480字节，根据chunk_alloc的代码这480字节有可能被用于下标为”#0”、 ”#1”、 ”#3”、 ”#4”、 ”#5”……所指向的chunk链表。

由此可见，一次malloc出来的连续内存可能被分割成如杯子掉地般零碎。零碎也就罢了，最主要的是没有对这些零碎的内存使用与否作个标记，这也就本质地决定了分配器的没有办法做到适时调用原始的free释放一些内存。因此如果SGI分配器要实现适时地释放一些内存，必需对原来的分配器代码的分配回收算法做大量的修改，甚至是重写。

SGI分配器不能做到适时释放一些内存的两个主要现象：

1. 一次malloc的连续内存被分割成四分五裂，也本质上决定了一个chunk链表的"杂乱"，即下标为"#x"的一个chunk链表所链接的内存块可能来自不同的malloc。这种"杂乱"对适时原始free来说是一种不可管理，无法free。

2. 一次malloc的连续空闲内存要再分配给下标为"#x"的chunk链表，被再分配的内存都"无法回收"。

    从上面两个现象可得知，要做到适时释放一些内存主要是对一次malloc的连续内存的再分配要能回收，"重组"成一块连续的空闲内存才能调用原始的free释放。为了达到适时释放的目的，增加额外管理信息是必要的。增加额外的管理信息也就浪费了内存，而在SGI的分配器中的内存利用率是"100%"的。同时增加额外的管理信息进行管理，也相应带来管理上的复杂。

    SGI分配器对内存有预取功能，一次malloc的连续内存可能被用于多次下标为"#x"的请求。如果修改了，这个预取功能还能不能保留，如果不能保留时间效率也就不如原来的好(当然这个预取也会"浪费"一点空间)。

    从时间效率和空间效率看，要SGI分配器改为能适时释放一些内存的必要性真是值得商榷，还是让实践、需要去决定吧。

    SGI分配器有个地方确实不足的是对多线程使用内存没有很好的优化,只是为多线程的使用实现了另外一个版本pthread_alloc。单从内存管理方面看，个人认为这种多线程的内存管理方法不如GLIB库实现的内存管理方法好。