（转）C++内存管理

我们给auto_vect提供了标准的begin和end方法来找回iterator：

class auto_vector { public: typedef auto_iterator<T> iterator; iterator begin () { return _arr; } iterator end () { return _arr + _end; } };

　　你也许会问我们是否要利用资源管理重新实现每一个标准的容器？幸运的是，不;事实是strong vector解决了大部分所有权的需求。当你把你的对象都安全的放置到一个strong vector中，你可以用所有其它的容器来重新安排（weak）pointer。

设想，例如，你需要对一些动态分配的对象排序的时候。你将它们的指针保存到一个strong vector中。然后你用一个标准的vector来保存从strong vector中获得的weak指针。你可以用标准的算法对这个vector进行排序。这种中介vector叫做permutation vector。相似的，你也可以用标准的maps, priority queues, heaps, hash tables等等。

1.2.8 Code Inspection

　　如果你严格遵照资源管理的条款，你就不会再资源泄露或者两次删除的地方遇到麻烦。你也降低了访问野指针的几率。同样的，遵循原有的规则，用delete删除用new申请的德指针，不要两次删除一个指针。你也不会遇到麻烦。但是，那个是更好的注意呢？

　　这两个方法有一个很大的不同点。就是和寻找传统方法的bug相比，找到违反资源管理的规定要容易的多。后者仅需要一个代码检测或者一个运行测试，而前者则在代码中隐藏得很深，并需要很深的检查。

　　设想你要做一段传统的代码的内存泄露检查。第一件事，你要做的就是grep所有在代码中出现的new，你需要找出被分配空间地指针都作了什么。你需要确定导致删除这个指针的所有的执行路径。你需要检查break语句，过程返回，异常。原有的指针可能赋给另一个指针，你对这个指针也要做相同的事。

　　相比之下，对于一段用资源管理技术实现的代码。你也用grep检查所有的new，但是这次你只需要检查邻近的调用：

　　● 这是一个直接的Strong Pointer转换，还是我们在一个构造函数的函数体中？

　　● 调用的返回知是否立即保存到对象中，构造函数中是否有可以产生异常的代码。？

　　● 如果这样的话析构函数中时候有delete?

　　下一步，你需要用grep查找所有的release方法，并实施相同的检查。

　　不同点是需要检查、理解单个执行路径和只需要做一些本地的检验。这难道不是提醒你非结构化的和结构化的程序设计的不同吗？原理上，你可以认为你可以应付goto，并且跟踪所有的可能分支。另一方面，你可以将你的怀疑本地化为一段代码。本地化在两种情况下都是关键所在。

　　在资源管理中的错误模式也比较容易调试。最常见的bug是试图访问一个释放过的strong pointer。这将导致一个错误，并且很容易跟踪。

1.2.9 共享的所有权

　　为每一个程序中的资源都找出或者指定一个所有者是一件很容易的事情吗？答案是出乎意料的，是！如果你发现了一些问题，这可能说明你的设计上存在问题。还有另一种情况就是共享所有权是最好的甚至是唯一的选择。

　　共享的责任分配给被共享的对象和它的客户（client）。一个共享资源必须为它的所有者保持一个引用计数。另一方面，所有者再释放资源的时候必须通报共享对象。最后一个释放资源的需要在最后负责free的工作。

　　最简单的共享的实现是共享对象继承引用计数的类RefCounted：

class RefCounted { public: RefCounted () : _count (1) {} int GetRefCount () const { return _count; } void IncRefCount () { _count++; } int DecRefCount () { return --_count; } private int _count; };

　　按照资源管理，一个引用计数是一种资源。如果你遵守它，你需要释放它。当你意识到这一事实的时候，剩下的就变得简单了。简单的遵循规则--再构造函数中获得引用计数，在析构函数中释放。甚至有一个RefCounted的smart pointer等价物：

template <class T> class RefPtr { public: RefPtr (T * p) : _p (p) {} RefPtr (RefPtr<T> & p) { _p = p._p; _p->IncRefCount (); } ~RefPtr () { if (_p->DecRefCount () == 0) delete _p; } private T * _p; };

　　注意模板中的T不比成为RefCounted的后代，但是它必须有IncRefCount和DecRefCount的方法。当然，一个便于使用的RefPtr需要有一个重载的指针访问操作符。在RefPtr中加入转换语义学（transfer semantics）是读者的工作。

1.2.10 所有权网络

　　链表是资源管理分析中的一个很有意思的例子。如果你选择表成为链(link)的所有者的话，你会陷入实现递归的所有权。每一个link都是它的继承者的所有者，并且，相应的，余下的链表的所有者。下面是用smart pointer实现的一个表单元：

