C++内存管理

参考并整理于http://blog.csdn.net/zhanghefu/archive/2009/12/14/5003407.aspx

1、内存分配

1.1  分配方式简介

在C++中，内存分成5个区，他们分别是堆、栈、自由存储区、全局/静态存储区和常量存储区。也有认为分为3个区：堆、栈、静态存储区，把只有存储区作为堆，全局/静态存储区和常量存储区统称为静态存储区。

栈，在执行函数时，函数内局部变量的存储单元都可以在栈上创建，函数执行结束时这些存储单元自动被释放。栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限。

堆，就是那些由new分配的内存块，他们的释放编译器不去管，由我们的应用程序去控制，一般一个new就要对应一个delete。如果程序员没有释放掉，那么在程序结束后，操作系统会自动回收。

自由存储区，就是那些由malloc等分配的内存块，他和堆是十分相似的，不过它是用free来结束自己的生命的。

全局/静态存储区，全局变量和静态变量被分配到同一块内存中，在以前的C语言中，全局变量又分为初始化的和未初始化的，在C++里面没有这个区分了，他们共同占用同一块内存区。

常量存储区，这是一块比较特殊的存储区，他们里面存放的是常量，不允许修改。也可以统称为静态存储区。

 

1.2   堆和栈

堆和栈主要的区别由以下几点：管理方式不同；空间大小不同；能否产生碎片不同；生长方向不同；分配方式不同；分配效率不同；

管理方式：对于栈来讲，是由编译器自动管理，无需我们手工控制；对于堆来说，释放工作由程序员控制，容易产生memory leak。

空间大小：一般来讲在32位系统下，堆内存可以达到4G的空间，从这个角度来看堆内存几乎是没有什么限制的。但是对于栈来讲，一般都是有一定的空间大小的，例如，在VC++中，默认的栈空间大小是1M。当然，我们可以修改：

a. link时用/STACK指定它的大小，或者在.def中使用STACKSIZE指定它的大小；

b. 使用控制台命令“EDITBIN”更改exe的栈空间大小。

如：打开工程，依次操作菜单如下：Project->Setting->Link，在Category 中选中Output，然后在Reserve中设定堆栈的最大值和commit。

注意：reserve最小值为4Byte；commit是保留在虚拟内存的页文件里面，它设置的较大会使栈开辟较大的值，可能增加内存的开销和启动时间。

碎片问题：对于堆来讲，频繁的new/delete势必会造成内存空间的不连续，从而造成大量的碎片，使程序效率降低。对于栈来讲，则不会存在这个问题，因为栈是先进后出的队列，他们是如此的一一对应，以至于永远都不可能有一个内存块从栈中间弹出，在他弹出之前，在他上面的后进的栈内容已经被弹出。

生长方向：对于堆来讲，生长方向是向上的，也就是向着内存地址增加的方向；对于栈来讲，它的生长方向是向下的，是向着内存地址减小的方向增长。

分配方式：堆都是动态分配的，没有静态分配的堆。栈有2种分配方式：静态分配和动态分配。静态分配是编译器完成的，比如局部变量的分配。动态分配由alloca函数进行分配，但是栈的动态分配和堆是不同的，他的动态分配是由编译器进行释放，无需我们手工实现。

 

分配效率：栈是机器系统提供的数据结构，计算机会在底层对栈提供支持：分配专门的寄存器存放栈的地址，压栈出栈都有专门的指令执行，这就决定了栈的效率比较高。堆则是C/C++函数库提供的，它的机制是很复杂的，例如为了分配一块内存，库函数会按照一定的算法（具体的算法可以参考数据结构/操作系统）在堆内存中搜索可用的足够大小的空间，如果没有足够大小的空间（可能是由于内存碎片太多），就有可能调用系统功能去增加程序数据段的内存空间，这样就有机会分到足够大小的内存，然后进行返回。显然，堆的效率比栈要低得多。

 

从这里我们可以看到，堆和栈相比，由于大量new/delete的使用，容易造成大量的内存碎片；由于没有专门的系统支持，效率很低；由于可能引发用户态和核心态的切换，内存的申请，代价变得更加昂贵。所以栈在程序中是应用最广泛的，就算是函数的调用也利用栈去完成，函数调用过程中的参数，返回地址，EBP和局部变量都采用栈的方式存放。所以，我们推荐大家尽量用栈，而不是用堆。

　　虽然栈有如此众多的好处，但是由于和堆相比不是那么灵活，有时候分配大量的内存空间，还是用堆好一些。

无论是堆还是栈，都要防止越界现象的发生（除非你是故意使其越界），因为越界的结果要么是程序崩溃，要么是摧毁程序的堆、栈结构，产生以想不到的结果，就算是在你的程序运行过程中，没有发生上面的问题，你还是要小心，说不定什么时候就崩掉，那时候debug可是相当困难的。

 

