内存泄露检测

内存泄漏的定义  

　 　一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内 存。应用程序一般使用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的要小很 多。

　　内存泄漏的发生方式：

　　以发生的方式来分类，内存泄漏可以分为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的析 构函数里被删除）。当不断的有连接建立、断开时隐式内存泄漏就发生了。

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

　　检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住这两个函数，我们就能跟踪每一 块内存的生命周期，比如，每当成功的分配一块内存后，就把它的指针加入一个全局的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，这时就需要 截获多个分配函数）
这里顺便提一下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的调用使用的都是指向常量字符串的指针。