class Link { // ... private auto_ptr<Link> _next; }; 　　最好的方法是，将连接控制封装到一个弄构进行资源转换的类中。 　　对于双链表呢？安全的做法是指明一个方向，如forward: class DoubleLink { // ... private DoubleLink *_prev; auto_ptr<DoubleLink> _next; };

　　注意不要创建环形链表。

　　这给我们带来了另外一个有趣的问题--资源管理可以处理环形的所有权吗？它可以，用一个mark-and-sweep的算法。这里是实现这种方法的一个例子：

template<class T> class CyclPtr { public: CyclPtr (T * p) :_p (p), _isBeingDeleted (false) {} ~CyclPtr () { _isBeingDeleted = true; if (!_p->IsBeingDeleted ()) delete _p; } void Set (T * p) { _p = p; } bool IsBeingDeleted () const { return _isBeingDeleted; } private T * _p; bool _isBeingDeleted; };

　　注意我们需要用class T来实现方法IsBeingDeleted，就像从CyclPtr继承。对特殊的所有权网络普通化是十分直接的。

　　将原有代码转换为资源管理代码

如果你是一个经验丰富的程序员，你一定会知道找资源的bug是一件浪费时间的痛苦的经历。我不必说服你和你的团队花费一点时间来熟悉资源管理是十分值得的。你可以立即开始用这个方法，无论你是在开始一个新项目或者是在一个项目的中期。转换不必立即全部完成。下面是步骤。

（1）       首先，在你的工程中建立基本的Strong Pointer。然后通过查找代码中的new来开始封装裸指针。

（2）       最先封装的是在过程中定义的临时指针。简单的将它们替换为auto_ptr并且删除相应的delete。如果一个指针在过程中没有被删除而是被返回，用auto_ptr替换并在返回前调用release方法。在你做第二次传递的时候，你需要处理对release的调用。注意，即使是在这点，你的代码也可能更加"精力充沛"--你会移出代码中潜在的资源泄漏问题。

（3）       下面是指向资源的裸指针。确保它们被独立的封装到auto_ptr中，或者在构造函数中分配在析构函数中释放。如果你有传递所有权的行为的话，需要调用release方法。如果你有容器所有对象，用Strong Pointers重新实现它们。

（4）       接下来，找到所有对release的方法调用并且尽力清除所有，如果一个release调用返回一个指针，将它修改传值返回一个auto_ptr。

（5）       重复着一过程，直到最后所有new和release的调用都在构造函数或者资源转换的时候发生。这样，你在你的代码中处理了资源泄漏的问题。对其他资源进行相似的操作。

（6）       你会发现资源管理清除了许多错误和异常处理带来的复杂性。不仅仅你的代码会变得精力充沛，它也会变得简单并容易维护。

2 内存泄漏

2.1 C++中动态内存分配引发问题的解决方案

假设我们要开发一个String类，它可以方便地处理字符串数据。我们可以在类中声明一个数组，考虑到有时候字符串极长，我们可以把数组大小设为200，但一般的情况下又不需要这么多的空间，这样是浪费了内存。对了，我们可以使用new操作符，这样是十分灵活的，但在类中就会出现许多意想不到的问题，本文就是针对这一现象而写的。现在，我们先来开发一个String类，但它是一个不完善的类。的确，我们要刻意地使它出现各种各样的问题，这样才好对症下药。好了，我们开始吧！

/* String.h */ #ifndef STRING_H_ #define STRING_H_ class String { private: char * str; //存储数据 int len; //字符串长度 public: String(const char * s); //构造函数 String(); // 默认构造函数 ~String(); // 析构函数 friend ostream & operator＜＜(ostream & os,const String& st); }; #endif /*String.cpp*/ #include ＜iostream＞ #include ＜cstring＞ #include "String.h" using namespace std; String::String(const char * s) { len = strlen(s); str = new char[len + 1]; strcpy(str, s); }//拷贝数据 String::String() { len =0; str = new char[len+1]; str[0]='"0'; } String::~String() { cout＜＜"这个字符串将被删除："＜＜str＜＜'"n';//为了方便观察结果，特留此行代码。 delete [] str; } ostream & operator＜＜(ostream & os, const String & st) { os ＜＜ st.str; return os; } /*test_right.cpp*/ #include ＜iostream＞ #include ＜stdlib.h＞ #include "String.h" using namespace std; int main() { String temp("天极网"); cout＜＜temp＜＜'"n'; system("PAUSE"); return 0; }

　　

　　运行结果：

天极网 　　请按任意键继续. . .

　　大家可以看到，以上程序十分正确，而且也是十分有用的。可是，我们不能被表面现象所迷惑！下面，请大家用test_String.cpp文件替换test_right.cpp文件进行编译，看看结果。有的编译器可能就是根本不能进行编译！

test_String.cpp:

#include ＜iostream＞ #include ＜stdlib.h＞ #include "String.h" using namespace std; void show_right(const String&); void show_String(const String);//注意，参数非引用，而是按值传递。 int main() { String test1("第一个范例。"); String test2("第二个范例。"); String test3("第三个范例。"); String test4("第四个范例。"); cout＜＜"下面分别输入三个范例："n"; cout＜＜test1＜＜endl; cout＜＜test2＜＜endl; cout＜＜test3＜＜endl; String* String1=new String(test1); cout＜＜*String1＜＜endl; delete String1; cout＜＜test1＜＜endl; //在Dev-cpp上没有任何反应。 cout＜＜"使用正确的函数："＜＜endl; show_right(test2); cout＜＜test2＜＜endl; cout＜＜"使用错误的函数："＜＜endl; show_String(test2); cout＜＜test2＜＜endl; //这一段代码出现严重的错误！ String String2(test3); cout＜＜"String2: "＜＜String2＜＜endl; String String3; String3=test4; cout＜＜"String3: "＜＜String3＜＜endl; cout＜＜"下面，程序结束，析构函数将被调用。"＜＜endl; return 0; } void show_right(const String& a) { cout＜＜a＜＜endl; } void show_String(const String a) { cout＜＜a＜＜endl; }

　　运行结果：

下面分别输入三个范例： 　　第一个范例。 　　第二个范例。 　　第三个范例。 　　第一个范例。 　　这个字符串将被删除：第一个范例。 　　使用正确的函数： 　　 　　第二个范例。 　　第二个范例。 　　使用错误的函数： 　　第二个范例。 　　这个字符串将被删除：第二个范例。 　　这个字符串将被删除：?= 　　?= 　　String2: 第三个范例。 　　String3: 第四个范例。 　　下面，程序结束，析构函数将被调用。 　　这个字符串将被删除：第四个范例。 　　这个字符串将被删除：第三个范例。 　　这个字符串将被删除：?= 　　这个字符串将被删除：x = 　　这个字符串将被删除：?= 　　这个字符串将被删除：

现在，请大家自己试试运行结果，或许会更加惨不忍睹呢！下面，我为大家一一分析原因。

首先，大家要知道，C＋＋类有以下这些极为重要的函数：

一：复制构造函数。

二：赋值函数。

我们先来讲复制构造函数。什么是复制构造函数呢？比如，我们可以写下这样的代码：String test1(test2);这是进行初始化。我们知道，初始化对象要用构造函数。可这儿呢？按理说，应该有声明为这样的构造函数：String(const String &);可是，我们并没有定义这个构造函数呀？答案是，C＋＋提供了默认的复制构造函数，问题也就出在这儿。

（1）：什么时候会调用复制构造函数呢？（以String类为例。）

　　在我们提供这样的代码：String test1(test2)时，它会被调用；当函数的参数列表为按值传递，也就是没有用引用和指针作为类型时，如：void show_String(const String)，它会被调用。其实，还有一些情况，但在这儿就不列举了。

（2）：它是什么样的函数。

它的作用就是把两个类进行复制。拿String类为例，C＋＋提供的默认复制构造函数是这样的：

String(const String& a) { str=a.str; len=a.len; }

在平时，这样并不会有任何的问题出现，但我们用了new操作符，涉及到了动态内存分配，我们就不得不谈谈浅复制和深复制了。以上的函数就是实行的浅复制，它只是复制了指针，而并没有复制指针指向的数据，可谓一点儿用也没有。打个比方吧！就像一个朋友让你把一个程序通过网络发给他，而你大大咧咧地把快捷方式发给了他，有什么用处呢？我们来具体谈谈：

假如，A对象中存储了这样的字符串：“C＋＋”。它的地址为2000。现在，我们把A对象赋给B对象：String B=A。现在，A和B对象的str指针均指向2000地址。看似可以使用，但如果B对象的析构函数被调用时，则地址2000处的字符串“C＋＋”已经被从内存中抹去，而A对象仍然指向地址2000。这时，如果我们写下这样的代码：cout＜＜A＜＜endl;或是等待程序结束，A对象的析构函数被调用时，A对象的数据能否显示出来呢？只会是乱码。而且，程序还会这样做：连续对地址2000处使用两次delete操作符，这样的后果是十分严重的！

本例中，有这样的代码：

String* String1=new String(test1); cout＜＜*String1＜＜endl; delete String1;

　　假设test1中str指向的地址为2000,而String中str指针同样指向地址2000，我们删除了2000处的数据，而test1对象呢？已经被破坏了。大家从运行结果上可以看到，我们使用cout＜＜test1时，一点反应也没有。而在test1的析构函数被调用时，显示是这样：“这个字符串将被删除：”。

再看看这段代码：

cout＜＜"使用错误的函数："＜＜endl; show_String(test2); cout＜＜test2＜＜endl;//这一段代码出现严重的错误！

show_String函数的参数列表void show_String(const String a)是按值传递的，所以，我们相当于执行了这样的代码：String a=test2;函数执行完毕，由于生存周期的缘故，对象a被析构函数删除，我们马上就可以看到错误的显示结果了：这个字符串将被删除：?=。当然，test2也被破坏了。解决的办法很简单，当然是手工定义一个复制构造函数喽！人力可以胜天！

String::String(const String& a) { len=a.len; str=new char(len+1); strcpy(str,a.str); }

　　我们执行的是深复制。这个函数的功能是这样的：假设对象A中的str指针指向地址2000，内容为“I am a C++ Boy!”。我们执行代码String B=A时，我们先开辟出一块内存，假设为3000。我们用strcpy函数将地址2000的内容拷贝到地址3000中，再将对象B的str指针指向地址3000。这样，就互不干扰了。

大家把这个函数加入程序中，问题就解决了大半，但还没有完全解决，问题在赋值函数上。我们的程序中有这样的段代码：

String String3; String3=test4;

　　经过我前面的讲解，大家应该也会对这段代码进行寻根摸底：凭什么可以这样做：String3=test4？？？原因是，C＋＋为了用户的方便，提供的这样的一个操作符重载函数：operator=。所以，我们可以这样做。大家应该猜得到，它同样是执行了浅复制，出了同样的毛病。比如，执行了这段代码后，析构函数开始大展神威^_^。由于这些变量是后进先出的，所以最后的String3变量先被删除：这个字符串将被删除：第四个范例。很正常。最后，删除到test4的时候，问题来了：这个字符串将被删除：?=。原因我不用赘述了，只是这个赋值函数怎么写，还有一点儿学问呢！大家请看：

平时，我们可以写这样的代码：x=y=z。（均为整型变量。）而在类对象中，我们同样要这样，因为这很方便。而对象A=B=C就是A.operator=(B.operator=(c))。而这个operator=函数的参数列表应该是：const String& a，所以，大家不难推出，要实现这样的功能，返回值也要是String&，这样才能实现A＝B＝C。我们先来写写看：

String& String::operator=(const String& a) { delete [] str;//先删除自身的数据 len=a.len; str=new char[len+1]; strcpy(str,a.str);//此三行为进行拷贝 return *this;//返回自身的引用 }

是不是这样就行了呢？我们假如写出了这种代码：A=A，那么大家看看，岂不是把A对象的数据给删除了吗？这样可谓引发一系列的错误。所以，我们还要检查是否为自身赋值。只比较两对象的数据是不行了，因为两个对象的数据很有可能相同。我们应该比较地址。以下是完好的赋值函数：

String& String::operator=(const String& a) { if(this==&a) return *this; delete [] str; len=a.len; str=new char[len+1]; strcpy(str,a.str); return *this; }

把这些代码加入程序，问题就完全解决，下面是运行结果：

下面分别输入三个范例： 　　第一个范例 　　第二个范例 　　第三个范例 　　第一个范例 　　这个字符串将被删除：第一个范例。 　　第一个范例 　　　使用正确的函数： 　　第二个范例。 　　第二个范例。 　　　使用错误的函数： 　　第二个范例。 　　这个字符串将被删除：第二个范例。 　　第二个范例。 　　String2: 第三个范例。 　　String3: 第四个范例。 　　下面，程序结束，析构函数将被调用。 　　这个字符串将被删除：第四个范例。 　　这个字符串将被删除：第三个范例。 　　这个字符串将被删除：第四个范例。 　　这个字符串将被删除：第三个范例。 　　这个字符串将被删除：第二个范例。 　　这个字符串将被删除：第一个范例。

2.2 如何对付内存泄漏？

写出那些不会导致任何内存泄漏的代码。很明显，当你的代码中到处充满了new 操作、delete操作和指针运算的话，你将会在某个地方搞晕了头，导致内存泄漏，指针引用错误，以及诸如此类的问题。这和你如何小心地对待内存分配工作其实完全没有关系：代码的复杂性最终总是会超过你能够付出的时间和努力。于是随后产生了一些成功的技巧，它们依赖于将内存分配（allocations）与重新分配（deallocation）工作隐藏在易于管理的类型之后。标准容器（standard containers）是一个优秀的例子。它们不是通过你而是自己为元素管理内存，从而避免了产生糟糕的结果。想象一下，没有string和vector的帮助，写出这个：

#include<vector> #include<string> #include<iostream> #include<algorithm> using namespace std; int main() // small program messing around with strings { 　cout << "enter some whitespace-separated words:"n"; 　vector<string> v; 　string s; 　while (cin>>s) v.push_back(s); 　sort(v.begin(),v.end()); 　string cat; 　typedef vector<string>::const_iterator Iter; 　for (Iter p = v.begin(); p!=v.end(); ++p) cat += *p+"+"; 　cout << cat << ’"n’; }

　　你有多少机会在第一次就得到正确的结果？你又怎么知道你没有导致内存泄漏呢？

　　注意，没有出现显式的内存管理，宏，造型，溢出检查，显式的长度限制，以及指针。通过使用函数对象和标准算法（standard algorithm），我可以避免使用指针——例如使用迭代子（iterator），不过对于一个这么小的程序来说有点小题大作了。

　　这些技巧并不完美，要系统化地使用它们也并不总是那么容易。但是，应用它们产生了惊人的差异，而且通过减少显式的内存分配与重新分配的次数，你甚至可以使余下的例子更加容易被跟踪。早在1981年，我就指出，通过将我必须显式地跟踪的对象的数量从几万个减少到几打，为了使程序正确运行而付出的努力从可怕的苦工，变成了应付一些可管理的对象，甚至更加简单了。

　　如果你的程序还没有包含将显式内存管理减少到最小限度的库，那么要让你程序完成和正确运行的话，最快的途径也许就是先建立一个这样的库。

　　模板和标准库实现了容器、资源句柄以及诸如此类的东西，更早的使用甚至在多年以前。异常的使用使之更加完善。

　　如果你实在不能将内存分配/重新分配的操作隐藏到你需要的对象中时，你可以使用资源句柄（resource handle），以将内存泄漏的可能性降至最低。这里有个例子：我需要通过一个函数，在空闲内存中建立一个对象并返回它。这时候可能忘记释放这个对象。毕竟，我们不能说，仅仅关注当这个指针要被释放的时候，谁将负责去做。使用资源句柄，这里用了标准库中的auto_ptr，使需要为之负责的地方变得明确了。

#include<memory> #include<iostream> using namespace std; struct S { 　S() { cout << "make an S"n"; } 　~S() { cout << "destroy an S"n"; } 　S(const S&) { cout << "copy initialize an S"n"; } 　S& operator=(const S&) { cout << "copy assign an S"n"; } }; S* f() { 　return new S; // 谁该负责释放这个S？ }; auto_ptr<S> g() { 　return auto_ptr<S>(new S); // 显式传递负责释放这个S } int main() { 　cout << "start main"n"; 　S* p = f(); 　cout << "after f() before g()"n"; 　// S* q = g(); // 将被编译器捕捉 　auto_ptr<S> q = g(); 　cout << "exit main"n"; 　// *p产生了内存泄漏 　// *q被自动释放 }

　　在更一般的意义上考虑资源，而不仅仅是内存。

如果在你的环境中不能系统地应用这些技巧（例如，你必须使用别的地方的代码，或者你的程序的另一部分简直是原始人类（译注：原文是Neanderthals，尼安德特人，旧石器时代广泛分布在欧洲的猿人）写的，如此等等），那么注意使用一个内存泄漏检测器作为开发过程的一部分，或者插入一个垃圾收集器（garbage collector）。

2.3浅谈C/C++内存泄漏及其检测工具

　　对于一个c/c++程序员来说，内存泄漏是一个常见的也是令人头疼的问题。已经有许多技术被研究出来以应对这个问题，比如Smart Pointer，Garbage Collection等。Smart Pointer技术比较成熟，STL中已经包含支持Smart Pointer的class，但是它的使用似乎并不广泛，而且它也不能解决所有的问题；Garbage Collection技术在Java中已经比较成熟，但是在c/c++领域的发展并不顺畅，虽然很早就有人思考在C++中也加入GC的支持。现实世界就是这样的，作为一个c/c++程序员，内存泄漏是你心中永远的痛。不过好在现在有许多工具能够帮助我们验证内存泄漏的存在，找出发生问题的代码。

2.3.1 内存泄漏的定义

一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。以下这段小程序演示了堆内存发生泄漏的情形：

void MyFunction(int nSize) { 　char* p= new char[nSize]; 　if( !GetStringFrom( p, nSize ) ){ 　　MessageBox(“Error”); 　　return; 　} 　…//using the string pointed by p; 　delete p; }

　　当函数GetStringFrom()返回零的时候，指针p指向的内存就不会被释放。这是一种常见的发生内存泄漏的情形。程序在入口处分配内存，在出口处释放内存，但是c函数可以在任何地方退出，所以一旦有某个出口处没有释放应该释放的内存，就会发生内存泄漏。

　　广义的说，内存泄漏不仅仅包含堆内存的泄漏，还包含系统资源的泄漏(resource leak)，比如核心态HANDLE，GDI Object，SOCKET， Interface等，从根本上说这些由操作系统分配的对象也消耗内存，如果这些对象发生泄漏最终也会导致内存的泄漏。而且，某些对象消耗的是核心态内存，这些对象严重泄漏时会导致整个操作系统不稳定。所以相比之下，系统资源的泄漏比堆内存的泄漏更为严重。

GDI Object的泄漏是一种常见的资源泄漏：

void CMyView::OnPaint( CDC* pDC ) { 　CBitmap bmp; 　CBitmap* pOldBmp; 　bmp.LoadBitmap(IDB_MYBMP); 　pOldBmp = pDC->SelectObject( &bmp ); 　… 　if( Something() ){ 　　return; 　} 　pDC->SelectObject( pOldBmp ); 　return; }

　　当函数Something()返回非零的时候，程序在退出前没有把pOldBmp选回pDC中，这会导致pOldBmp指向的HBITMAP对象发生泄漏。这个程序如果长时间的运行，可能会导致整个系统花屏。这种问题在Win9x下比较容易暴露出来，因为Win9x的GDI堆比Win2k或NT的要小很多。

2.3.2 内存泄漏的发生方式

　　以发生的方式来分类，内存泄漏可以分为4类：

　　1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。比如例二，如果Something()函数一直返回True，那么pOldBmp指向的HBITMAP对象总是发生泄漏。

　　2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。比如例二，如果Something()函数只有在特定环境下才返回True，那么pOldBmp指向的HBITMAP对象并不总是发生泄漏。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。

3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，但是因为这个类是一个Singleton，所以内存泄漏只会发生一次。另一个例子：

char* g_lpszFileName = NULL; void SetFileName( const char* lpcszFileName ) { 　if( g_lpszFileName ){ 　　free( g_lpszFileName ); 　} 　g_lpszFileName = strdup( lpcszFileName ); }

　　如果程序在结束的时候没有释放g_lpszFileName指向的字符串，那么，即使多次调用SetFileName()，总会有一块内存，而且仅有一块内存发生泄漏。

4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。举一个例子：

class Connection { 　public: 　　Connection( SOCKET s); 　　~Connection(); 　　… 　private: 　　SOCKET _socket; 　　… }; class ConnectionManager { 　public: 　　ConnectionManager(){} 　　~ConnectionManager(){ 　　　list::iterator it; 　　　for( it = _connlist.begin(); it != _connlist.end(); ++it ){ 　　　　delete （*it）; 　　　} 　　　_connlist.clear(); 　　} 　　void OnClientConnected( SOCKET s ){ 　　　Connection* p = new Connection(s); 　　　_connlist.push_back(p); 　　} 　　void OnClientDisconnected( Connection* pconn ){ 　　　_connlist.remove( pconn ); 　　　delete pconn; 　　} 　private: 　　list _connlist; };

　　假设在Client从Server端断开后，Server并没有呼叫OnClientDisconnected()函数，那么代表那次连接的Connection对象就不会被及时的删除（在Server程序退出的时候，所有Connection对象会在ConnectionManager的析构函数里被删除）。当不断的有连接建立、断开时隐式内存泄漏就发生了。

从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。

2.3.3 检测内存泄漏

　　检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住这两个函数，我们就能跟踪每一块内存的生命周期，比如，每当成功的分配一块内存后，就把它的指针加入一个全局的list中；每当释放一块内存，再把它的指针从list中删除。这样，当程序结束的时候，list中剩余的指针就是指向那些没有被释放的内存。这里只是简单的描述了检测内存泄漏的基本原理，详细的算法可以参见Steve Maguire的<<Writing Solid Code>>。

　　如果要检测堆内存的泄漏，那么需要截获住malloc/realloc/free和new/delete就可以了（其实new/delete最终也是用malloc/free的，所以只要截获前面一组即可）。对于其他的泄漏，可以采用类似的方法，截获住相应的分配和释放函数。比如，要检测BSTR的泄漏，就需要截获SysAllocString/SysFreeString；要检测HMENU的泄漏，就需要截获CreateMenu/ DestroyMenu。（有的资源的分配函数有多个，释放函数只有一个，比如，SysAllocStringLen也可以用来分配BSTR，这时就需要截获多个分配函数）

　　在Windows平台下，检测内存泄漏的工具常用的一般有三种，MS C-Runtime Library内建的检测功能；外挂式的检测工具，诸如，Purify，BoundsChecker等；利用Windows NT自带的Performance Monitor。这三种工具各有优缺点，MS C-Runtime Library虽然功能上较之外挂式的工具要弱，但是它是免费的；Performance Monitor虽然无法标示出发生问题的代码，但是它能检测出隐式的内存泄漏的存在，这是其他两类工具无能为力的地方。

　　以下我们详细讨论这三种检测工具：

2.3.3.1 VC下内存泄漏的检测方法

　　用MFC开发的应用程序，在DEBUG版模式下编译后，都会自动加入内存泄漏的检测代码。在程序结束后，如果发生了内存泄漏，在Debug窗口中会显示出所有发生泄漏的内存块的信息，以下两行显示了一块被泄漏的内存块的信息：

E:"TestMemLeak"TestDlg.cpp(70) : {59} normal block at 0x00881710, 200 bytes long.

Data: <abcdefghijklmnop> 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70

　　第一行显示该内存块由TestDlg.cpp文件，第70行代码分配，地址在0x00881710，大小为200字节，{59}是指调用内存分配函数的Request Order，关于它的详细信息可以参见MSDN中_CrtSetBreakAlloc()的帮助。第二行显示该内存块前16个字节的内容，尖括号内是以ASCII方式显示，接着的是以16进制方式显示。

　　一般大家都误以为这些内存泄漏的检测功能是由MFC提供的，其实不然。MFC只是封装和利用了MS C-Runtime Library的Debug Function。非MFC程序也可以利用MS C-Runtime Library的Debug Function加入内存泄漏的检测功能。MS C-Runtime Library在实现malloc/free，strdup等函数时已经内建了内存泄漏的检测功能。

注意观察一下由MFC Application Wizard生成的项目，在每一个cpp文件的头部都有这样一段宏定义：

#ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif

有了这样的定义，在编译DEBUG版时，出现在这个cpp文件中的所有new都被替换成DEBUG_NEW了。那么DEBUG_NEW是什么呢？DEBUG_NEW也是一个宏，以下摘自afx.h，1632行

#define DEBUG_NEW new(THIS_FILE, __LINE__)

所以如果有这样一行代码：

char* p = new char[200];

经过宏替换就变成了：

char* p = new( THIS_FILE, __LINE__)char[200];

根据C++的标准，对于以上的new的使用方法，编译器会去找这样定义的operator new：

void* operator new(size_t, LPCSTR, int)

我们在afxmem.cpp 63行找到了一个这样的operator new 的实现

void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine) { 　return ::operator new(nSize, _NORMAL_BLOCK, lpszFileName, nLine); } void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine) { 　… 　pResult = _malloc_dbg(nSize, nType, lpszFileName, nLine); 　if (pResult != NULL) 　　return pResult; 　… }

　　第二个operator new函数比较长，为了简单期间，我只摘录了部分。很显然最后的内存分配还是通过_malloc_dbg函数实现的，这个函数属于MS C-Runtime Library 的Debug Function。这个函数不但要求传入内存的大小，另外还有文件名和行号两个参数。文件名和行号就是用来记录此次分配是由哪一段代码造成的。如果这块内存在程序结束之前没有被释放，那么这些信息就会输出到Debug窗口里。

　　这里顺便提一下THIS_FILE，__FILE和__LINE__。__FILE__和__LINE__都是编译器定义的宏。当碰到__FILE__时，编译器会把__FILE__替换成一个字符串，这个字符串就是当前在编译的文件的路径名。当碰到__LINE__时，编译器会把__LINE__替换成一个数字，这个数字就是当前这行代码的行号。在DEBUG_NEW的定义中没有直接使用__FILE__，而是用了THIS_FILE，其目的是为了减小目标文件的大小。假设在某个cpp文件中有100处使用了new，如果直接使用__FILE__，那编译器会产生100个常量字符串，这100个字符串都是飧?/SPAN>cpp文件的路径名，显然十分冗余。如果使用THIS_FILE，编译器只会产生一个常量字符串，那100处new的调用使用的都是指向常量字符串的指针。

　　再次观察一下由MFC Application Wizard生成的项目，我们会发现在cpp文件中只对new做了映射，如果你在程序中直接使用malloc函数分配内存，调用malloc的文件名和行号是不会被记录下来的。如果这块内存发生了泄漏，MS C-Runtime Library仍然能检测到，但是当输出这块内存块的信息，不会包含分配它的的文件名和行号。

要在非MFC程序中打开内存泄漏的检测功能非常容易，你只要在程序的入口处加入以下几行代码：

int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG ); tmpFlag |= _CRTDBG_LEAK_CHECK_DF; _CrtSetDbgFlag( tmpFlag );

