如何在 linux 下檢測記憶體流失

原文出處：
[url]http://www-900.ibm.com/developerWorks/cn/linux/l-mleak/index.shtml[/url]

洪琨 (hcode@21cn.com)
C++程式員
2003 年 6 月

本文針對 linux 下的 C++ 程式的記憶體流失的檢測方法及其實現進行探討。其中包括 C++ 中的 new 和 delete 的基本原理，記憶體檢測子系統的實現原理和具體方法，以及記憶體流失檢測的進階話題。作為記憶體檢測子系統實現的一部分，提供了一個具有更好的使用特性的互斥體（Mutex）類。

內容：

1．開發背景
2．New和delete的原理
3．記憶體檢測的基本實現原理
4．錯誤方式刪除帶來的問題
5．動態記憶體泄漏資訊的檢測
6．實現上的問題：嵌套delete
展望
參考資料
關於作者

在 Linux 專區還有：

教程
工具與產品
代碼與組件
文章

洪琨 (hcode@21cn.com)
C++程式員
2003 年 6 月
本文針對 linux 下的 C++ 程式的記憶體流失的檢測方法及其實現進行探討。其中包括 C++ 中的 new 和 delete 的基本原理，記憶體檢測子系統的實現原理和具體方法，以及記憶體流失檢測的進階話題。作為記憶體檢測子系統實現的一部分，提供了一個具有更好的使用特性的互斥體（Mutex）類。

1．開發背景：

在 windows 下使用 VC 編程時，我們通常需要 DEBUG 模式下運行程式，而後調試器將在退出程式時，列印出程式運行過程中在堆上分配而沒有釋放的記憶體資訊，其中包括代碼檔案名稱、行號以及記憶體大小。該功能是 MFC Framework 提供的內建機制，封裝在其類結構體系內部。

在 linux 或者 unix 下，我們的 C++ 程式缺乏相應的手段來檢測記憶體資訊，而只能使用 top 指令觀察進程的動態記憶體總額。而且程式退出時，我們無法獲知任何記憶體流失資訊。為了更好的輔助在 linux 下程式開發，我們在我們的類庫項目中設計並實現了一個記憶體檢測子系統。下文將簡述 C++ 中的 new 和 delete 的基本原理，並講述了記憶體檢測子系統的實現原理、實現中的技巧，並對記憶體流失檢測的進階話題進行了討論。

2．New和delete的原理

當我們在程式中寫下 new 和 delete 時，我們實際上調用的是 C++ 語言內建的 new operator 和 delete operator。所謂語言內建就是說我們不能更改其含義，它的功能總是一致的。以 new operator 為例，它總是先分配足夠的記憶體，而後再調用相應的類型的建構函式初始化該記憶體。而 delete operator 總是先調用該類型的解構函式，而後釋放記憶體（圖1）。我們能夠施加影響力的事實上就是 new operator 和 delete operator 執行過程中分配和釋放記憶體的方法。

new operator 為分配記憶體所調用的函數名字是 operator new，其通常的形式是 void * operator new(size_t size); 其傳回值類型是 void*，因為這個函數返回一個未經處理（raw）的指標，未初始化的記憶體。參數 size 確定分配多少記憶體，你能增加額外的參數重載函數 operator new，但是第一個參數類型必須是 size_t。

delete operator 為釋放記憶體所調用的函數名字是 operator delete，其通常的形式是 void operator delete(void *memoryToBeDeallocated)；它釋放傳入的參數所指向的一片記憶體區。

這裡有一個問題，就是當我們調用 new operator 分配記憶體時，有一個 size 參數表明需要分配多大的記憶體。但是當調用 delete operator 時，卻沒有類似的參數，那麼 delete operator 如何能夠知道需要釋放該指標指向的記憶體塊的大小呢？答案是：對於系統自有的資料類型，語言本身就能區分記憶體塊的大小，而對於自訂資料類型（如我們自訂的類），則 operator new 和 operator delete 之間需要互相傳遞資訊。

當我們使用 operator new 為一個自訂類型對象分配記憶體時，實際上我們得到的記憶體要比實際對象的記憶體大一些，這些記憶體除了要儲存物件資料外，還需要記錄這片記憶體的大小，此方法稱為 cookie。這一點上的實現依據不同的編譯器不同。（例如 MFC 選擇在所分配記憶體的頭部儲存物件實際資料，而後面的部分儲存邊界標誌和記憶體大小資訊。g++ 則採用在所分配記憶體的頭 4 個自己儲存相關資訊，而後面的記憶體儲存物件實際資料。）當我們使用 delete operator 進行記憶體釋放操作時，delete operator 就可以根據這些資訊正確的釋放指標所指向的記憶體塊。

