内存泄露

以在程序运行期决定），使用完后必须显式释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。

特别注意：
内存泄露是一种逻辑上的概念，即一块申请的内存，如果使用完了，以后不使用了，却没有及时释放，严格意义上说内存泄露就发生了。并不是只要显式的释放了内存就没有内存泄露（详细描述请参考本文的隐式内存泄露）。

在多出口的函数中，内存泄漏最容易发生，如下面这段代码：

实例一：
void MyFunction(int nSize)
{ 
       char* p= new char[nSize]; 
       if ( NULL == p ) {
             return;
       }
       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等，从根本上说这些由操作系统分配的对象也消耗内存，如果这些对象发生泄漏最终也会导致内存的泄漏。而且，某些对象消耗的是核心态内存（进程的地址空间中的高2GB区域，该区域为所有的进程所共享），这些对象严重泄漏时会导致整个操作系统不稳定。所以相比之下，系统资源的泄漏比堆内存的泄漏更为严重。

以发生的方式来分类，内存泄漏可以分为4类：
1.   常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
2.   偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
3.  一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，但是因为这个类是一个Singleton，所以内存泄漏只会发生一次。

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

 

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

下面我们从系统资源的泄漏和隐式内存泄漏两个方面来讨论泄漏的问题：

一、系统资源的泄漏：

系统资源的泄漏是相对堆内存的泄漏而言的，由于堆内存的泄漏讨论的比较多，也很容易被理解，这里就不赘述了。系统资源包括核心态HANDLE，GDI Object，SOCKET，Interface等，在分析系统资源泄漏前，让我们先来了解一下系统资源的管理。（参考Chapter 3《深入解析Windows操作系统》）

 

 

图1 A Process and its resources

由图1可知，每个进程都有一个Handle Table，Handle Table中包含了所有该进程创建或打开的对象的指针。Handle Talbe可以理解为如下的结构

Index 表项      1 8个字节用于标示对象的信息(Refer to 图2) 2 8个字节用于标示对象的信息(Refer to 图2) ... ...

表1 Handle Table的结构

Handle Table的每项具有如下的结构：

图2 Structure of a handle table entry

在我们的进程中Open或Create一个内核对象时，进程Handle Table中便添加相应的项，并返回该项在Handle Table中的Index作为该进程中该内核对象的Handle。所以进程中系统资源的HANDLE就是该系统资源指针在Handle Table中的Index，该值是和进程相关的，同一个内核对象在不同的进程中对应的HANDLE一般不同。
     由图1可知，如果我们的进程中创建或打开了某个系统资源，在使用完后没有调用对应的函数（如CloseHandle）释放或使该资源的Usage Count减1（每个内核对象维护一个Usage Count来记录引用该内核对象的进程的个数。进程通过调用CloseHandle函数释放对内核对象的引用。当进程对某个内核对象调用CloseHandle时，对应的内核对象的Usage Count减1，当内核对象的Usage Count为0时，内核才真正地将该内核对象释放。），则该资源在进程的运行过程中将一直存在，该资源对应的内核内存就一直不能被释放，直到进程的结束。

二、隐式内存泄漏

从前面对隐式内存泄漏的定义中，我们知道，程序最终释放了所有申请的内存，很多人会说，这里并没有产生内存泄漏。所以在此，我们必须重新界定一下内存泄漏的概念。

从进程的角度来考虑的话，在它的地址空间中一般有2GB的用户模式分区可供程序员使用，只要进程运行的过程中内存的使用少于这个值，就能基本正常运行，当进程退出时，不管程序员有没有显式的调用内存函数来释放内存，系统总能够在进程结束时终结所有和进程相关的资源，包括内存。所以说，如果在进程结束的时候才将进程运行期间所申请的内存释放是没有意义的，因为就算你不释放，系统也会帮你释放的。

内存泄漏的重新界定：

     在进程运行过程中，一定要及时释放申请的内存，即如果用户申请了一段内存，则在使用完后立即释放，否则进程的内存会不断的累积，最后导致进程的地址空间中没有足够的内存来分配给可能出现的新的内存申请。

     比如，该文中的例1，此处申请的内存只用于在该函数中临时缓存得到的字符串，完成该任务后就应该及时释放，如果此处不释放，因为该首指针已经没法得到，所以在进程结束前就没有机会释放了。但是系统会在该进程结束时释放该段内存。如果在进程结束前尚未出现内存耗尽的情况，则用户无法感知内存泄露的存在。

内存泄漏为什么会造成内存耗尽？
     同样拿例1来说，如果该程序运行的时间较短，每次泄露的内存也不多的话，该程序在运行过程中不会出现内存耗尽的情况。但是如果该程序运行了n久之后（谁知道它要运行多久，也许是一辈子吧:)），积少成多，最后泄漏的内存已经到了2GB(进程全部用户分区的大小)，这时候，再运行该函数，在语句
                   char* p= new char[nSize];
会返回NULL，因为已经没有可被分配的内存了。
     试想，如果我在程序中定义了一个全局变量，它记录了该进程中每次分配内存的首地址，所以在任何时候，程序员都有机会来释放申请的内存，但是，程序员在编写程序时只是在进程结束时才释放记录在全局变量中所有分配的内存的话，上述内存耗尽的情况照样发生。（当我们指责他的程序发生了内存泄漏时，也许他还能辩论一番，毕竟，他在进程终止之前释放了所有分配的内存）

内存泄漏为什么会引起机器性能的下降？
     和内存相关的机器性能下降的原因可归结为：内存与页文件或内存映射文件之间频繁的数据交换。在为进程申请内存空间后，访问该段内存将时，该区域被映射到计算机的主存中，即使进程“Working Set”不断增加，从而是可用的计算机主存不断下降，从而增加了主存与页文件的数据交换。（Working Set占用的是真正计算机的主存）
     但是因为被泄露的内存不可能再被使用，所以一旦被泄露的内存被交换出计算机主存，它们也就不可能再被加载到主存。
     反映进程运行性能的一个主要参考指标是Page Faults，如果Page Faults不断上升，说明内存和页文件之间发生了频繁的数据交换，说明机器的主存已经严重不足。