　　这样，在程序结束的时候，也就是winmain，main或dllmain函数返回之后，如果还有内存块没有释放，它们的信息会被打印到Debug窗口里。

如果你试着创建了一个非MFC应用程序，而且在程序的入口处加入了以上代码，并且故意在程序中不释放某些内存块，你会在Debug窗口里看到以下的信息：

{47} normal block at 0x00C91C90, 200 bytes long. Data: < > 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

　　内存泄漏的确检测到了，但是和上面MFC程序的例子相比，缺少了文件名和行号。对于一个比较大的程序，没有这些信息，解决问题将变得十分困难。

　　为了能够知道泄漏的内存块是在哪里分配的，你需要实现类似MFC的映射功能，把new，maolloc等函数映射到_malloc_dbg函数上。这里我不再赘述，你可以参考MFC的源代码。

　　由于Debug Function实现在MS C-RuntimeLibrary中，所以它只能检测到堆内存的泄漏，而且只限于malloc，realloc或strdup等分配的内存，而那些系统资源，比如HANDLE，GDI Object，或是不通过C-Runtime Library分配的内存，比如VARIANT，BSTR的泄漏，它是无法检测到的，这是这种检测法的一个重大的局限性。另外，为了能记录内存块是在哪里分配的，源代码必须相应的配合，这在调试一些老的程序非常麻烦，毕竟修改源代码不是一件省心的事，这是这种检测法的另一个局限性。