以上論述的是對於單個對象的記憶體配置/釋放，當我們為數組分配/釋放記憶體時，雖然我們仍然使用 new operator 和 delete operator，但是其內部行為卻有不同：new operator 調用了operator new 的數組版的兄弟－ operator new[]，而後針對每一個數群組成員調用建構函式。而 delete operator 先對每一個數群組成員調用解構函式，而後調用 operator delete[] 來釋放記憶體。需要注意的是，當我們建立或釋放由自訂資料類型所構成的數組時，編譯器為了能夠標識出在 operator delete[] 中所需釋放的記憶體塊的大小，也使用了編譯器相關的 cookie 技術。

綜上所述，如果我們想檢測記憶體流失，就必須對程式中的記憶體配置和釋放情況進行記錄和分析，也就是說我們需要重載 operator new/operator new[];operator delete/operator delete[] 四個全域函數，以截獲我們所需檢驗的記憶體操作資訊。

3．記憶體檢測的基本實現原理：

上文提到要想檢測記憶體流失，就必須對程式中的記憶體配置和釋放情況進行記錄，所能夠採取的辦法就是重載所有形式的operator new 和 operator delete，截獲 new operator 和 delete operator 執行過程中的記憶體操作資訊。下面列出的就是重載形式

void* operator new( size_t nSize, char* pszFileName, int nLineNum )
void* operator new[]( size_t nSize, char* pszFileName, int nLineNum )
void operator delete( void *ptr )
void operator delete[]( void *ptr )

我們為 operator new 定義了一個新的版本，除了必須的 size_t nSize 參數外，還增加了檔案名稱和行號，這裡的檔案名稱和行號就是這次 new operator 操作符被調用時所在的檔案名稱和行號，這個資訊將在發現記憶體流失時輸出，以協助使用者定位泄漏具體位置。對於 operator delete，因為無法為之定義新的版本，我們直接覆蓋了全域的 operator delete 的兩個版本。

在重載的 operator new 函數版本中，我們將調用全域的 operator new 的相應的版本並將相應的 size_t 參數傳入，而後，我們將全域 operator new 返回的指標值以及該次分配所在的檔案名稱和行號資訊記錄下來，這裡所採用的資料結構是一個 STL 的 map，以指標值為 key 值。當 operator delete 被調用時，如果調用方式正確的話（調用方式不正確的情況將在後面詳細描述），我們就能以傳入的指標值在 map 中找到相應的資料項目並將之刪除，而後調用 free 將指標所指向的記憶體塊釋放。當程式退出的時候，map 中的剩餘的資料項目就是我們企圖檢測的記憶體流失資訊－－已經在堆上分配但是尚未釋放的分配資訊。

以上就是記憶體檢測實現的基本原理，現在還有兩個基本問題沒有解決：

1) 如何取得記憶體配置代碼所在的檔案名稱和行號，並讓 new operator 將之傳遞給我們重載的 operator new。

2) 我們何時建立用於儲存記憶體資料的 map 資料結構，如何管理，何時列印記憶體流失資訊。

先解決問題1。首先我們可以利用 C 的先行編譯宏 __FILE__ 和 __LINE__，這兩個宏將在編譯時間在指定位置展開為該檔案的檔案名稱和該行的行號。而後我們需要將預設的全域 new operator 替換為我們自訂的能夠傳入檔案名稱和行號的版本，我們在子系統標頭檔 MemRecord.h 中定義：

#define DEBUG_NEW new(__FILE__, __LINE__ )

而後在所有需要使用記憶體檢測的客戶程式的所有的 cpp 檔案的開頭加入

#include "MemRecord.h"
#define new DEBUG_NEW

就可以將客戶源檔案中的對於全域預設的 new operator 的調用替換為 new (__FILE__,__LINE__) 調用，而該形式的new operator將調用我們的operator new (size_t nSize, char* pszFileName, int nLineNum)，其中 nSize 是由 new operator 計算並傳入的，而 new 調用點的檔案名稱和行號是由我們自訂版本的 new operator 傳入的。我們建議在所有使用者自己的原始碼檔案中都加入上述宏，如果有的檔案中使用記憶體檢測子系統而有的沒有，則子系統將可能因無法監控整個系統而輸出一些泄漏警告。

