c/c++服务器程序内存泄露问题分析及解决

由 www.169it.com 搜集整理

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

1.内存泄漏的定义

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

1 2 3 4 5 6 7 8 9 10

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的泄漏是一种常见的资源泄漏：

1 2 3 4 5 6 7 8 9 10 11 12 13

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，因此内存泄漏只会发生一次。另外一个例子：

1 2 3 4 5 6 7 8

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

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

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

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.检测内存泄漏

　　检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住这两个函数，咱们就能跟踪每一 块内存的生命周期，好比，每当成功的分配一块内存后，就把它的指针加入一个全局的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虽然没法标示出发生问题的代码，可是它能检测出隐式的内存泄漏的存在，这是其余两类工具无能为力的地方。　　

　　内存泄漏是个大而复杂的问题，即便是Java和.Net这样有 Gabarge Collection机制的环境，也存在着泄漏的可能，好比隐式内存泄漏。

3.避免内存泄露

  写服务器程序，最怕的就是内存泄露。由于程序常常运行好几个月不停，一点点内存泄露都会致使悲剧的发生。常规来讲，首要是避免内存泄露，其次是检查内存泄露。

1)不用new

c++程序，尽可能多用stl，避免用new。我本身写的代码，除了在main函数里面有new外，其余地方不会再有任何new出现。这样就把内存管理交给stl去作。

或许你会说，不用new怎么可能啊？

很简单，char数组用std::string代替，其余对象直接拷贝。除非你的对象很大很大，不然，一点点拷贝耗时，彻底能够忽略不计。

2)每一个重要结构都提供Info函数

给你的每一个重要结构都加上一个Info函数，info函数返回一个string，描述当前结构的状态，如map的大小，内存占用的大小。在最顶层，不定时的输出（或者根据命令输出）各个对象的info结果。这样能够避免隐形的内存泄露，即不是内存泄露，但某个对象保持的大量对象的引用，致使对象没法被删除；

即某个对象内部的map，不断的添加数据，也在不断的删除数据，但在某些特殊状况下，它不会删除。

3)stl内存泄露的问题

stl几乎没有内存泄露，但它有一个内存cache，这个cache对小对象的分配很友好。stl的一个麻烦是，它几乎不会释放这些空间，这样的一个结果是，你看到本身的程序内存占用不断的上涨。其实，理论上是不用惧怕的，由于它涨到必定范围（如，机器只有几百兆可用空间了），就不会涨了。能够经过在运行程序前，export GLIBCXX_FORCE_NEW=1，来让stl不要进行cache。注意，这个仅仅在gcc(g++) 3.3之后有效。

4)valgrind等内存检测工具

 直接下载，编译（注意，必须在configure的当前目录下执行configure，不能另外选一个目录），安装。执行：valgrind --num-callers=20 --leak-check=full --leak-resolution=high --show-reachable=yes --log-file=val.log xxx &，等过了几天后，把它kill,而后慢慢的看val.log文件。

当你采用了前面3个策略后，valgrind几乎没有啥效果，反正我历来没有从它这里得到任何有用的信息过。主要是由于前面几步保证了没有显式的内存泄露，因此，valgrind也就找不出来啥内存泄露了。

5)valgrind的工具massif

massif比valgrind好的地方在于，它会告诉你当前内存的分布状况。你能够看到占用了几百兆的程序究竟是那些地方占用了内存。执行：valgrind --tool=massif xxx。通常经过这个均可以看到明显的内存泄露。这个工具很好，俺用它发现了一个十分异常的状况，这个状况是由vector的reserve致使的。原本应该reserve返回数据的个数，结果reserve了命中结果的个数。致使偶尔会出现内存占用过500M的状况，但由于没有内存泄露，因此其余几个工具都找不出来，就只有massif提供的堆栈快照能够发现这个问题。

• 文章来源:c/c++服务器程序内存泄露问题分析及解决