对于开发一个大型的程序，MS C-Runtime Library提供的检测功能是远远不够的。接下来我们就看看外挂式的检测工具。我用的比较多的是BoundsChecker，一则因为它的功能比较全面，更重要的是它的稳定性。这类工具如果不稳定，反而会忙里添乱。到底是出自鼎鼎大名的NuMega，我用下来基本上没有什么大问题。

2.3.3.2 使用BoundsChecker检测内存泄漏

　　BoundsChecker采用一种被称为 Code Injection的技术，来截获对分配内存和释放内存的函数的调用。简单地说，当你的程序开始运行时，BoundsChecker的DLL被自动载入进程的地址空间（这可以通过system-level的Hook实现），然后它会修改进程中对内存分配和释放的函数调用，让这些调用首先转入它的代码，然后再执行原来的代码。BoundsChecker在做这些动作的时，无须修改被调试程序的源代码或工程配置文件，这使得使用它非常的简便、直接。

　　这里我们以malloc函数为例，截获其他的函数方法与此类似。

　　需要被截获的函数可能在DLL中，也可能在程序的代码里。比如，如果静态连结C-Runtime Library，那么malloc函数的代码会被连结到程序里。为了截获住对这类函数的调用，BoundsChecker会动态修改这些函数的指令。

以下两段汇编代码，一段没有BoundsChecker介入，另一段则有BoundsChecker的介入：

