C++内存管理变革(2)：最袖珍的垃圾回收器

空间性能分析

我们知道，一般内存管理器为了将用户申请的内存块管理起来，除了用户需要的cb字节内存外，通常额外还提供一个内存块的头结构，通过这个头结构将内存串连成为一个链表。一般来讲，这个头结构至少有两项（可能还不止），示意如下：

struct MemHeader
{
MemHeader* pPrev;
size_t cb;
};

仍然假设平均Alloc一次的内存为32字节。则一次malloc分配过程，就会浪费8/32 = 25%的内存。并且由于大量的小对象存在，整个内存中的碎片（指那些自由但无法被使用的内存）将特别严重。

而AutoFreeAlloc的Alloc没有如何额外开销。整个AutoFreeAlloc，只有在将_MemBlock串为链表的有一个额外的pPrev指针，加上_MemBlock是malloc出来的，有额外的8字节开销。总计浪费(4+8)/2048 = 0.6%的内存，几乎可以忽略不计。

后记

AutoFreeAlloc于2004-5-21开发，只有100行的代码量。但是，这个组件获得了空前的成功，它的应用范围逐步扩大，超过了我最初实现这个组件时的预计。

我渐渐冷静下来，考虑这其中蕴涵的道理。我逐步领会到了，它的成功之处，不是它在时间、空间性能的高效，而是在于它帮助C++程序员解决了最大的难题——内存管理。虽然，这个解决方案并不是完整的。

AutoFreeAlloc是一个切入点，从它身上，让我明白了C++的new/delete的不合理；STL引入的allocator是一个切入点，从它身上，让我明白了内存管理有很强的区域性，在不同的区域（局部过程）中对allocator的需求却又不尽相同。

我们前文也提到了一个例子：一个文档打开，编辑，直到文档被最终关闭，这个完成算不算局部过程呢？在AutoFreeAlloc解决的问题域来看，显然我们无法认为它是一个局部过程。但是，从其他allocator角度来讲，是否就有可能把它作为一个局部过程了呢？

正是考虑到AutoFreeAlloc的缺陷，我们需要一个功能更强的垃圾回收器。这就是我们下一次需要讨论的组件了。

最后，仍然需要明确的一点时。我们很难也不需要实现一个象Java、C#那样的垃圾回收器。提供一个具备特定的内存管理能力的allocator才是正道。

[1] 请参考boost官方网站http://www.boost.org/。

[2] mempool技术是一个很成熟的内存管理技术，被sgi-stl、boost等C++库实现者采用。

[3] 真正是否要把一个过程定义为局部过程，完全取决于设计者本身。例如，一个文档打开，编辑，直到文档被最终关闭，这个完成算不算局部过程呢？在大部分情况下我们认为它不是一个局部过程，但是下回我们将专门讨论是否有可能，以及应该如何将它作为一个局部过程。

[4] 那些提供了垃圾回收器的语言的使用者，显然也有应用了垃圾回收器的烦恼。例如C#在调用非管制代码（如调用Win32 api）时，这些问题变得突出，一个疏忽就留下潜在隐患。这与C/C++程序员遗憾语言没有垃圾回收器的感觉类似。

[5] 当前的_MemBlock的自由内存很可能还是有的，但是不足cb字节。此时我们说这里有内存碎片（memory piece）：这些碎片尽管没有人使用，但是我们把它弃而不用。

附加说明：

本文所描述的AutoFreeAlloc组件，完整代码可在WINX库(http://sourceforge.net/projects/winx)中找到。你也可以通过以下链接在线浏览：

AutoFreeAlloc完整源代码：http://winx.cvs.sourceforge.net/winx/stdext/include/stdext/memory/AutoFreeAlloc.h?view=markup

另外， 这篇文章写的时间较早，其规格虽然与现在的AutoFreeAlloc一样，但成员函数名改了：

Alloc -> allocate

Clear -> clear

之所以这样，是因为AutoFreeAlloc被纳入stdext库（这个库可独立于winx界面库，是winx界面库的基础）。stdext库的命名风格尽量与STL的命名习惯一致。