内存泄露小结

内存泄露小结

什么是内存泄露
    在编程时进行动态内存分配是非常必要的。它可以在程序运行的过程中帮助分配所需的内存，而不是在进程启动的时候就进行分配。当以前分配的一片内存不再需要使用或无法访问时，但是却并没有释放它，那么对于该进程来说，会因此导致总可用内存的减少，这时就出现了内存泄漏。
    在计算机科学中，内存泄漏(memory leak)指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。内存泄漏与许多其他问题有着相似的症状，并且通常情况下只能由那些可以获得程序源代码的程序员才可以分析出来。然而，有不少人习惯于把任何不需要的内存使用的增加描述为内存泄漏，严格意义上来说这是不准确的。
　　一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显式释放的内存。应用程序一般使用malloc，calloc，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函数可以在任何地方退出，所以一旦有某个出口处没有释放应该释放的内存，就会发生内存泄漏。

内存泄露的后果
        内存泄漏会因为减少可用内存的数量从而降低计算机的性能。最终，在最糟糕的情况下，过多的可用内存被分配掉导致全部或部分设备停止正常工作，或者应用程序崩溃。
        以下例子无需任何程式设计上的知识，但能表明如何导致内存泄漏及其造成的影响。注意以下的例子是虚构的。
　　在此例中的应用程式是一个简单软件的一小部分，FreeEIM用来控制升降机的运作。此部分软件当乘客在升降机内按下一楼层的按钮时运行。
　　当按下按钮时：
　　1.得到内存，用作记住目的楼层；
　　2.把目的楼层的数字存储到内存；
　　3.升降机是否已到达目的楼层？
　　如是，没有任何事需要做：程式完成
　　否则：
　　（1）.等待直至升降机停止；
　　（2）.到达指定楼层；
　　（3）.把刚才用作记住目的楼层的内存释出。
　　此程式有一处会造成内存泄漏。如果在升降机所在楼层按下该层的按钮，内存就会一直被占用而不再释放。这种情况发生得越多，泄漏的内存则越多。
　　这个小错误不会造成即时影响。因为人不会经常在升降机所在楼层按下同一层的按钮。而且在通常情况下，升降机应有足够的内存以应付上百次、上千次类似的情况。不过，升降机最后仍有可能消耗完所有内存。这可能需要数个月或是数年，所以在简单的测试下这个问题不会被发现。
　　而这个例子导致的后果会是不那么令人愉快。至少，升降机不会再响应前往其他楼层的要求。更严重的是，如果程式需要内存去开启升降机门，那可能有人被困升降机内，因为升降机没有足够的内存去开启升降机门。
　　内存泄漏只会在程式运行的时间内持续。例如：关闭升降机的电源时，程式终止运行。当电源再度开启，程式会再次运行而内存会重置，而这种缓慢的泄漏亦会从头开始再次发生。

自动内存管理
    内存泄漏是程式设计中一项常见错误，特别是使用没有内置自动垃圾回收的编程语言，如C及C++。一般情况下，内存泄漏发生是因为不能存取动态分配的内存。目前有相当数量的调试工具用于检测不能存取的内存，从而可以防止内存泄漏问题，如IBM Rational Purify、BoundsChecker、Valgrind、Insure++及memwatch都是为C/C++程式设计亦较受欢迎的内存除错工具。飞鸽传书垃圾回收则可以应用到任何编程语言，而C/C++也有此类函式库。