1.3   内存分配控制

在嵌入式系统中使用C++的一个常见问题是内存分配，即对new 和 delete 操作符的失控。

具有讽刺意味的是，问题的根源却是C++对内存的管理非常的容易而且安全。具体地说，当一个对象被消除时，它的析构函数能够安全的释放所分配的内存。

 

这当然是个好事情，但是这种使用的简单性使得程序员们过度使用new 和 delete，而不注意在嵌入式C++环境中的因果关系。并且，在嵌入式系统中，由于内存的限制，频繁的动态分配不定大小的内存会引起很大的问题以及堆破碎的风险。

作为忠告，保守的使用内存分配是嵌入式环境中的第一原则。

但当你必须要使用new 和delete时，你不得不控制C++中的内存分配。你需要用一个全局的new 和delete来代替系统的内存分配符，并且一个类一个类的重载new 和delete。

　　一个防止堆破碎的通用方法是从不同固定大小的内存持中分配不同类型的对象。对每个类重载new 和delete就提供了这样的控制。

 

 

1.3.1  重载new和delete操作符

可以很容易地重载new 和 delete 操作符，如下所示：

// 全局的new和delete重载void * operator new(size_t size){void *p = malloc(size);return (p);}void operator delete(void *p);{free(p);} // 单个类的new 和 delete 操作符重载。能灵活的控制对象的内存分配。class TestClass {public:void * operator new(size_t size);void operator delete(void *p);// .. other members here ...};void *TestClass::operator new(size_t size){void *p = malloc(size); // Replace this with alternative allocatorreturn (p);}void TestClass::operator delete(void *p){free(p); // Replace this with alternative de-allocator}/* 所有TestClass 对象的内存分配都采用这段代码。更进一步，任何从TestClass 继承的类也都采用这一方式，除非它自己也重载了new 和 delete 操作符。*/ 

通过重载new 和 delete 操作符的方法，可以自由地采用不同的分配策略，从不同的内存池中分配不同的类对象。

1.3.2  为单个的类重载 new[ ]和delete[ ]

 

 

 

 

 

必须小心对象数组的分配。你可能希望调用到被你重载过的new 和 delete 操作符，但并不如此。对象数组的内存分配的请求被定向到全局的new[ ]和delete[ ] 操作符，而这些内存来自于系统堆。

 

C++将对象数组的内存分配作为一个单独的操作，而不同于单个对象的内存分配。为了改变这种方式，你同样需要重载new[ ] 和 delete[ ]操作符。

