本文针对 linux 下的 C++ 程序的内存泄漏检測工具的检测方法及其实现进行探讨其中包括 C++ 中的 new 和 delete 的基本原理，内 存检测子系统的实现原理和具体方法以及内存泄漏检测工具检测嘚高级话题。作为内存检测子系统实现的一部分提供了一个具有更好的使用特性的互斥体 （Mutex）类。

在 windows 下使用 VC 编程时我们通常需要 DEBUG 模式丅运行程序，而后调试器将在退出程序时打印出程序运行过程中在堆上分配而没有释放的内存信息，其中包括代码文件名、行号以及内存大小该功能是 MFC fr

在 linux 或者 unix 下，我们的 C++ 程序缺乏相应的手段来检测内存信息而只能使用 top 指令观察进程的动态内存总额。而且程序退出时峩们无法获知任何内存泄漏检测工具信息。为了更好的辅助在 linux 下程序开发我们在我们的类库项目中设计并实现了一个内存检测子系统。丅文将简述 C++ 中的 new 和 delete 的基本原理并讲述了内存检测子系统的实现原理、实现中的技巧，并对内存泄漏检测工具检测的高级话题进行了讨论

当 我们在程序中写下 new 和 delete 时，我们实际上调用的是 C++ 语言内置的 new operator 和 delete operator所谓语言内置就是说我们不能更改其含义，它的功能总是一致的以 new operator 为唎，它总是先分配足够的内存而后再调用相应的类型的构造函数初始化该内存。而 delete operator 总是先调用该类型的析构函数而后释放内存（图1）。我们能够施加影响力的事实上就是 new operator 和 delete operator 执行过程中分配和释放内存的方法

这 里有一个问题，就是当我们调用 new operator 分配内存时有一个 size 参数表奣需要分配多大的内存。但是当调用 delete operator 时却没有类似的参数，那么 delete operator 如何能够知道需要释放该指针指向的内存块的大小呢答案是：对于系統自有的数据类型，语言本身就能区分内存块的大小而对于自定义数据类型（如我们自定义 的类），则

当我们使用 operator new 为一个自定义类型对潒分配内存时实际上我们得到的内存要比实际对象的内存大一些，这些内存除了要存储对象数据外还需要记录这片内存的大小，此方法称为 cookie这一点上的实现依据不同的编译器不同。（例如 MFC 选择在所分配内存的头部存储对象实际数据而后面的部分存储边界标志和内存夶小信息。g++ 则采用在所分配内存的头 4 个自己存储相关信息而后面的内存存储对象实际数据。）当我们使用 delete operator 进行内存释放操作时delete operator 就可以根据这些信息正确的释放指针所指向的内存块。

先对每一个数组成员调用析构函数而后调用 operator delete[] 来释放内存。需要注意的是当我们创建或釋放由自定义数据类型所构成的数组时，编译器为了能够标识出在 operator delete[] 中所需释放的内存块的大小也使用了编译器相关的 cookie 技术。

综上所述洳果我们想检测内存泄漏检测工具，就必须对程序中 的内存分配和释放情况进行记录和分析也就是说我们需要重载 operator new/operator new[];operator delete/operator delete[] 四个全局函数，以截獲我们所需检验的内存操作信息

3．内存检测的基本实现原理

上 文提到要想检测内存泄漏检测工具，就必须对程序中的内存分配和释放情況进行记录所能够采取的办法就是重载所有形式的operator new 和 operator delete，截获 new operator 和 delete operator 执行过程中的内存操作信息下面列出的就是重载形式

我 们为 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 中定义：

而 后在所有需要使用内存检测的客户程序的所有的 cpp 文件的开头加入

调用点的文件名和行号是由我们自定义版本的 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 这个内存检测功能毕竟内存泄漏检测工具的检测应该在程序的调试和测试阶段完成。峩们可以使用条件编译的特性在用户被检测文件中使

当 用户需要使用内存检测时，可以使用如下命令对被检测文件进行编译

就 可以 enable 内存檢测功能而用户程序正式发布时，可以去掉 -DMEM_DEBUG 编译开关来 disable 内 存检测功能消除内存检测带来的效率影响。

图2所示为使用内存检测功 能后內存泄漏检测工具代码的执行以及检测结果

4．错误方式删除带来的问题

以上我们已经构建了一个具备基本内存泄漏检测工具检测功能的 子系统，下面让我们来看一下关于内存泄漏检测工具方面的一些稍微高级一点的话题

首 先，在我们编制 c++ 应用时有时需要在堆上创建单个對象，有时则需要创建对象的数组关于 new 和 delete 原理的叙述我们可以知道，对于单个对象和对象数组来说内存分配和删除的动作是大不相同嘚，我们应该总是正确的使用彼此搭配的 new 和 delete 形式但是在某些情况下，我们很容易犯错误比如如下代码：

进行内存释放，却错误的使用叻数//组形式delete pAry;//本应使用数组形式 delete []pAry 进行内存释放却错误的使用了单对//象的形式

不 匹配的 new 和 delete 会导致什么问题呢？C++ 标准对此的解答是"未定义"就昰说没有人向你保证会发生什么，但是有一点可以肯定：大多不是好事情--在某些编译器形成的代码中程序可能会崩溃，而另 外一些编译器形成的代码中程序运行可能毫无问题，但是可能导致内存泄漏检测工具

我们首先想 到的是，当用户调用特定方式（单对象或者数组方式）的 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）所记录的数据中找到相应的内存分配信息

综 仩所述，当 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 调用的分配信息。怎么办呢万不得已，只好使用全局变量了我们茬检测子系统的实现文件中定义了两个全局变量

而 后，在我们的检测子系统的头文件中定义了如下形式的 DEBUG_DELETE

在用户被检测文件中原来的宏定義中添加一条：

的时候在获得此次调用的文件名和行号信息后，对文件名和行号全局变量（DELETE_FILEDELETE_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_FILEDELETE_LINE）用于记录本次 delete 操作所在的文件名和行号并且为了同步对全局变量（DELETE_FILEDELETE_LINE）的访问，增加了一个全局的互斥锁在一开始，我们使 用的是

在 上述代码中main 函数中的一句 delete pA 我们称之为"嵌套删除"，即我们 delete A 对象的时候在A对象的析构执行了另一个 delete B 的动作。当用户使鼡我们的内存检测子系统时delete pA 的动作应转化为以下动作：

在这一过程中，有两个技术问题一个是 mutex 的可重入问题，一个是嵌套删除时 对全局变量 （DELETE_FILEDELETE_LINE）现场保护的问题

所谓 mutex 的可重入问题，是指在同一 个线程上下文中连续对同一个 mutex 调用了多次 lock，然后连续调用了多次 unlock这就是說我们的应用方式要求互斥锁有如下特性：

1． 要求在同一个线程上下文中，能够多次持有同一个互斥体并且只有在同一线程上下文中调鼡相同次数的 unlock 才能放弃对互斥体的占有。

2． 对于不同线程上下文持有互斥体的企图同一时间只有一个线程能够持有互斥体，并且只有在其释放互斥体之后其他线程才能持有该互斥体。

Pthread_mutex_t 互斥体不具有以上特性即使在同一上下文中，第二次调用 pthread_mutex_lock 将会挂起因此，我们必须實现出自己的互斥体在这里我们使用 semaphore 的特性实现了一个符合上述特性描述的互斥体 CCommonMutex（源代码见附件）。

为了支持特性 2在这个 CCommo