　　提供自动内存管理的编程语言如Java、VB、.NET（.Net内存泄露）以及LISP，都不能避免内存泄漏。例如，程式会把项目加入至列表，但在完成时没有移除，如同人把物件丢到一堆物品中或放到抽屉内，但后来忘记取走这件物品一样。内存管理器不能判断项目是否将再被存取，除非程式作出一些指示表明不会再被存取。
　　虽然内存管理器可以回复不能存取的内存，但它不可以释放可存取的内存因为仍有可能需要使用。现代的内存管理器因此为程式设计员提供技术来标示内存的可用性，以不同级别的“存取性”表示。内存管理器不会把需要存取可能较高的对象释放。当对象直接和一个强引用相关或者间接和一组强引用相关表示该对象存取性较强。（强引用相对于弱引用，是防止对象被回收的一个引用。）要防止此类内存泄漏，开发者必须使用对象后清理引用，一般都是在不再需要时将引用设成null，如果有可能，把维持强引用的事件侦听器全部注销。
　　一般来说，自动内存管理对开发者来讲比较方便，因为他们不需要实现释放的动作，或担心清理内存的顺序，而不用考虑对象是否依然被引用。对开发者来说，了解一个引用是否有必要保持比了解一个对象是否被引用要简单得多。但是，自动内存管理不能消除所有的内容泄漏。


C++中内存泄漏的检测
文章来自：http://blog.csdn.net/phinecos/article/details/4745720

首先我们需要知道程序有没有内存泄露，然后定位到底是哪行代码出现内存泄露了，这样才能将其修复。
最简单的方法当然是借助于专业的检测工具，比较有名如BoundsCheck,功能非常强大，相信做C++开发的人都离不开它。此外就是不使用任何工具，
而是自己来实现对内存泄露的监控，分如下两种情况：

一. 在 MFC 中检测内存泄漏
假如是用MFC的程序的话，很简单。默认的就有内存泄露检测的功能。
我们用VS2005生成了一个MFC的对话框的程序,发现他可以自动的检测内存泄露.不用我们做任何特殊的操作. 仔细观察,发现在每个CPP文件中,都有下面的代码:
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
DEBUG_NEW 这个宏定义在afx.h文件中，就是它帮助我们定位内存泄漏。

 在含有以上代码的cpp文件中分配内存后假如没有删除，那么停止程序的时候，VisualStudio的Output窗口就会显示如下的信息了：
Detected memory leaks!
Dumping objects ->
d:/code/mfctest/mfctest.cpp(80) : {157} normal block at 0x003AF170, 4 bytes long.
 Data: < > 00 00 00 00 
Object dump complete.
在Output窗口双击粗体字那一行，那么IDE就会打开该文件，定位到该行，很容易看出是哪出现了内存泄露。

二．检测纯C++的程序内存泄露
我试了下用VisualStudio建立的Win32 Console Application和Win32 Project项目，结果都不能检测出内存泄露。
下面一步一步来把程序的内存泄露检测的机制建立起来。
首先，我们需要知道C运行库的Debug版本提供了许多检测功能，使得我们更容易的Debug程序。在MSDN中有专门的章节讲这个，叫做Debug Routines，建议大家先看看里面的内容吧。
我们会用到里面很重要的几个函数。其中最重要的是 _CrtDumpMemoryLeaks();自己看MSDN里的帮助吧。使用这个函数，需要包含头文件crtdbg.h。
该函数只在Debug版本才有用，当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“Output(输出)”窗口中显示内存泄漏信息.写段代码试验一下吧，如下：

检测内存泄露版本一：
#include "stdafx.h"
#include <crtdbg.h>
int _tmain(int argc, _TCHAR* argv[])
{
    int* p = new int();
    _CrtDumpMemoryLeaks();
    return 0;
}
 运行后，在Output（输出）窗口，显示了如下的信息：
Detected memory leaks!
Dumping objects ->
{112} normal block at 0x003AA770, 4 bytes long.
 Data: <    > 00 00 00 00 
Object dump complete.
 但是这个只是告诉我们程序有内存泄露，到底在哪泄露了一眼看不出来啊。

看我们的检测内存泄露版本二：
#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
int _tmain(int argc, _TCHAR* argv[])
{
    int* p = new int();
    _CrtDumpMemoryLeaks();
    return 0;
}
  该程序定义了几个宏，通过宏将Debug版本下的new给替换了，新的new记录下了调用new时的文件名和代码行.运行后，可以看到如下的结果：