class TestClass {public:void * operator new[ ](size_t size);void operator delete[ ](void *p);// .. other members here ..};void *TestClass::operator new[ ](size_t size){void *p = malloc(size);return (p);}void TestClass::operator delete[ ](void *p){free(p);}int main(void){TestClass *p = new TestClass[10];// ... etc ...delete[ ] p;}  

但是注意：对于多数C++的实现，new[]操作符中的个数参数是数组的大小加上额外的存储对象数目的一些字节，在你的内存分配机制重要考虑到这一点。你应该尽量避免分配对象数组，从而使你的内存分配策略简单。

 

1.4   常见的内存错误及其对策

1）内存分配未成功，却使用了它。常用解决办法是，在使用内存之前检查指针是否为NULL。如果指针p是函数的参数，那么在函数的入口处用assert(p!=NULL)进行检查。如果是用malloc或new来申请内存，应该用if(p==NULL) 或if(p!=NULL)进行防错处理。

2）内存分配虽然成功，但是尚未初始化就引用它。主要有两个起因：一是没有初始化的观念；二是误以为内存的缺省初值全为零，导致引用初值错误（例如数组）。 内存的缺省初值究竟是什么并没有统一的标准，尽管有些时候为零值，我们宁可信其无不可信其有。所以无论用何种方式创建数组，都别忘了赋初值，即便是赋零值也不可省略，不要嫌麻烦。

3）内存分配成功并且已经初始化，但操作越过了内存的边界。例如在使用数组时经常发生下标“多1”或者“少1”的操作。特别是在for循环语句中，循环次数很容易搞错，导致数组操作越界。

4）忘记了释放内存，造成内存泄露。动态内存的申请与释放必须配对。

5）释放了内存却继续使用它。有三种情况：

（a）程序中的对象调用关系过于复杂，实在难以搞清楚某个对象究竟是否已经释放了内存。此时应该重新设计数据结构，从根本上解决对象管理的混乱局面。

（b）函数的return语句写错了，注意不要返回指向“栈内存”的“指针”或者“引用”，因为该内存在函数体结束时被自动销毁。

（c）使用free或delete释放了内存后，没有将指针设置为NULL。导致产生“野指针”。

 

 

【规则1】用malloc或new申请内存之后，应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存。

【规则2】不要忘记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用。

【规则3】避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”操作。

　　【规则4】动态内存的申请与释放必须配对，防止内存泄漏。

 

　　【规则5】用free或delete释放了内存之后，立即将指针设置为NULL，防止产生“野指针”。

 

1.5   杜绝“野指针”

“野指针”不是NULL指针，是指向“垃圾”内存的指针。人们一般不会错用NULL指针，因为用if语句很容易判断。但是“野指针”是很危险的，if语句对它不起作用。 “野指针”的成因主要有三种：

（1）指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针，它的缺省值是随机的，它会乱指一气。所以，指针变量在创建的同时应当被初始化，要么将指针设置为NULL，要么让它指向合法的内存。

（2）指针p被free或者delete之后，没有置为NULL，让人误以为p是个合法的指针。

（3）指针操作超越了变量的作用域范围。如：

int a[10];

// 初始化...

int*p = a+10; // error, 此时p已经越界。

1.6  有了malloc/free为什么还要new/delete?

 

malloc与free是C++/C语言的标准库函数，new/delete是C++的运算符。它们都可用于申请动态内存和释放内存。

对于非内部数据类型的对象而言，光用maloc/free无法满足动态对象的要求。因为对象在创建的同时要自动执行构造函数，对象在消亡之前要自动执行析构函数。由于malloc/free是库函数而不是运算符，不在编译器控制权限之内，不能够把执行构造函数和析构函数的任务强加于malloc/free。因此C++语言需要一个能完成动态内存分配和初始化工作的运算符new，以及一个能完成清理与释放内存工作的运算符delete。注意new/delete不是库函数。

 

既然new/delete的功能完全覆盖了malloc/free，为什么C++不把malloc/free淘汰出局呢？这是因为C++程序经常要调用C函数，而C程序只能用malloc/free管理动态内存。

 

如果用free释放“new创建的动态对象”，那么该对象因无法执行析构函数而可能导致程序出错。如果用delete释放“malloc申请的动态内存”，结果不会导致程序出错，但是该程序的可读性很差。所以new/delete必须配对使用，malloc/free也一样。

 

 

1.7   内存耗尽

 

如果在申请动态内存时找不到足够大的内存块，malloc和new将返回NULL指针，宣告内存申请失败。通常有三种方式处理“内存耗尽”问题。

（1）判断指针是否为NULL，如果是则马上用return语句终止本函数。

（2）判断指针是否为NULL，如果是则马上用exit(1)终止整个程序的运行。

 

