C++内存管理变革(3)：另类内存管理

核心提示：只读DOM模型（或允许少量修改）的建立在《文本分析的三种典型设计模式》一文中我推荐大家使用DOM模型去进行文件操作，并且通常情况下，C++内存管理变革(3)：另类内存管理(2)，这个DOM模型是只读DOM模型（或允许少量修改），对于只读DOM模型，可以考虑象Java的GC那样，使用两个AutoFreeAlloc，使用A

只读DOM模型（或允许少量修改）的建立

在《文本分析的三种典型设计模式》一文中我推荐大家使用DOM模型去进行文件操作。并且通常情况下，这个DOM模型是只读DOM模型（或允许少量修改）。

对于只读DOM模型，使用AutoFreeAlloc是极其方便的。整个DOM树涉及的内存统一由同一个AutoFreeAlloc实例进行分配。大体如下：

class Document;
class ObjectA
{
private:
Document* m_doc;
SubObject* m_c;

public:
ObjectA(Document* doc) : m_doc(doc) {
m_c = STD_NEW(doc->alloc, SubObject);
}

* getC() {
return m_c;
}
};

class Document
{
public:
AutoFreeAlloc alloc;

private:
ObjectA* m_a;
ObjectB* m_b;

public:
ObjectA* getA() {
if (m_a == NULL)
m_a = STD_NEW(alloc, ObjectA)(this);
return m_a;
}
};

通过这种方式创建的DOM模型，只要你删除了Document对象，整个DOM树自然就被删除了。你根本不需要担心其中有任何内存泄漏的可能。

另类内存管理的观念

通过以上内容，我试图向大家阐述的一个观点是：

有了AutoFreeAlloc后，C++程序员也可以象GC语言的程序员一样大胆new而不需要顾忌什么时候delete。

展开来讲，可以有以下结论：

如果你程序的空间复杂度为O(1)，那么只new不delete是没有问题的。

如果你程序的空间复杂度为O(n)，并且是简单的n*O(1)，那么可以用AutoFreeAlloc简化内存管理。

如果你程序的空间复杂度为O(t)，其中t是程序运行时间，并且你不能确定程序执行的总时间，那么AutoFreeAlloc并不直接适合你。比较典型的例子是Word、Excel等文档编辑类的程序。

用AutoFreeAlloc实现通用型的GC

AutoFreeAlloc对内存管理的环境进行了简化，这种简化环境是常见的。在此环境下，C++程序员获得了无可比拟的性能优势。当然，在一般情形下，AutoFreeAlloc并不适用。

那么，一个通用的半自动GC环境在C++是否可能？《C++内存管理变革》系列的核心就是要告诉你：当然可以。并且，我们推荐C++程序员使用半自动的GC，而不是Java/C# 中的那种GC。

通用的半自动GC环境可以有很多种建立方式。这里我们简单聊一下如何使用AutoFreeAlloc去建立。

我们知道，使用AutoFreeAlloc，将导致程序随着时间推移，逐步地吃掉可用的内存。假设现在已经到达我们设置的临界点，我们需要开始gc。整个过程和Java等语言的gc其实完全类似：通过一个根对象（Object* root），获得所有活动着的对象（Active Objects），将它们复制到一个新的AutoFreeAlloc中：

Object* gc(AutoFreeAlloc& oldAlloc, Object* root, AutoFreeAlloc& newAlloc)
{
Object* root2 = root->clone(newAlloc);
oldAlloc.clear();
return root2;
}

如果C++象Java/C#那样有足够丰富的元信息，那么Object::clone过程就可以象Java/C# 等语言那样自动完成。这些元信息对于GC过程的用处无非在于，我们可以遍历整个活动对象的集合，然后把这些活动对象复制一份。没有复制过来的对象自然而然就被丢弃了。

GC的原理就是这么简单。没有元信息也没关系，只要我们要求每个由GC托管的对象支持clone函数，一切就ok了。对于一个复杂程序，要求每个对象提供clone函数不见得是什么过分的要求，clone函数也不只有gc过程才需要，很多对象在设计上天然就需要clone。

补充说明

关于全局AutoFreeAlloc变量

我个人非常不推荐使用全局变量（除非是常量：不一定用const修饰，指的是经过一定初始化步骤后就不在修改的变量）。上面只是对于小型的单线程程序偷懒才这样做。

关于用AutoFreeAlloc实现通用型的GC

请注意我没有讨论过于细节的东西。如果你决定选择这种做法，请仔细推敲细节。可以预见的一些细节有：

AutoFreeAlloc与线程模型（ThreadModel）。AutoFreeAlloc关注点在于快，它通常不涉及跨线程问题。但是如果要作为通用型的GC，这一点不能不考虑。为了性能，推荐每个线程独立管理内存，而不要使用互斥体。

性能优化。可以考虑象Java的GC那样，使用两个AutoFreeAlloc，把对象划分为年轻代和年老代。