Detected memory leaks!
Dumping objects ->
d:/code/consoletest/consoletest.cpp(21) : {112} client block at 0x003A38B0, subtype 0, 4 bytes long.
 Data: <    > 00 00 00 00 
Object dump complete.
 呵呵，已经和MFC程序的效果一样了，但是等一等。看下如下的代码吧：
int _tmain(int argc, _TCHAR* argv[])
{
    int* p = new int();
    _CrtDumpMemoryLeaks();
    delete p;
    return 0;
}
运行后可以发现我们删除了指针，但是它仍然报内存泄露。所以可以想象，每调用一次new，程序内部都会将该调用记录下来，类似于有个数组记录，假如delete了，那么就将其从数组中删除，而_CrtDumpMemoryLeaks()就是把这个数组当前的状态打印出来。
所以除了在必要的时候Dump出内存信息外，最重要的就是在程序退出的时候需要掉用一次_CrtDumpMemoryLeaks();
假如程序有不止一个出口，那么我们就需要在多个地方都调用该函数。

更进一步，假如程序在类的析构函数里删除指针，怎么办？例如：
#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
class Test
{
public:
    Test()      {   _p = new int();     }
    ~Test()     {   delete _p;          }
    int* _p;
};
int _tmain(int argc, _TCHAR* argv[])
{
    int* p = new int();
    delete p;
    Test t;
    _CrtDumpMemoryLeaks();
    return 0;
}
可以看到析构函数在程序退出的时候才调用，明明没有内存泄露，但是这样的写法还是报了。
如何改进呢,看检测内存泄露版本三：
#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
class Test
{
public:
    Test()      {   _p = new int();     }
    ~Test()     {   delete _p;          }
    int* _p;
};
int _tmain(int argc, _TCHAR* argv[])
{
    _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
    int* p = new int();
    delete p;
    Test t;
    return 0;
}
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。

必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF。

这样，该版本已经达到了MFC一样的效果了,但是我觉得光这样还不够，因为我们只是在Output窗口中输出信息，对开发人员的提醒还不明显，经常会被遗漏，而且很多人就算发现了内存泄露，但是不好修复，不会严重影响到程序外在表现，都不会修复。怎么样能让开发人员主动的修复内存泄露的问题呢？记得曾经和人配合写程序，我的函数参数有要求，不能为空，但是别人老是传空值，没办法了，只好在函数开始验证函数参数，给他assert住，这样程序运行时老是不停的弹出assert，调试程序那个烦压，最后其他程序员烦了，就把这个问题给改好了，输入参数就正确了。所以我觉得咱要让程序员主动去做一件事，首先要让他觉得做这个事是能减轻自己负担，让自己工作轻松的。呵呵，那咱们也这样，当程序退出时，检测到内存泄露就让程序提示出来。

看检测内存泄露版本四：
#include "stdafx.h"
#include <assert.h>
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
void Exit()
{
    int i = _CrtDumpMemoryLeaks();
    assert( i == 0);
}
int _tmain(int argc, _TCHAR* argv[])
{
    atexit(Exit);
    int* p = new int();
    return 0;
}
该版本会在程序退出时检查内存泄露，假如存在就会弹出提示对话框。atexit(Exit);设置了在程序退出时执行Exit()函数。Exit()函数中,假如存在内存泄露，_CrtDumpMemoryLeaks()会返回非0值，就会被assert住了。
到这个版本已经达到可以使用的程度了。但是我们还可以做些改进，因为真要准确的检测到代码中所有的内存泄露，需要把代码中的#define……拷贝到所有使用new的文件中。不可能每个文件都拷贝这么多代码，所以我们可以将他提取出来，放在一个文件中，比如我是放在KDetectMemoryLeak.h中，该文件内容如下：
#pragma once
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif

然后将KDetectMemoryLeak.h包含在项目的通用文件中，例如用VS建的项目就将其包含在stdafx.h中。或者我自己建的一个Common.h文件中，该文件包含一些通用的，基本所有文件都会用到的代码。