    （3）为new和malloc设置异常处理函数。例如Visual C++可以用_set_new_hander函数为new设置用户自己定义的异常处理函数，也可以让malloc享用与new相同的异常处理函数。详细内容请参考C++使用手册。

上述（1）（2）方式使用最普遍。如果一个函数内有多处需要申请动态内存，那么方式（1）就显得力不从心（释放内存很麻烦），应该用方式（2）来处理。

如果发生“内存耗尽”这样的事情，一般说来应用程序已经无药可救。如果不用exit(1) 把坏程序杀死，它可能会害死操作系统。道理如同：如果不把歹徒击毙，歹徒在老死之前会犯下更多的罪。

不加错误处理将导致程序的质量很差，千万不可因小失大。

 

1.8  malloc/free的使用要点

函数malloc的原型及使用如下：

void * malloc(size_t size);void free( void * memblock );int *p = (int *) malloc(sizeof(int) * length);free(p); 

 

我们应当把注意力集中在两个要素上：“类型转换”和“sizeof”。

malloc返回值的类型是void *，所以在调用malloc时要显式地进行类型转换，将void * 转换成所需要的指针类型。

 

malloc函数本身并不识别要申请的内存是什么类型，它只关心内存的总字节数。使用sizeof运算符是良好的风格。

为什么free函数不象malloc函数那样复杂呢？这是因为指针p的类型以及它所指的内存的容量事先都是知道的，语句free(p)能正确地释放内存。如果p是NULL指针，那么free对p无论操作多少次都不会出问题。如果p不是NULL指针，那么free对p连续操作两次就会导致程序运行错误。

 

 

1.9    new/delete的使用要点

运算符new使用起来要比函数malloc简单得多，例如：

int *p1 = (int *)malloc(sizeof(int) * length);int *p2 = new int[length]; 

这是因为new内置了sizeof、类型转换和类型安全检查功能。对于非内部数据类型的对象而言，new在创建动态对象的同时完成了初始化工作。

如果对象有多个构造函数，那么new的语句也可以有多种形式。例如:

class Obj{　public :　　Obj(void); // 无参数的构造函数　　Obj(int x); // 带一个参数的构造函数　　//…}void Test(void){　Obj *a = new Obj;　Obj *b = new Obj(1); // 初值为1　//…　delete a;　delete b; // 如果用new创建对象数组，那么只能使用对象的无参数构造函数 Obj *objects = new Obj[100]; // 创建100个动态对象 // Obj *objects = new Obj[100](1);// error delete []objects; // 正确的用法 //delete objects; // 错误的用法} 

 

2、内存回收

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

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

（3）静态对象：

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

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

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

 

 

2.1   使用栈对象

 

 

栈对象是在适当的时候创建，然后在适当的时候自动释放的，也就是栈对象有自动管理功能。那么栈对象会在什么会自动释放了？第一，在其生命期结束的时候；第二，在其所在的函数发生异常的时候。

 

栈对象，自动释放时，会调用它自己的析构函数。如果我们在栈对象中封装资源，而且在栈对象的析构函数中执行释放资源的动作，那么就会使资源泄漏的概率大大降低，因为栈对象可以自动的释放资源，即使在所在函数发生异常的时候。

实际的过程是这样的：函数抛出异常时，会发生所谓的stack_unwinding（堆栈回滚），即堆栈会展开，由于是栈对象，自然存在于栈中，所以在堆栈回滚的过程中，栈对象的析构函数会被执行，从而释放其所封装的资源。除非在析构函数执行的过程中再次抛出异常――而这种可能性是很小的，所以用栈对象封装资源是比较安全的。

基于此认识，我们就可以创建一个自己的句柄或代理来封装资源了。智能指针（auto_ptr）中就使用了这种技术。在有这种需要的时候，我们就希望我们的资源封装类只能在栈中创建，也就是要限制在堆中创建该资源封装类的实例。

 

 

2.2   禁止产生堆对象

重载类中new和delete操作符为私有函数。

2.3   禁止产生栈对象

将构造函数或析构函数设为私有的，这样系统就不能调用构造/析构函数了，当然就不能在栈中生成对象了。（即设计模式中的单实例模式）

 

 

 

3、健壮指针和资源管理

资源的定义：“任何在你的程序中获得并在此后释放的东西。”内存是一个相当明显的资源的例子。它需要用new来获得，用delete来释放。同时也有许多其它类型的资源文件：句柄、重要的片断、Windows中的GDI资源，等等。将资源的概念推广到程序中创建、释放的所有对象也是十分方便的，无论对象是在堆中分配的还是在栈中或者是在全局作用域内的。

对于给定的资源的拥有着，是负责释放资源的一个对象或者是一段代码。所有权分立为两种级别——自动的和显式的（automatic and explicit），如果一个对象的释放是由语言本身的机制来保证的，这个对象的就是被自动地所有。例如，一个嵌入在其他对象中的对象，他的清除需要其他对象来在清除的时候保证。外面的对象被看作嵌入类的所有者。

类似地，每个在栈上创建的对象（作为自动变量）的释放（破坏）是在控制流离开了对象被定义的作用域的时候保证的。这种情况下，作用于被看作是对象的所有者。注意所有的自动所有权都是和语言的其他机制相容的，包括异常。无论是如何退出作用域的——正常流程控制退出、一个break语句、一个return、一个goto、或者是一个throw——自动资源都可以被清除。

到目前为止，一切都很好！问题是在引入指针、句柄和抽象的时候产生的。如果通过一个指针访问一个对象的话，比如对象在堆中分配，C++不自动地关注它的释放。程序员必须明确的用适当的程序方法来释放这些资源。比如说，如果一个对象是通过调用new来创建的，它需要用delete来回收。一个文件是用CreateFile(Win32 API)打开的，它需要用CloseHandle来关闭。用EnterCritialSection进入的临界区（Critical Section）需要LeaveCriticalSection退出，等等。一个"裸"指针，文件句柄，或者临界区状态没有所有者来确保它们的最终释放。基本的资源管理的前提就是确保每个资源都有他们的所有者。

 

3.1 RAII规则

RAII是“资源获取就是初始化”的缩语（Resource Acquisition Is Initialization），是一种利用对象生命周期来控制程序资源（如内存、文件句柄、网络连接、互斥量等等）的简单技术。

        RAII 的一般做法是这样的：在对象构造时获取资源，接着控制对资源的访问使之在对象的生命周期内始终保持有效，最后在对象析构的时候释放资源。借此，我们实际上把管理一份资源的责任托管给了一个对象。

这种做法有两大好处：

　　1,我们不需要显式地释放资源。

　　2,采用这种方式，对象所需的资源在其生命期内始终保持有效 —— 我们可以说，此时这个类维护了一个 invariant。这样，通过该类对象使用资源时，就不必检查资源有效性的问题，可以简化逻辑、提高效率。

 

 

3.2 auto_ptr

http://blog.csdn.net/wcyoot/archive/2011/06/15/6546375.aspx