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

核心提示：自动析构过程我们知道，C++以及其他面向对象语言为对象引入了构造、析构过程，C++内存管理变革(2)：最袖珍的垃圾回收器(5)，这是一个了不起的发明，因为只有这样，为其提供一次相应的Free过程，★ 结论：AutoFreeAlloc在时间上的性能，才能够保证对象从一开始产生以来（刚new出来），到对象销毁这整个过程

自动析构过程

我们知道，C++以及其他面向对象语言为对象引入了构造、析构过程。这是一个了不起的发明。因为只有这样，才能够保证对象从一开始产生以来（刚new出来），到对象销毁这整个过程，它的数据都处于完备状态，是自洽的。

我们知道，C++以及其他面向对象语言为对象引入了构造、析构过程。这是一个了不起的发明。因为只有这样，才能够保证对象从一开始产生以来（刚new出来），到对象销毁这整个过程，它的数据都处于完备状态，是自洽的。

由于垃圾回收器负责对象的回收，它自然不止需要关注对象申请的内存的释放，同时也需要保证，在对象销毁之前它的析构过程被调用。上文我们为了关注内存管理过程，把自动析构过程需要的代码均去除了。为了支持自动析构，AutoFreeAlloc类增加了以下成员：

class AutoFreeAlloc
{
struct _DestroyNode
{
_DestroyNode* pPrev;
FnDestructor fnDestroy;
};
_DestroyNode* m_destroyChain;
};

如果一个类存在析构，则它需要在Alloc内存的同时指定析构函数。代码如下：

void* AutoFreeAlloc::Alloc(size_t cb, FnDestructor fn)
{
_DestroyNode* pNode = (_DestroyNode*)Alloc(sizeof(_DestroyNode) + cb);
pNode->fnDestroy = fn;
pNode->pPrev = m_destroyChain;
m_destroyChain = pNode;
return pNode + 1;
}

只要通过该Alloc函数申请的内存，我们在Clear中就可以调用相应的析构。当然，Clear函数需要补充自动析构相关的代码：

void AutoFreeAlloc::Clear()
{
while (m_destroyChain)
{
m_destroyChain->fnDestroy(m_destroyChain + 1);
m_destroyChain = m_destroyChain->pPrev;
}
// 以下是原先正常的内存释放过程…
}

时间性能分析

void* AutoFreeAlloc::Alloc(size_t cb);

OOP技术带来一个内存上的问题是，对象粒度越来越细了，对象基本上都是小对象。这就对内存管理的性能提出了很高的要求。

如果我们以对象大小平均为32字节计算的话，每2048/32 = 64操作中，只有一次操作满足m_end – m_begin < cb的条件。也就是说，在通常情况（63/64 = 98.4%的概率）下，Alloc操作只需要一个减法操作就完成内存分配。

我说这是世界上最快速的内存分配算法，也许你对此仍然抱有怀疑态度。但是可以肯定的一点是，要突破它的性能极限我觉得已经很难很难了。

void AutoFreeAlloc::Clear();

一般内存管理器通常一次内存分配操作就需调用相应的一次Free操作。但是AutoFreeAlloc不针对每一个Alloc进行释放，而是针对每一个_MemBlock。仍假设对象平均大小为32字节的话，也就是相当于把64次Alloc操作合并，为其提供一次相应的Free过程。

★ 结论：AutoFreeAlloc在时间上的性能，大约比普通的malloc/free的快64倍。