内存问题Word文档格式.docx
《内存问题Word文档格式.docx》由会员分享，可在线阅读，更多相关《内存问题Word文档格式.docx（12页珍藏版）》请在冰豆网上搜索。
然而，有不少人习惯于把任何不需要的内存使用的增加描述为内存泄漏，即使严格意义上来说这是不准确的。
一般我们常说的内存泄漏是指堆内存的泄漏。
堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。
应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。
·
后果...............................................
内存泄漏会因为减少可用内存的数量从而降低计算机的性能。
最终，在最糟糕的情况下，过多的可用内存被分配掉导致全部或部分设备停止正常工作，或者应用程序崩溃。
内存泄漏可能不严重，甚至能够被常规的手段检测出来。
在现代操作系统中，一个应用程序使用的常规内存在程序终止时被释放。
这表示一个短暂运行的应用程序中的内存泄漏不会导致严重后果。
在以下情况，内存泄漏导致较严重
后果：
*程序运行后置之不理，并且随着时间的流失消耗越来越多的内存（比如服务器上的后台任务，尤其是嵌入式系统中的后台任务，这些任务可能被运行后很多年内都置之不理）；
*新的内存被频繁地分配，比如当显示电脑游戏或动画视频画面时；
*程序能够请求未被释放的内存（比如共享内存），甚至是在程序终止的时候；
*泄漏在操作系统内部发生；
*泄漏在系统关键驱动中发生；
*内存非常有限，比如在嵌入式系统或便携设备中；
*当运行于一个终止时内存并不自动释放的操作系统（比如AmigaOS）之上，而且一旦丢失只能通过重启来恢复。
一般我们常说的内存泄漏是指堆内存的泄漏。
堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。
应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。
以下这段小程序演示了堆内存发生泄漏的情形：
voidMyFunction（intnSize）
{
char*p=newchar[nSize];
if（!
GetStringFrom（p,nSize））{
MessageBox（“Error”）;
return;
}
…//usingthestringpointedbyp;
deletep;
}
例一
当函数GetStringFrom（）返回零的时候，指针p指向的内存就不会被释放。
这是一种常见的发生内存泄漏的情形。
程序在入口处分配内存，在出口处释放内存，但是c函数可以在任何地方退出，所以一旦有某个出口处没有释放应该释放的内存，就会发生内存泄漏。
广义的说，内存泄漏不仅仅包含堆内存的泄漏，还包含系统资源的泄漏（resourceleak），比如核心态HANDLE，GDIObject，SOCKET，Interface等，从根本上说这些由操作系统分配的对象也消耗内存，如果这些对象发生泄漏最终也会导致内存的泄漏。
而且，某些对象消耗的是核心态内存，这些对象严重泄漏时会导致整个操作系统不稳定。
所以相比之下，系统资源的泄漏比堆内存的泄漏更为严重。
GDIObject的泄漏是一种常见的资源泄漏：
voidCMyView:
:
OnPaint（CDC*pDC）
CBitmapbmp;
CBitmap*pOldBmp;
bmp.LoadBitmap（IDB_MYBMP）;
pOldBmp=pDC->
SelectObject（&
bmp）;
…
if（Something（））{
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;
voidSetFileName（constchar*lpcszFileName）
if（g_lpszFileName）{
free（g_lpszFileName）;
g_lpszFileName=strdup（lpcszFileName）;
例三
如果程序在结束的时候没有释放g_lpszFileName指向的字符串，那么，即使多次调用SetFileName（），总会有一块内存，而且仅有一块内存发生泄漏。
4.隐式内存泄漏。
程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。
严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。
但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。
所以，我们称这类内存泄漏为隐式内存泄漏。
举一个例子：
classConnection
public:
Connection（SOCKETs）;
~Connection（）;
…
private:
SOCKET_socket;
};
classConnectionManager
ConnectionManager（）{}
~ConnectionManager（）{
list:
iteratorit;
for（it=_connlist.begin（）;
it!
=_connlist.end（）;
++it）{
delete（*it）;
}
_connlist.clear（）;
}
voidOnClientConnected（SOCKETs）{
Connection*p=newConnection（s）;
_connlist.push_back（p）;
voidOnClientDisconnected（Connection*pconn）{
_connlist.remove（pconn）;
deletepconn;
list_connlist;
例四
假设在Client从Server端断开后，Server并没有呼叫OnClientDisconnected（）函数，那么代表那次连接的Connection对象就不会被及时的删除（在Server程序退出的时候，所有Connection对象会在ConnectionManager的析构函数里被删除）。
当不断的有连接建立、断开时隐式内存泄漏就发生了。
从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。
真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。
从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。
检测内存泄漏
检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。
截获住这两个函数，我们就能跟踪每一块内存的生命周期，比如，每当成功的分配一块内存后，就把它的指针加入一个全局的list中；
每当释放一块内存，再把它的指针从list中删除。
这样，当程序结束的时候，list中剩余的指针就是指向那些没有被释放的内存。
这里只是简单的描述了检测内存泄漏的基本原理，详细的算法可以参见SteveMaguire的<
<
WritingSolidCode>
>
。
如果要检测堆内存的泄漏，那么需要截获住malloc/realloc/free和new/delete就可以了（其实new/delete最终也是用malloc/free的，所以只要截获前面一组即可）。
对于其他的泄漏，可以采用类似的方法，截获住相应的分配和释放函数。
比如，要检测BSTR的泄漏，就需要截获SysAllocString/SysFreeString；
要检测HMENU的泄漏，就需要截获CreateMenu/DestroyMenu。
（有的资源的分配函数有多个，释放函数只有一个，比如，SysAllocStringLen也可以用来分配BSTR，这时就需要截获多个分配函数）
在Windows平台下，检测内存泄漏的工具常用的一般有三种，MSC-RuntimeLibrary内建的检测功能；
外挂式的检测工具，诸如，Purify
升级会员 