再說第二個問題。我們用於管理客戶資訊的這個 map 必須在客戶程式第一次調用 new operator 或者 delete operator 之前被建立，而且在最後一個 new operator 和 delete operator 調用之後進行泄漏資訊的列印，也就是說它需要先於客戶程式而出生，而在客戶程式退出之後進行分析。能夠包容客戶程式生命週期的確有一人--全域對象（appMemory）。我們可以設計一個類來封裝這個 map 以及這對它的插入刪除操作，然後構造這個類的一個全域對象（appMemory），在全域對象（appMemory）的建構函式中建立並初始化這個資料結構，而在其解構函式中對資料結構中剩餘資料進行分析和輸出。Operator new 中將調用這個全域對象（appMemory）的 insert 介面將指標、檔案名稱、行號、記憶體塊大小等資訊以指標值為 key 記錄到 map 中，在 operator delete 中調用 erase 介面將對應指標值的 map 中的資料項目刪除，注意不要忘了對 map 的訪問需要進行互斥同步，因為同一時間可能會有多個線程進行堆上的記憶體操作。

好啦，記憶體檢測的準系統已經具備了。但是不要忘了，我們為了檢測記憶體流失，在全域的 operator new 增加了一層間接性，同時為了保證對資料結構的安全訪問增加了互斥，這些都會降低程式啟動並執行效率。因此我們需要讓使用者能夠方便的 enable 和 disable 這個記憶體檢測功能，畢竟記憶體流失的檢測應該在程式的調試和測試階段完成。我們可以使用條件編譯的特性，在使用者被檢測檔案中使用如下宏定義：

#include "MemRecord.h"
#if defined( MEM_DEBUG )
#define new DEBUG_NEW
#endif

當使用者需要使用記憶體檢測時，可以使用如下命令對被檢測檔案進行編譯

g++ -c -DMEM_DEBUG xxxxxx.cpp

就可以 enable 記憶體檢測功能，而使用者程式正式發布時，可以去掉 -DMEM_DEBUG 編譯開關來 disable 記憶體檢測功能，消除記憶體檢測帶來的效率影響。

圖2所示為使用記憶體檢測功能後，記憶體流失代碼的執行以及檢測結果

圖2

4．錯誤方式刪除帶來的問題

以上我們已經構建了一個具備基本記憶體流失檢測功能的子系統，下面讓我們來看一下關於記憶體流失方面的一些稍微進階一點的話題。

首先，在我們編製 c++ 應用時，有時需要在堆上建立單個對象，有時則需要建立對象的數組。關於 new 和 delete 原理的敘述我們可以知道，對於單個對象和對象數組來說，記憶體配置和刪除的動作是大不相同的，我們應該總是正確的使用彼此搭配的 new 和 delete 形式。但是在某些情況下，我們很容易犯錯誤，比如如下代碼：

class Test {};
……
Test* pAry = new Test[10];//建立了一個擁有 10 個 Test 對象的數組
Test* pObj = new Test;//建立了一個單對象
……
delete []pObj;//本應使用單對象形式 delete pObj 進行記憶體釋放，卻錯誤的使用了數
//組形式
delete pAry;//本應使用數組形式 delete []pAry 進行記憶體釋放，卻錯誤的使用了單對
//象的形式

不匹配的 new 和 delete 會導致什麼問題呢？C++ 標準對此的解答是"未定義"，就是說沒有人向你保證會發生什麼，但是有一點可以肯定：大多不是好事情--在某些編譯器形成的代碼中，程式可能會崩潰，而另外一些編譯器形成的代碼中，程式運行可能毫無問題，但是可能導致記憶體流失。

既然知道形式不匹配的 new 和 delete 會帶來的問題，我們就需要對這種現象進行毫不留情的揭露，畢竟我們重載了所有形式的記憶體操作 operator new，operator new[]，operator delete，operator delete[]。

