原帖：http://blog.csdn.net/i_like_cpp/archive/2007/06/28/1669962.aspx
作者：許式偉 2006年11月某日

內(nèi)存管理是C++程序員的痛。我的《內(nèi)存管理變革》系列就是試圖討論更為有效的內(nèi)存管理方式，以杜絕（或減少）內(nèi)存泄漏，減輕C++程序員的負(fù)擔(dān)。由于工作忙的緣故，這個系列目前未完，暫停。
?
這篇短文我想換個方式，討論一下如何以最快的速度找到內(nèi)存泄漏。
?
確認(rèn)是否存在內(nèi)存泄漏
我們知道，MFC程序如果檢測到存在內(nèi)存泄漏，退出程序的時候會在調(diào)試窗口提醒內(nèi)存泄漏。例如：

class CMyApp : public CWinApp
{
public:
?? BOOL InitApplication()
?? {
?????? int* leak = new int[10];
?????? return TRUE;
?? }
};
產(chǎn)生的內(nèi)存泄漏報告大體如下：

Detected memory leaks!
Dumping objects ->
c:\work\test.cpp(186) : {52} normal block at 0x003C4410, 40 bytes long.
?Data: <??????????????? > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
這挺好。問題是，如果我們不喜歡MFC，那么難道就沒有辦法？或者自己做？

呵呵，這不需要。其實，MFC也沒有自己做。內(nèi)存泄漏檢測的工作是VC++的C運(yùn)行庫做的。也就是說，只要你是VC++程序員，都可以很方便地檢測內(nèi)存泄漏。我們還是給個樣例：

#include <crtdbg.h>

inline void EnableMemLeakCheck()
{
?? _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
}

void main()
{
?? EnableMemLeakCheck();
?? int* leak = new int[10];
}
?運(yùn)行（提醒：不要按Ctrl+F5，按F5），你將發(fā)現(xiàn)，產(chǎn)生的內(nèi)存泄漏報告與MFC類似，但有細(xì)節(jié)不同，如下：

Detected memory leaks!
Dumping objects ->
{52} normal block at 0x003C4410, 40 bytes long.
?Data: <??????????????? > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
為什么呢？看下面。

定位內(nèi)存泄漏由于哪一句話引起的
你已經(jīng)發(fā)現(xiàn)程序存在內(nèi)存泄漏。現(xiàn)在的問題是，我們要找泄漏的根源。

一般我們首先確定內(nèi)存泄漏是由于哪一句引起。在MFC中，這一點(diǎn)很容易。你雙擊內(nèi)存泄漏報告的文字，或者在Debug窗口中按F4，IDE就幫你定位到申請該內(nèi)存塊的地方。對于上例，也就是這一句：

?? int* leak = new int[10];

這多多少少對你分析內(nèi)存泄漏有點(diǎn)幫助。特別地，如果這個new僅對應(yīng)一條delete（或者你把delete漏寫），這將很快可以確認(rèn)問題的癥結(jié)。

我們前面已經(jīng)看到，不使用MFC的時候，生成的內(nèi)存泄漏報告與MFC不同，而且你立刻發(fā)現(xiàn)按F4不靈。那么難道MFC做了什么手腳？

其實不是，我們來模擬下MFC做的事情。看下例：

inline void EnableMemLeakCheck()
{
?? _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
}

#ifdef _DEBUG
#define new?? new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif

void main()
{
?? EnableMemLeakCheck();
?? int* leak = new int[10];
}

再運(yùn)行這個樣例，你驚喜地發(fā)現(xiàn)，現(xiàn)在內(nèi)存泄漏報告和MFC沒有任何分別了。

快速找到內(nèi)存泄漏
單確定了內(nèi)存泄漏發(fā)生在哪一行，有時候并不足夠。特別是同一個new對應(yīng)有多處釋放的情形。在實際的工程中，以下兩種情況很典型：

創(chuàng)建對象的地方是一個類工廠（ClassFactory）模式。很多甚至全部類實例由同一個new創(chuàng)建。對于此，定位到了new出對象的所在行基本沒有多大幫助。
?
COM對象。我們知道COM對象采用Reference Count維護(hù)生命周期。也就是說，對象new的地方只有一個，但是Release的地方很多，你要一個個排除。
那么，有什么好辦法，可以迅速定位內(nèi)存泄漏？

答：有。

在內(nèi)存泄漏情況復(fù)雜的時候，你可以用以下方法定位內(nèi)存泄漏。這是我個人認(rèn)為通用的內(nèi)存泄漏追蹤方法中最有效的手段。

我們再回頭看看crtdbg生成的內(nèi)存泄漏報告：

Detected memory leaks!
Dumping objects ->
c:\work\test.cpp(186) : {52} normal block at 0x003C4410, 40 bytes long.
?Data: <??????????????? > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
除了產(chǎn)生該內(nèi)存泄漏的內(nèi)存分配語句所在的文件名、行號為，我們注意到有一個比較陌生的信息：{52}。這個整數(shù)值代表了什么意思呢？

其實，它代表了第幾次內(nèi)存分配操作。象這個例子，{52}代表了第52次內(nèi)存分配操作發(fā)生了泄漏。你可能要說，我只new過一次，怎么會是第52次？這很容易理解，其他的內(nèi)存申請操作在C的初始化過程調(diào)用的唄。:)

有沒有可能，我們讓程序運(yùn)行到第52次內(nèi)存分配操作的時候，自動停下來，進(jìn)入調(diào)試狀態(tài)？所幸，crtdbg確實提供了這樣的函數(shù)：即 long _CrtSetBreakAlloc(long nAllocID)。我們加上它：

inline void EnableMemLeakCheck()
{
?? _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
}

#ifdef _DEBUG
#define new?? new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif

void main()
{
?? EnableMemLeakCheck();
?? _CrtSetBreakAlloc(52);
?? int* leak = new int[10];
}
你發(fā)現(xiàn)，程序運(yùn)行到 int* leak = new int[10]; 一句時，自動停下來進(jìn)入調(diào)試狀態(tài)。細(xì)細(xì)體會一下，你可以發(fā)現(xiàn)，這種方式你獲得的信息遠(yuǎn)比在程序退出時獲得文件名及行號有價值得多。因為報告泄漏文件名及行號，你獲得的只是靜態(tài)的信息，然而_CrtSetBreakAlloc則是把整個現(xiàn)場恢復(fù)，你可以通過對函數(shù)調(diào)用棧分析（我發(fā)現(xiàn)很多人不習(xí)慣看函數(shù)調(diào)用棧，如果你屬于這種情況，我強(qiáng)烈推薦你去補(bǔ)上這一課，因為它太重要了）以及其他在線調(diào)試技巧，來分析產(chǎn)生內(nèi)存泄漏的原因。通常情況下，這種分析方法可以在5分鐘內(nèi)找到肇事者。

當(dāng)然，_CrtSetBreakAlloc要求你的程序執(zhí)行過程是可還原的（多次執(zhí)行過程的內(nèi)存分配順序不會發(fā)生變化）。這個假設(shè)在多數(shù)情況下成立。不過，在多線程的情況下，這一點(diǎn)有時難以保證。

?

附加說明：
對“內(nèi)存管理”相關(guān)的技術(shù)感興趣？這里可以看到我的所有關(guān)于內(nèi)存管理的文章。

?

本文來自CSDN博客，轉(zhuǎn)載請標(biāo)明出處： http://blog.csdn.net/i_like_cpp/archive/2007/06/28/1669962.aspx