天下没有十全十美的事情，既然我们提供了一种针对错误方式删除的提醒方法，我们就需要考虑以下几种异常情况：

　　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 消息时，删除相应的内存分配信息。同时启动一个分析线程，每隔一定的时间间隔就计算一下当前的以分配而尚未释放的内存信息，并以内存的分配位置为关键字进行统计，查看在同一位置（相同文件名和行号）所分配的内存总量和其占进程总内存量的百分比。

　　在支持 MemSnapShot 过程中的实现上的唯一技巧是--对于被检测进程异常退出状况的处理。因为被检测进程中的内存检测子系统创建了用于进程间传输数据的消息队列，它是一个核心资源，其生命周期与内核相同，一旦创建，除非显式的进行删除或系统重启，否则将不被释放。

　　不错，我们可以在内存检测子系统中的全局对象（appMemory）的析构函数中完成对消息队列的删除，但是如果被检测进程非正常退出（CTRL +C，段错误崩溃等），消息队列可就没人管了。那么我们可以不可以在全局对象（appMemory）的构造函数中使用 signal 系统调用注册 SIGINT，SIGSEGV 等系统信号处理函数，并在处理函数中删除消息队列呢？还是不行，因为被检测进程完全有可能注册自己的对应的信号处理函数，这样就会替换我们的信号处理函数。最终我们采取的方法是利用 fork 产生一个孤儿进程，并利用这个进程监视被检测进程的生存状况，如果被检测进程已经退出（无论正常退出还是异常退出），则试图删除被检测进程所创建的消息队列。下面简述其实现原理：

　　在全局对象（appMemory）构造函数中，创建消息队列成功以后，我们调用 fork 创建一个子进程，而后该子进程再次调用 fork 创建孙子进程，并退出，从而使孙子进程变为一个"孤儿"进程（之所以使用孤儿进程是因为我们需要切断被检测进程与我们创建的进程之间的信号联系）。孙子进程利用父进程（被检测进程）的全局对象（appMemory）得到其 PID 和刚刚创建的消息队列的标识，并传递给调用 exec 函数产生的一个新的程序映象--MemCleaner。

　　MemCleaner 程序仅仅调用 kill(pid, 0);函数来查看被检测进程的生存状态，如果被检测进程不存在了（正常或者异常退出），则 kill 函数返回非 0 值，此时我们就动手清除可能存在的消息队列。

上一页  [1] [2] [3] [4] [5] 下一页