我們首先想到的是，當使用者調用特定方式（單對象或者數組方式）的 operator new 來分配記憶體時，我們可以在指向該記憶體的指標相關的資料結構中，增加一項用於描述其分配方式。當使用者調用不同形式的 operator delete 的時候，我們在 map 中找到與該指標相對應的資料結構，然後比較分配方式和釋放方式是否匹配，匹配則在 map 中正常刪除該資料結構，不匹配則將該資料結構轉移到一個所謂 "ErrorDelete" 的 list 中，在程式最終退出的時候和記憶體流失資訊一起列印。

上面這種方法是最順理成章的，但是在實際應用中效果卻不好。原因有兩個，第一個原因我們上面已經提到了：當 new 和 delete 形式不匹配時，其結果"未定義"。如果我們運氣實在太差--程式在執行不匹配的 delete 時崩潰了，我們的全域對象（appMemory）中儲存的資料也將不複存在，不會列印出任何資訊。第二個原因與編譯器相關，前面提到過，當編譯器處理自訂資料類型或者自訂資料類型數組的 new 和 delete 操作符的時候，通常使用編譯器相關的 cookie 技術。這種 cookie 技術在編譯器中可能的實現方式是：new operator 先計算容納所有對象所需的記憶體大小，而後再加上它為記錄 cookie 所需要的記憶體量，再將總容量傳給operator new 進行記憶體配置。當 operator new 返回所需的記憶體塊後，new operator 將在調用相應次數的建構函式初始化有效資料的同時，記錄 cookie 資訊。而後將指向有效資料的指標返回給使用者。也就是說我們重載的 operator new 所申請到並記錄下來的指標與 new operator 返回給調用者的指標不一定一致（圖3）。當調用者將 new operator 返回的指標傳給 delete operator 進行記憶體釋放時，如果其調用形式相匹配，則相應形式的 delete operator 會作出相反的處理，即調用相應次數的解構函式，再通過指向有效資料的指標位置找出包含 cookie 的整塊記憶體位址，並將其傳給 operator delete 釋放記憶體。如果調用形式不匹配，delete operator 就不會做上述運算，而直接將指向有效資料的指標（而不是真正指向整塊記憶體的指標）傳入 operator delete。因為我們在 operator new 中記錄的是我們所分配的整塊記憶體的指標，而現在傳入 operator delete 的卻不是，所以就無法在全域對象（appMemory）所記錄的資料中找到相應的記憶體配置資訊。

圖3

綜上所述，當 new 和 delete 的調用形式不匹配時，由於程式有可能崩潰或者記憶體子系統找不到相應的記憶體配置資訊，在程式最終列印出 "ErrorDelete" 的方式只能檢測到某些"幸運"的不匹配現象。但我們總得做點兒什麼，不能讓這種危害極大的錯誤從我們眼前溜走，既然不能秋後算帳，我們就即時輸出一個 warning 資訊來提醒使用者。什麼時候拋出一個 warning 呢？很簡單，當我們發現在 operator delete 或 operator delete[] 被調用的時候，我們無法在全域對象（appMemory）的 map 中找到與傳入的指標值相對應的記憶體配置資訊，我們就認為應該提醒使用者。

既然決定要輸出warning資訊，那麼現在的問題就是：我們如何描述我們的warning資訊才能更便於使用者定位到不匹配刪除錯誤呢？答案：在 warning 資訊中列印本次 delete 調用的檔案名稱和行號資訊。這可有點困難了，因為對於 operator delete 我們不能向對象 operator new 一樣做出一個帶附加資訊的重載版本，我們只能在保持其介面原貌的情況下，重新定義其實現，所以我們的 operator delete 中能夠得到的輸入只有指標值。在 new/delete 調用形式不匹配的情況下，我們很有可能無法在全域對象（appMemory）的 map 中找到原來的 new 調用的分配資訊。怎麼辦呢？萬不得已，只好使用全域變數了。我們在檢測子系統的實現檔案中定義了兩個全域變數（DELETE_FILE, DELETE_LINE）記錄 operator delete 被調用時的檔案名稱和行號，同時為了保證並發的 delete 操作對這兩個變數訪問同步，還使用了一個 mutex（至於為什麼是 CCommonMutex 而不是一個 pthread_mutex_t，在"實現上的問題"一節會詳細論述，在這裡它的作用就是一個 mutex）。

char DELETE_FILE[ FILENAME_LENGTH ] = {0};
int DELETE_LINE = 0;
CCommonMutex globalLock;

而後，在我們的檢測子系統的標頭檔中定義了如下形式的 DEBUG_DELETE