126: _CRTIMP void * __cdecl malloc ( 127: size_t nSize 128: ) 129: { 00403C10 push ebp 00403C11 mov ebp,esp 130: return _nh_malloc_dbg(nSize, _newmode, _NORMAL_BLOCK, NULL, 0); 00403C13 push 0 00403C15 push 0 00403C17 push 1 00403C19 mov eax,[__newmode (0042376c)] 00403C1E push eax 00403C1F mov ecx,dword ptr [nSize] 00403C22 push ecx 00403C23 call _nh_malloc_dbg (00403c80) 00403C28 add esp,14h 131: }

以下这一段代码有BoundsChecker介入：

126: _CRTIMP void * __cdecl malloc ( 127: size_t nSize 128: ) 129: { 00403C10 jmp 01F41EC8 00403C15 push 0 00403C17 push 1 00403C19 mov eax,[__newmode (0042376c)] 00403C1E push eax 00403C1F mov ecx,dword ptr [nSize] 00403C22 push ecx 00403C23 call _nh_malloc_dbg (00403c80) 00403C28 add esp,14h 131: }

　　当BoundsChecker介入后，函数malloc的前三条汇编指令被替换成一条jmp指令，原来的三条指令被搬到地址01F41EC8处了。当程序进入malloc后先jmp到01F41EC8，执行原来的三条指令，然后就是BoundsChecker的天下了。大致上它会先记录函数的返回地址（函数的返回地址在stack上，所以很容易修改），然后把返回地址指向属于BoundsChecker的代码，接着跳到malloc函数原来的指令，也就是在00403c15的地方。当malloc函数结束的时候，由于返回地址被修改，它会返回到BoundsChecker的代码中，此时BoundsChecker会记录由malloc分配的内存的指针，然后再跳转到到原来的返回地址去。

　　如果内存分配/释放函数在DLL中，BoundsChecker则采用另一种方法来截获对这些函数的调用。BoundsChecker通过修改程序的DLL Import Table让table中的函数地址指向自己的地址，以达到截获的目的。

截获住这些分配和释放函数，BoundsChecker就能记录被分配的内存或资源的生命周期。接下来的问题是如何与源代码相关，也就是说当BoundsChecker检测到内存泄漏，它如何报告这块内存块是哪段代码分配的。答案是调试信息（Debug Information）。当我们编译一个Debug版的程序时，编译器会把源代码和二进制代码之间的对应关系记录下来，放到一个单独的文件里(.pdb)或者直接连结进目标程序，通过直接读取调试信息就能得到分配某块内存的源代码在哪个文件，哪一行上。使用Code Injection和Debug Information，使BoundsChecker不但能记录呼叫分配函数的源代码的位置，而且还能记录分配时的Call Stack，以及Call Stack上的函数的源代码位置。这在使用像MFC这样的类库时非常有用，以下我用一个例子来说明：

