對於一個c/c++程式設計師來說，記憶體洩漏是一個常見的也是令人頭疼的問題。已經有許多技術被研究出來以應對這個問題，比如Smart Pointer，Garbage Collection等。Smart Pointer技術比較成熟，STL中已經包含支援Smart Pointer的class，但是它的使用似乎並不廣泛，而且它也不能解決所有的問題；Garbage Collection技術在Java中已經比較成熟，但是在c/c++領域的發展並不順暢，雖然很早就有人思考在C++中也加入GC的支援。現實世界就是這樣的，作為一個c/c++程式設計師，記憶體洩漏是你心中永遠的痛。不過好在現在有許多工具能夠幫助我們驗證記憶體洩漏的存在，找出發生問題的程式碼。
一．記憶體洩漏的定義
一般我們常說的記憶體洩漏是指堆記憶體的洩漏。堆記憶體是指程式從堆中分配的，大小任意的（記憶體塊的大小可以在程式執行期決定），使用完後必須顯示釋放的記憶體。應用程式一般使用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 33 |
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的解構函式裡被刪除）。當不斷的有連線建立、斷開時隱式記憶體洩漏就發生了。
從使用者使用程式的角度來看，記憶體洩漏本身不會產生什麼危害，作為一般的使用者，根本感覺不到記憶體洩漏的存在。真正有危害的是記憶體洩漏的堆積，這會最終消耗盡系統所有的記憶體。從這個角度來說，一次性記憶體洩漏並沒有什麼危害，因為它不會堆積，而隱式記憶體洩漏危害性則非常大，因為較之於常發性和偶發性記憶體洩漏它更難被檢測到。