extern char DELETE_FILE[ FILENAME_LENGTH ];
extern int DELETE_LINE;
extern CCommonMutex globalLock;//在後面解釋
#define DEBUG_DELETE globalLock.Lock(); /
if (DELETE_LINE != 0) BuildStack();/ （//見第六節解釋）
strncpy( DELETE_FILE, __FILE__,FILENAME_LENGTH - 1 );/
DELETE_FILE[ FILENAME_LENGTH - 1 ]= '/0'; /
DELETE_LINE = __LINE__; /
delete

在使用者被檢測檔案中原來的宏定義中添加一條：

#include "MemRecord.h"
#if defined( MEM_DEBUG )
#define new DEBUG_NEW
#define delete DEBUG_DELETE
#endif

這樣，在使用者被檢測檔案調用 delete operator 之前，將先獲得互斥鎖，然後使用調用點檔案名稱和行號對相應的全域變數（DELETE_FILE,DELETE_LINE）進行賦值，而後調用 delete operator。當 delete operator 最終調用我們定義的 operator delete 的時候，在獲得此次調用的檔案名稱和行號資訊後，對檔案名稱和行號全域變數（DELETE_FILE,DELETE_LINE）重新初始化並開啟互斥鎖，讓下一個掛在互斥鎖上的 delete operator 得以執行。

在對 delete operator 作出如上修改以後，當我們發現無法經由 delete operator 傳入的指標找到對應的記憶體配置資訊的時候，就列印包括該次調用的檔案名稱和行號的 warning。

天下沒有十全十美的事情，既然我們提供了一種針對錯誤方式刪除的提醒方法，我們就需要考慮以下幾種異常情況：

1． 使用者使用的第三方庫函數中有記憶體配置和釋放操作。或者使用者的被檢測進程中進行記憶體配置和釋放的實現檔案沒有使用我們的宏定義。由於我們替換了全域的 operator delete，這種情況下的使用者調用的 delete 也會被我們截獲。使用者並沒有使用我們定義的DEBUG_NEW 宏，所以我們無法在我們的全域對象（appMemory）資料結構中找到對應的記憶體配置資訊，但是由於它也沒有使用DEBUG_DELETE，我們為 delete 定義的兩個全域 DELETE_FILE 和 DELETE_LINE 都不會有值，因此可以不列印 warning。

2． 使用者的一個實現檔案調用了 new 進行記憶體配置工作，但是該檔案並沒有使用我們定義的 DEBUG_NEW 宏。同時使用者的另一個實現檔案中的代碼負責調用 delete 來刪除前者分配的記憶體，但不巧的是，這個檔案使用了 DEBUG_DELETE 宏。這種情況下記憶體檢測子系統會報告 warning，並列印出 delete 調用的檔案名稱和行號。

3． 與第二種情況相反，使用者的一個實現檔案調用了 new 進行記憶體配置工作，並使用我們定義的 DEBUG_NEW 宏。同時使用者的另一個實現檔案中的代碼負責調用 delete 來刪除前者分配的記憶體，但該檔案沒有使用 DEBUG_DELETE 宏。這種情況下，因為我們能夠找到這個記憶體配置的原始資訊，所以不會列印 warning。

4． 當出現嵌套 delete（定義可見"實現上的問題"）的情況下，以上第一和第三種情況都有可能列印出不正確的 warning 資訊，詳細分析可見"實現上的問題"一節。

你可能覺得這樣的 warning 太隨意了，有誤導之嫌。怎麼說呢？作為一個檢測子系統，對待有可能的錯誤我們所採取的原則是：寧可誤判，不可漏報。請大家"有則改之，無則加勉"。

5．動態記憶體泄漏資訊的檢測

上面我們所講述的記憶體流失的檢測能夠在程式整個生命週期結束時，列印出在程式運行過程中已經在堆上分配但是沒有釋放的記憶體配置資訊，程式員可以由此找到程式中"顯式"的記憶體流失點並加以改正。但是如果程式在結束之前能夠將自己所分配的所有記憶體都釋放掉，是不是就可以說這個程式不存在記憶體流失呢？答案：否！在編程實踐中，我們發現了另外兩種危害性更大的"隱式"記憶體流失，其表現就是在程式退出時，沒有任何記憶體流失的現象，但是在程式運行過程中，記憶體佔用量卻不斷增加，直到使整個系統崩潰。