void ShowXItemMenu() { 　… 　CMenu menu; 　menu.CreatePopupMenu(); 　//add menu items. 　menu.TrackPropupMenu(); 　… } void ShowYItemMenu( ) { 　… 　CMenu menu; 　menu.CreatePopupMenu(); 　//add menu items. 　menu.TrackPropupMenu(); 　menu.Detach();//this will cause HMENU leak 　… } BOOL CMenu::CreatePopupMenu() { 　… 　hMenu = CreatePopupMenu(); 　… }

当调用ShowYItemMenu()时，我们故意造成HMENU的泄漏。但是，对于BoundsChecker来说被泄漏的HMENU是在class CMenu::CreatePopupMenu()中分配的。假设的你的程序有许多地方使用了CMenu的CreatePopupMenu()函数，如CMenu::CreatePopupMenu()造成的，你依然无法确认问题的根结到底在哪里，在ShowXItemMenu()中还是在ShowYItemMenu()中，或者还有其它的地方也使用了CreatePopupMenu()？有了Call Stack的信息，问题就容易了。BoundsChecker会如下报告泄漏的HMENU的信息：

Function File Line CMenu::CreatePopupMenu E:"8168"vc98"mfc"mfc"include"afxwin1.inl 1009 ShowYItemMenu E:"testmemleak"mytest.cpp 100

　　这里省略了其他的函数调用

　　如此，我们很容易找到发生问题的函数是ShowYItemMenu()。当使用MFC之类的类库编程时，大部分的API调用都被封装在类库的class里，有了Call Stack信息，我们就可以非常容易的追踪到真正发生泄漏的代码。

　　记录Call Stack信息会使程序的运行变得非常慢，因此默认情况下BoundsChecker不会记录Call Stack信息。可以按照以下的步骤打开记录Call Stack信息的选项开关：

　　1. 打开菜单：BoundsChecker|Setting…

　　2. 在Error Detection页中，在Error Detection Scheme的List中选择Custom

　　3. 在Category的Combox中选择 Pointer and leak error check

　　4. 钩上Report Call Stack复选框

　　5. 点击Ok

　　基于Code Injection，BoundsChecker还提供了API Parameter的校验功能，memory over run等功能。这些功能对于程序的开发都非常有益。由于这些内容不属于本文的主题，所以不在此详述了。

尽管BoundsChecker的功能如此强大，但是面对隐式内存泄漏仍然显得苍白无力。所以接下来我们看看如何用Performance Monitor检测内存泄漏。

2.3.3.3 使用Performance Monitor检测内存泄漏

　　NT的内核在设计过程中已经加入了系统监视功能，比如CPU的使用率，内存的使用情况，I/O操作的频繁度等都作为一个个Counter，应用程序可以通过读取这些Counter了解整个系统的或者某个进程的运行状况。Performance Monitor就是这样一个应用程序。

　　为了检测内存泄漏，我们一般可以监视Process对象的Handle Count，Virutal Bytes 和Working Set三个Counter。Handle Count记录了进程当前打开的HANDLE的个数，监视这个Counter有助于我们发现程序是否有Handle泄漏；Virtual Bytes记录了该进程当前在虚地址空间上使用的虚拟内存的大小，NT的内存分配采用了两步走的方法，首先，在虚地址空间上保留一段空间，这时操作系统并没有分配物理内存，只是保留了一段地址。然后，再提交这段空间，这时操作系统才会分配物理内存。所以，Virtual Bytes一般总大于程序的Working Set。监视Virutal Bytes可以帮助我们发现一些系统底层的问题; Working Set记录了操作系统为进程已提交的内存的总量，这个值和程序申请的内存总量存在密切的关系，如果程序存在内存的泄漏这个值会持续增加，但是Virtual Bytes却是跳跃式增加的。

　　监视这些Counter可以让我们了解进程使用内存的情况，如果发生了泄漏，即使是隐式内存泄漏，这些Counter的值也会持续增加。但是，我们知道有问题却不知道哪里有问题，所以一般使用Performance Monitor来验证是否有内存泄漏，而使用BoundsChecker来找到和解决。

　　当Performance Monitor显示有内存泄漏，而BoundsChecker却无法检测到，这时有两种可能：第一种，发生了偶发性内存泄漏。这时你要确保使用Performance Monitor和使用BoundsChecker时，程序的运行环境和操作方法是一致的。第二种，发生了隐式的内存泄漏。这时你要重新审查程序的设计，然后仔细研究Performance Monitor记录的Counter的值的变化图，分析其中的变化和程序运行逻辑的关系，找到一些可能的原因。这是一个痛苦的过程，充满了假设、猜想、验证、失败，但这也是一个积累经验的绝好机会。

3 探讨C++内存回收

3.1 C++内存对象大会战

　　如果一个人自称为程序高手，却对内存一无所知，那么我可以告诉你，他一定在吹牛。用C或C++写程序，需要更多地关注内存，这不仅仅是因为内存的分配是否合理直接影响着程序的效率和性能，更为主要的是，当我们操作内存的时候一不小心就会出现问题，而且很多时候，这些问题都是不易发觉的，比如内存泄漏，比如悬挂指针。笔者今天在这里并不是要讨论如何避免这些问题，而是想从另外一个角度来认识C++内存对象。

　　我们知道，C++将内存划分为三个逻辑区域：堆、栈和静态存储区。既然如此，我称位于它们之中的对象分别为堆对象，栈对象以及静态对象。那么这些不同的内存对象有什么区别了？堆对象和栈对象各有什么优劣了？如何禁止创建堆对象或栈对象了？这些便是今天的主题。

3.1.1 基本概念

　　先来看看栈。栈，一般用于存放局部变量或对象，如我们在函数定义中用类似下面语句声明的对象：

Type stack_object ;

　　stack_object便是一个栈对象，它的生命期是从定义点开始，当所在函数返回时，生命结束。

　　另外，几乎所有的临时对象都是栈对象。比如，下面的函数定义：

Type fun(Type object);

　　这个函数至少产生两个临时对象，首先，参数是按值传递的，所以会调用拷贝构造函数生成一个临时对象object_copy1 ，在函数内部使用的不是使用的不是object，而是object_copy1，自然，object_copy1是一个栈对象，它在函数返回时被释放；还有这个函数是值返回的，在函数返回时，如果我们不考虑返回值优化（NRV），那么也会产生一个临时对象object_copy2，这个临时对象会在函数返回后一段时间内被释放。比如某个函数中有如下代码：

Type tt ,result ; //生成两个栈对象 tt = fun(tt); //函数返回时，生成的是一个临时对象object_copy2

　　上面的第二个语句的执行情况是这样的，首先函数fun返回时生成一个临时对象object_copy2 ，然后再调用赋值运算符执行

tt = object_copy2 ; //调用赋值运算符

　　看到了吗？编译器在我们毫无知觉的情况下，为我们生成了这么多临时对象，而生成这些临时对象的时间和空间的开销可能是很大的，所以，你也许明白了，为什么对于“大”对象最好用const引用传递代替按值进行函数参数传递了。

　　接下来，看看堆。堆，又叫自由存储区，它是在程序执行的过程中动态分配的，所以它最大的特性就是动态性。在C++中，所有堆对象的创建和销毁都要由程序员负责，所以，如果处理不好，就会发生内存问题。如果分配了堆对象，却忘记了释放，就会产生内存泄漏；而如果已释放了对象，却没有将相应的指针置为NULL，该指针就是所谓的“悬挂指针”，再度使用此指针时，就会出现非法访问，严重时就导致程序崩溃。

　　那么，C++中是怎样分配堆对象的？唯一的方法就是用new（当然，用类malloc指令也可获得C式堆内存），只要使用new，就会在堆中分配一块内存，并且返回指向该堆对象的指针。

　　再来看看静态存储区。所有的静态对象、全局对象都于静态存储区分配。关于全局对象，是在main()函数执行前就分配好了的。其实，在main()函数中的显示代码执行之前，会调用一个由编译器生成的_main()函数，而_main()函数会进行所有全局对象的的构造及初始化工作。而在main()函数结束之前，会调用由编译器生成的exit函数，来释放所有的全局对象。比如下面的代码：

void main（void） { 　… …// 显式代码 }

　　实际上，被转化成这样：

void main（void） { 　_main（）; //隐式代码，由编译器产生，用以构造所有全局对象 　… … // 显式代码 　… … 　exit（） ; // 隐式代码，由编译器产生，用以释放所有全局对象 }

　　所以，知道了这个之后，便可以由此引出一些技巧，如，假设我们要在main()函数执行之前做某些准备工作，那么我们可以将这些准备工作写到一个自定义的全局对象的构造函数中，这样，在main()函数的显式代码执行之前，这个全局对象的构造函数会被调用，执行预期的动作，这样就达到了我们的目的。 刚才讲的是静态存储区中的全局对象，那么，局部静态对象了？局部静态对象通常也是在函数中定义的，就像栈对象一样，只不过，其前面多了个static关键字。局部静态对象的生命期是从其所在函数第一次被调用，更确切地说，是当第一次执行到该静态对象的声明代码时，产生该静态局部对象，直到整个程序结束时，才销毁该对象。

　　还有一种静态对象，那就是它作为class的静态成员。考虑这种情况时，就牵涉了一些较复杂的问题。

　　第一个问题是class的静态成员对象的生命期，class的静态成员对象随着第一个class object的产生而产生，在整个程序结束时消亡。也就是有这样的情况存在，在程序中我们定义了一个class，该类中有一个静态对象作为成员，但是在程序执行过程中，如果我们没有创建任何一个该class object，那么也就不会产生该class所包含的那个静态对象。还有，如果创建了多个class object，那么所有这些object都共享那个静态对象成员。

　　第二个问题是，当出现下列情况时：

class Base { 　public: 　　static Type s_object ; } class Derived1 : public Base / / 公共继承 { 　… …// other data } class Derived2 : public Base / / 公共继承 { 　… …// other data } Base example ; Derivde1 example1 ; Derivde2 example2 ; example.s_object = …… ; example1.s_object = …… ; example2.s_object = …… ;

　　请注意上面标为黑体的三条语句，它们所访问的s_object是同一个对象吗？答案是肯定的，它们的确是指向同一个对象，这听起来不像是真的，是吗？但这是事实，你可以自己写段简单的代码验证一下。我要做的是来解释为什么会这样？ 我们知道，当一个类比如Derived1，从另一个类比如Base继承时，那么，可以看作一个Derived1对象中含有一个Base型的对象，这就是一个subobject。一个Derived1对象的大致内存布局如下：

　　

　　让我们想想，当我们将一个Derived1型的对象传给一个接受非引用Base型参数的函数时会发生切割，那么是怎么切割的呢？相信现在你已经知道了，那就是仅仅取出了Derived1型的对象中的subobject，而忽略了所有Derived1自定义的其它数据成员，然后将这个subobject传递给函数（实际上，函数中使用的是这个subobject的拷贝）。

　　所有继承Base类的派生类的对象都含有一个Base型的subobject（这是能用Base型指针指向一个Derived1对象的关键所在，自然也是多态的关键了），而所有的subobject和所有Base型的对象都共用同一个s_object对象，自然，从Base类派生的整个继承体系中的类的实例都会共用同一个s_object对象了。上面提到的example、example1、example2的对象布局如下图所示：

3.1.2 三种内存对象的比较

　　栈对象的优势是在适当的时候自动生成，又在适当的时候自动销毁，不需要程序员操心；而且栈对象的创建速度一般较堆对象快，因为分配堆对象时，会调用operator new操作，operator new会采用某种内存空间搜索算法，而该搜索过程可能是很费时间的，产生栈对象则没有这么麻烦，它仅仅需要移动栈顶指针就可以了。但是要注意的是，通常栈空间容量比较小，一般是1MB～2MB，所以体积比较大的对象不适合在栈中分配。特别要注意递归函数中最好不要使用栈对象，因为随着递归调用深度的增加，所需的栈空间也会线性增加，当所需栈空间不够时，便会导致栈溢出，这样就会产生运行时错误。

　　堆对象，其产生时刻和销毁时刻都要程序员精确定义，也就是说，程序员对堆对象的生命具有完全的控制权。我们常常需要这样的对象，比如，我们需要创建一个对象，能够被多个函数所访问，但是又不想使其成为全局的，那么这个时候创建一个堆对象无疑是良好的选择，然后在各个函数之间传递这个堆对象的指针，便可以实现对该对象的共享。另外，相比于栈空间，堆的容量要大得多。实际上，当物理内存不够时，如果这时还需要生成新的堆对象，通常不会产生运行时错误，而是系统会使用虚拟内存来扩展实际的物理内存。

接下来看看static对象。

　　首先是全局对象。全局对象为类间通信和函数间通信提供了一种最简单的方式，虽然这种方式并不优雅。一般而言，在完全的面向对象语言中，是不存在全局对象的，比如C#，因为全局对象意味着不安全和高耦合，在程序中过多地使用全局对象将大大降低程序的健壮性、稳定性、可维护性和可复用性。C++也完全可以剔除全局对象，但是最终没有，我想原因之一是为了兼容C。

　　其次是类的静态成员，上面已经提到，基类及其派生类的所有对象都共享这个静态成员对象，所以当需要在这些class之间或这些class objects之间进行数据共享或通信时，这样的静态成员无疑是很好的选择。

　　接着是静态局部对象，主要可用于保存该对象所在函数被屡次调用期间的中间状态，其中一个最显著的例子就是递归函数，我们都知道递归函数是自己调用自己的函数，如果在递归函数中定义一个nonstatic局部对象，那么当递归次数相当大时，所产生的开销也是巨大的。这是因为nonstatic局部对象是栈对象，每递归调用一次，就会产生一个这样的对象，每返回一次，就会释放这个对象，而且，这样的对象只局限于当前调用层，对于更深入的嵌套层和更浅露的外层，都是不可见的。每个层都有自己的局部对象和参数。

　　在递归函数设计中，可以使用static对象替代nonstatic局部对象（即栈对象），这不仅可以减少每次递归调用和返回时产生和释放nonstatic对象的开销，而且static对象还可以保存递归调用的中间状态，并且可为各个调用层所访问。

3.1.3 使用栈对象的意外收获

　　前面已经介绍到，栈对象是在适当的时候创建，然后在适当的时候自动释放的，也就是栈对象有自动管理功能。那么栈对象会在什么会自动释放了？第一，在其生命期结束的时候；第二，在其所在的函数发生异常的时候。你也许说，这些都很正常啊，没什么大不了的。是的，没什么大不了的。但是只要我们再深入一点点，也许就有意外的收获了。

　　栈对象，自动释放时，会调用它自己的析构函数。如果我们在栈对象中封装资源，而且在栈对象的析构函数中执行释放资源的动作，那么就会使资源泄漏的概率大大降低，因为栈对象可以自动的释放资源，即使在所在函数发生异常的时候。实际的过程是这样的：函数抛出异常时，会发生所谓的stack_unwinding（堆栈回滚），即堆栈会展开，由于是栈对象，自然存在于栈中，所以在堆栈回滚的过程中，栈对象的析构函数会被执行，从而释放其所封装的资源。除非，除非在析构函数执行的过程中再次抛出异常――而这种可能性是很小的，所以用栈对象封装资源是比较安全的。基于此认识，我们就可以创建一个自己的句柄或代理来封装资源了。智能指针（auto_ptr）中就使用了这种技术。在有这种需要的时候，我们就希望我们的资源封装类只能在栈中创建，也就是要限制在堆中创建该资源封装类的实例。

3.1.4 禁止产生堆对象

　　上面已经提到，你决定禁止产生某种类型的堆对象，这时你可以自己创建一个资源封装类，该类对象只能在栈中产生，这样就能在异常的情况下自动释放封装的资源。

　　那么怎样禁止产生堆对象了？我们已经知道，产生堆对象的唯一方法是使用new操作，如果我们禁止使用new不就行了么。再进一步，new操作执行时会调用operator new，而operator new是可以重载的。方法有了，就是使new operator 为private，为了对称，最好将operator delete也重载为private。现在，你也许又有疑问了,难道创建栈对象不需要调用new吗？是的，不需要，因为创建栈对象不需要搜索内存，而是直接调整堆栈指针，将对象压栈，而operator new的主要任务是搜索合适的堆内存，为堆对象分配空间，这在上面已经提到过了。好，让我们看看下面的示例代码：

#include <stdlib.h> //需要用到C式内存分配函数 class Resource ; //代表需要被封装的资源类 class NoHashObject { 　private: 　　Resource* ptr ;//指向被封装的资源 　　... ... //其它数据成员 　　void* operator new(size_t size) //非严格实现，仅作示意之用 　　{ 　　　return malloc(size) ; 　　} 　　void operator delete(void* pp) //非严格实现，仅作示意之用 　　{ 　　　free(pp) ; 　　} 　public: 　　NoHashObject() 　　{ 　　　//此处可以获得需要封装的资源，并让ptr指针指向该资源 　　　ptr = new Resource() ; 　　} 　　~NoHashObject() 　　{ 　　　delete ptr ; //释放封装的资源 　　} };  　　NoHashObject现在就是一个禁止堆对象的类了，如果你写下如下代码： NoHashObject* fp = new NoHashObject() ; //编译期错误！ delete fp ;

上面代码会产生编译期错误。好了，现在你已经知道了如何设计一个禁止堆对象的类了，你也许和我一样有这样的疑问，难道在类NoHashObject的定义不能改变的情况下，就一定不能产生该类型的堆对象了吗？不，还是有办法的，我称之为“暴力破解法”。C++是如此地强大，强大到你可以用它做你想做的任何事情。这里主要用到的是技巧是指针类型的强制转换。

void main(void) { 　char* temp = new char[sizeof(NoHashObject)] ; 　//强制类型转换，现在ptr是一个指向NoHashObject对象的指针 　NoHashObject* obj_ptr = (NoHashObject*)temp ; 　temp = NULL ; //防止通过temp指针修改NoHashObject对象 　//再一次强制类型转换，让rp指针指向堆中NoHashObject对象的ptr成员 　Resource* rp = (Resource*)obj_ptr ; 　//初始化obj_ptr指向的NoHashObject对象的ptr成员 　rp = new Resource() ; 　//现在可以通过使用obj_ptr指针使用堆中的NoHashObject对象成员了 　... ... 　delete rp ;//释放资源 　temp = (char*)obj_ptr ; 　obj_ptr = NULL ;//防止悬挂指针产生 　delete [] temp ;//释放NoHashObject对象所占的堆空间。 }

　　上面的实现是麻烦的，而且这种实现方式几乎不会在实践中使用，但是我还是写出来路，因为理解它，对于我们理解C++内存对象是有好处的。对于上面的这么多强制类型转换，其最根本的是什么了？我们可以这样理解：

　　某块内存中的数据是不变的，而类型就是我们戴上的眼镜，当我们戴上一种眼镜后，我们就会用对应的类型来解释内存中的数据，这样不同的解释就得到了不同的信息。

　　所谓强制类型转换实际上就是换上另一副眼镜后再来看同样的那块内存数据。

　　另外要提醒的是，不同的编译器对对象的成员数据的布局安排可能是不一样的，比如，大多数编译器将NoHashObject的ptr指针成员安排在对象空间的头4个字节，这样才会保证下面这条语句的转换动作像我们预期的那样执行：

Resource* rp = (Resource*)obj_ptr ;

　　但是，并不一定所有的编译器都是如此。

　　既然我们可以禁止产生某种类型的堆对象，那么可以设计一个类，使之不能产生栈对象吗？当然可以。

3.1.5 禁止产生栈对象

　　前面已经提到了，创建栈对象时会移动栈顶指针以“挪出”适当大小的空间，然后在这个空间上直接调用对应的构造函数以形成一个栈对象，而当函数返回时，会调用其析构函数释放这个对象，然后再调整栈顶指针收回那块栈内存。在这个过程中是不需要operator new/delete操作的，所以将operator new/delete设置为private不能达到目的。当然从上面的叙述中，你也许已经想到了：将构造函数或析构函数设为私有的，这样系统就不能调用构造/析构函数了，当然就不能在栈中生成对象了。

　　这样的确可以，而且我也打算采用这种方案。但是在此之前，有一点需要考虑清楚,那就是，如果我们将构造函数设置为私有，那么我们也就不能用new来直接产生堆对象了，因为new在为对象分配空间后也会调用它的构造函数啊。所以，我打算只将析构函数设置为private。再进一步，将析构函数设为private除了会限制栈对象生成外，还有其它影响吗？是的，这还会限制继承。

　　如果一个类不打算作为基类，通常采用的方案就是将其析构函数声明为private。

　　为了限制栈对象，却不限制继承，我们可以将析构函数声明为protected，这样就两全其美了。如下代码所示：

class NoStackObject { 　protected: 　　~NoStackObject() { } 　public: 　　void destroy() 　　{ 　　　delete this ;//调用保护析构函数 　　} };

　　接着，可以像这样使用NoStackObject类：

NoStackObject* hash_ptr = new NoStackObject() ; ... ... //对hash_ptr指向的对象进行操作 hash_ptr->destroy() ;

　　呵呵，是不是觉得有点怪怪的，我们用new创建一个对象，却不是用delete去删除它，而是要用destroy方法。很显然，用户是不习惯这种怪异的使用方式的。所以，我决定将构造函数也设为private或protected。这又回到了上面曾试图避免的问题，即不用new，那么该用什么方式来生成一个对象了？我们可以用间接的办法完成，即让这个类提供一个static成员函数专门用于产生该类型的堆对象。（设计模式中的singleton模式就可以用这种方式实现。）让我们来看看：

class NoStackObject { 　protected: 　　NoStackObject() { } 　　~NoStackObject() { } 　public: 　　static NoStackObject* creatInstance() 　　{ 　　　return new NoStackObject() ;//调用保护的构造函数 　　} 　　void destroy() 　　{ 　　　delete this ;//调用保护的析构函数 　　} };

　　现在可以这样使用NoStackObject类了：

NoStackObject* hash_ptr = NoStackObject::creatInstance() ; ... ... //对hash_ptr指向的对象进行操作 hash_ptr->destroy() ; hash_ptr = NULL ; //防止使用悬挂指针

现在感觉是不是好多了，生成对象和释放对象的操作一致了。

3.2 浅议C++ 中的垃圾回收方法

　　许多 C 或者 C++ 程序员对垃圾回收嗤之以鼻，认为垃圾回收肯定比自己来管理动态内存要低效，而且在回收的时候一定会让程序停顿在那里，而如果自己控制内存管理的话，分配和释放时间都是稳定的，不会导致程序停顿。最后，很多 C/C++ 程序员坚信在C/C++ 中无法实现垃圾回收机制。这些错误的观点都是由于不了解垃圾回收的算法而臆想出来的。

　　其实垃圾回收机制并不慢，甚至比动态内存分配更高效。因为我们可以只分配不释放，那么分配内存的时候只需要从堆上一直的获得新的内存，移动堆顶的指针就够了；而释放的过程被省略了，自然也加快了速度。现代的垃圾回收算法已经发展了很多，增量收集算法已经可以让垃圾回收过程分段进行，避免打断程序的运行了。而传统的动态内存管理的算法同样有在适当的时间收集内存碎片的工作要做，并不比垃圾回收更有优势。

　　而垃圾回收的算法的基础通常基于扫描并标记当前可能被使用的所有内存块，从已经被分配的所有内存中把未标记的内存回收来做的。C/C++ 中无法实现垃圾回收的观点通常基于无法正确扫描出所有可能还会被使用的内存块，但是，看似不可能的事情实际上实现起来却并不复杂。首先，通过扫描内存的数据，指向堆上动态分配出来内存的指针是很容易被识别出来的，如果有识别错误，也只能是把一些不是指针的数据当成指针，而不会把指针当成非指针数据。这样，回收垃圾的过程只会漏回收掉而不会错误的把不应该回收的内存清理。其次，如果回溯所有内存块被引用的根，只可能存在于全局变量和当前的栈内，而全局变量(包括函数内的静态变量)都是集中存在于 bss 段或 data段中。

　　垃圾回收的时候，只需要扫描 bss 段, data 段以及当前被使用着的栈空间，找到可能是动态内存指针的量，把引用到的内存递归扫描就可以得到当前正在使用的所有动态内存了。

　　如果肯为你的工程实现一个不错的垃圾回收器，提高内存管理的速度，甚至减少总的内存消耗都是可能的。如果有