1． 程式的一個線程不斷分配記憶體，並將指向記憶體的指標儲存在一個資料存放區中（如 list），但是在程式運行過程中，一直沒有任何線程進行記憶體釋放。當程式退出的時候，該資料存放區中的指標值所指向的記憶體塊被依次釋放。

2． 程式的N個線程進行記憶體配置，並將指標傳遞給一個資料存放區，由M個線程從資料存放區進行資料處理和記憶體釋放。由於 N 遠大於M，或者M個線程資料處理的時間過長，導致記憶體配置的速度遠大於記憶體被釋放的速度。但是在程式退出的時候，資料存放區中的指標值所指向的記憶體塊被依次釋放。

之所以說他危害性更大，是因為很不容易這種問題找出來，程式可能連續運行幾個十幾個小時沒有問題，從而通過了不嚴密的系統測試。但是如果在實際環境中 7×24 小時運行，系統將不定時的崩潰，而且崩潰的原因從 log 和程式表象上都查不出原因。

為了將這種問題也挑落馬下，我們增加了一個動態檢測模組 MemSnapShot，用於在程式運行過程中，每隔一定的時間間隔就對程式當前的記憶體總使用方式和記憶體配置情況進行統計，以使使用者能夠對程式的動態記憶體分配狀況進行監視。

當客戶使用 MemSnapShot 進程監視一個運行中的進程時，被監視進程的記憶體子系統將把記憶體配置和釋放的資訊即時傳送給MemSnapShot。MemSnapShot 則每隔一定的時間間隔就對所接收到的資訊進行統計，計算該進程總的記憶體使用量量，同時以調用new進行記憶體配置的檔案名稱和行號為索引值，計算每個記憶體配置動作所分配而未釋放的記憶體總量。這樣一來，如果在連續多個時間間隔的統計結果中，如果某檔案的某行所分配的記憶體總量不斷增長而始終沒有到達一個平衡點甚至回落，那它一定是我們上面所說到的兩種問題之一。

在實現上，記憶體檢測子系統的全域對象（appMemory）的建構函式中以自己的當前 PID 為基礎 key 值建立一個訊息佇列，並在operator new 和 operator delete 被調用的時候將相應的資訊寫入訊息佇列。MemSnapShot 進程啟動時需要輸入被檢測進程的 PID，而後通過該 PID 組裝 key 值並找到被檢測進程建立的訊息佇列，並開始讀入訊息佇列中的資料進行分析統計。當得到operator new 的資訊時，記錄記憶體配置資訊，當收到 operator delete 訊息時，刪除相應的記憶體配置資訊。同時啟動一個分析線程，每隔一定的時間間隔就計算一下當前的以分配而尚未釋放的記憶體資訊，並以記憶體的分配位置為關鍵字進行統計，查看在同一位置（相同檔案名稱和行號）所分配的記憶體總量和其占進程總記憶體量的百分比。

圖4 是一個正在啟動並執行 MemSnapShot 程式，它所監視的進程的動態記憶體分配情況：

圖四

在支援 MemSnapShot 過程中的實現上的唯一技巧是--對於被檢測進程異常退出狀況的處理。因為被檢測進程中的記憶體檢測子系統建立了用於進程間傳輸資料的訊息佇列，它是一個核心資源，其生命週期與核心相同，一旦建立，除非顯式的進行刪除或系統重啟，否則將不被釋放。

不錯，我們可以在記憶體檢測子系統中的全域對象（appMemory）的解構函式中完成對訊息佇列的刪除，但是如果被檢測進程非正常退出（CTRL +C，段錯誤崩潰等），訊息佇列可就沒人管了。那麼我們可以不可以在全域對象（appMemory）的建構函式中使用 signal 系統調用註冊 SIGINT，SIGSEGV 等系統訊號處理函數，並在處理函數中刪除訊息佇列呢？還是不行，因為被檢測進程完全有可能註冊自己的對應的訊號處理函數，這樣就會替換我們的訊號處理函數。最終我們採取的方法是利用 fork 產生一個孤兒進程，並利用這個進程監視被檢測進程的生存狀況，如果被檢測進程已經退出（無論正常退出還是異常退出），則試圖刪除被檢測進程所建立的訊息佇列。下面簡述其實現原理：

在全域對象（appMemory）建構函式中，建立訊息佇列成功以後，我們調用 fork 建立一個子進程，而後該子進程再次調用 fork 建立孫子進程，並退出，從而使孫子進程變為一個"孤兒"進程（之所以使用孤兒進程是因為我們需要切斷被檢測進程與我們建立的進程之間的訊號聯絡）。孫子進程利用父進程（被檢測進程）的全域對象（appMemory）得到其 PID 和剛剛建立的訊息佇列的標識，並傳遞給調用 exec 函數產生的一個新的程式映象--MemCleaner。

MemCleaner 程式僅僅調用 kill(pid, 0);函數來查看被檢測進程的生存狀態，如果被檢測進程不存在了（正常或者異常退出），則 kill 函數返回非 0 值，此時我們就動手清除可能存在的訊息佇列。

6．實現上的問題：嵌套delete

在"錯誤方式刪除帶來的問題"一節中，我們對 delete operator 動了個小手術--增加了兩個全域變數（DELETE_FILE,DELETE_LINE）用於記錄本次 delete 操作所在的檔案名稱和行號，並且為了同步對全域變數（DELETE_FILE,DELETE_LINE）的訪問，增加了一個全域的互斥鎖。在一開始，我們使用的是 pthread_mutex_t，但是在測試中，我們發現 pthread_mutex_t 在本應用環境中的局限性。

例如如下代碼：

class B {…};
class A {
public:
A() {m_pB = NULL};
A(B* pb) {m_pB = pb;};
~A()
{
if (m_pB != NULL)
行號1delete m_pB;//這句最要命
};
private:
class B* m_pB;
……
}
int main()
{
A* pA = new A(new B);
……
行號2delete pA;
}

在上述代碼中，main 函數中的一句 delete pA 我們稱之為"嵌套刪除"，即我們 delete A 對象的時候，在A對象的析構執行了另一個 delete B 的動作。當使用者使用我們的記憶體檢測子系統時，delete pA 的動作應轉化為以下動作：

上全域鎖
全域變數（DELETE_FILE,DELETE_LINE）賦值為檔案名稱和行號2
delete operator A
調用~A()
上全域鎖
全域變數（DELETE_FILE,DELETE_LINE）賦值為檔案名稱和行號1
delete operator B
調用~B()
返回~B()
調用operator delete B
記錄全域變數（DELETE_FILE,DELETE_LINE）值1並清除全域變數（DELETE_FILE,DELETE_LINE）值
開啟全域鎖
返回operator delete B
返回delete operator B
返回~A()
調用 operator delete A
記錄全域變數（DELETE_FILE,DELETE_LINE）值1並清除全域變數（DELETE_FILE,DELETE_LINE）值
開啟全域鎖
返回operator delete A
返回 delete operator A

在這一過程中，有兩個技術問題，一個是 mutex 的可重新進入問題，一個是嵌套刪除時對全域變數（DELETE_FILE,DELETE_LINE）現場保護的問題。

所謂 mutex 的可重新進入問題，是指在同一個線程上下文中，連續對同一個 mutex 調用了多次 lock，然後連續調用了多次 unlock。這就是說我們的應用方式要求互斥鎖有如下特性：

1． 要求在同一個線程上下文中，能夠多次持有同一個互斥體。並且只有在同一線程上下文中調用相同次數的 unlock 才能放棄對互斥體的佔有。

2． 對於不同線程上下文持有互斥體的企圖，同一時間只有一個線程能夠持有互斥體，並且只有在其釋放互斥體之後，其他線程才能持有該互斥體。

Pthread_mutex_t 互斥體不具有以上特性，即使在同一上下文中，第二次調用 pthread_mutex_lock 將會掛起。因此，我們必須實現出自己的互斥體。在這裡我們使用 semaphore 的特性實現了一個符合上述特性描述的互斥體 CCommonMutex（原始碼見附件）。

為了支援特性 2，在這個 CCommonMutex 類中，封裝了一個 semaphore，並在建構函式中令其資源值為 1，初始值為1。當調用 CCommonMutex::lock 介面時，調用 sem_wait 得到 semaphore，使訊號量的資源為 0 從而讓其他調用 lock 介面的線程掛起。當調用介面 CCommonMutex::unlock 時，調用 sem_post 使訊號量資源恢複為 1，讓其他掛起的線程中的一個持有訊號量。

同時為了支援特性 1，在這個 CCommonMutex 增加了對於當前線程 pid 的判斷和當前線程訪問計數。當線程第一次調用 lock 介面時，我們調用 sem_wait 的同時，記錄當前的 Pid 到成員變數 m_pid，共置訪問計數為 1，同一線程（m_pid == getpid()）其後的多次調用將只進行計數而不掛起。當調用 unlock 介面時，如果計數不為 1，則只需遞減訪問計數，直到遞減訪問計數為 1 才進行清除 pid、調用 sem_post。（具體代碼可見附件）

嵌套刪除時對全域變數（DELETE_FILE,DELETE_LINE）現場保護的問題是指，上述步驟中在 A 的解構函式中調用 delete m_pB 時，對全域變數（DELETE_FILE,DELETE_LINE）檔案名稱和行號的賦值將覆蓋主程式中調用 delete pA 時對全域變數（DELETE_FILE,DELETE_LINE）的賦值，造成了在執行 operator delete A 時，delete pA 的資訊全部丟失。

要想對這些全域資訊進行現場保護，最好用的就是堆棧了，在這裡我們使用了 STL 提供的 stack 容器。在 DEBUG_DELETE 宏定義中，對全域變數（DELETE_FILE,DELETE_LINE）賦值之前，我們先判斷是否前面已經有人對他們賦過值了--觀察行號變數是否等於 0，如果不為 0，則應該將已有的資訊壓棧（調用一個全域函數 BuildStack() 將當前的通用檔案名和行號資料壓入一個全域堆棧globalStack），而後再對全域變數（DELETE_FILE,DELETE_LINE）賦值，再調用 delete operator。而在記憶體子系統的全域對象（appMemory）提供的 erase 介面裡面，如果判斷傳入的檔案名稱和行號為 0，則說明我們所需要的資料有可能被嵌套刪除覆蓋了，所以需要從堆棧中彈出相應的資料進行處理。

現在嵌套刪除中的問題基本解決了，但是當嵌套刪除與 "錯誤方式刪除帶來的問題"一節的最後所描述的第一和第三種異常情況同時出現的時候，由於使用者的 delete 調用沒有通過我們定義的 DEBUG_DELETE 宏，上述機制可能出現問題。其根本原因是我們利用stack 保留了經由我們的 DEBUG_DELETE 宏記錄的 delete 資訊的現場，以便在 operator delete 和全域對象（appMemory）的 erase 介面中使用，但是使用者的沒經過 DEBUG_DELETE 宏的 delete 操作卻未曾進行壓棧操作而直接調用了 operator delete，有可能將不屬於這次操作的 delete 資訊彈出，破壞了堆棧資訊的順序和有效性。那麼，當我們因為無法找到這次及其後續的 delete 操作所對應的記憶體配置資訊的時候，可能會列印出錯誤的 warning 資訊。

展望

以上就是我們所實現的記憶體流失檢測子系統的原理和技術方案，第一版的原始碼在附件中，已經經過了較嚴格的系統測試。但是限於我們的 C++ 知識水平和編程功底，在實現過程中肯定還有沒有注意到的地方甚至是缺陷，希望能夠得到大家的指正，我的 email 是 hcode@21cn.com。

在我們所實現的記憶體檢測子系統基礎上，可以繼續搭建記憶體配置最佳化子系統，從而形成一個完整的記憶體子系統。一種記憶體配置最佳化子系統的實現方案是一次性分配大塊的記憶體，並使用特定的資料結構管理之，當記憶體配置請求到來時，使用特定演算法從這塊大記憶體中劃定所需的一塊給使用者使用，而使用者使用完畢，在將其劃為空白閑記憶體。這種記憶體最佳化方式將記憶體配置釋放轉換為簡單的資料處理，極大的減少了記憶體申請和釋放所耗費的時間。

參考資料

1． 《More effective C++》Scott Meyers，候捷譯

2． 《Effective c++》Scott Meyers，候捷譯

3． 《深度探索C++物件模型》Stanley B.Lippman，候捷譯

4． 《Unix環境進階編程》W.Richard Stevens，尤晉元等譯

5． 原始碼：檢測子系統、動態記憶體監測、自訂的 mutex 類的原始碼、簡單的示範程式

作者簡介

洪琨，C++程式員。對應用系統設計和設計模式應用有著濃厚的興趣，樂於研究如何使用物件導向技術構建系統和建立可重用組件。mail：hcode@21cn.com。

堅決打倒M$以及其走狗SCO近期的無恥行為！！！