请解释一下“内存泄漏”，这个问题会有啥影响

Posted 2023-04-16

简单说明了一下没有工具的情况如何运用VC库中的工具来检查代码的内存泄漏问题。
一: 内存泄漏
内存泄漏是编程中常常见到的一个问题，内存泄漏往往会一种奇怪的方式来表现出来,基本上每个程序都表现出不同的方式。 但是一般最后的结果只有两个，一个是程序当掉，一个是系统内存不足。 还有一种就是比较介于中间的结果程序不会当，但是系统的反映时间明显降低，需要定时的Reboot才会正常。
有 一个很简单的办法来检查一个程序是否有内存泄漏。就是是用Windows的任务管理器(Task Manager)。运行程序，然后在任务管理器里面查看 逗内存使用地和地虚拟内存大小地两项，当程序请求了它所需要的内存之后，如果虚拟内存还是持续的增长的话，就说明了这个程序有内存泄漏问题。 当然如果内存泄漏的数目非常的小，用这种方法可能要过很长时间才能看的出来。
当然最简单的办法大概就是用CompuWare的BoundChecker 之类的工具来检测了，不过这些工具的价格对于个人来讲稍微有点奢侈了。
如果是已经发布的程序，检查是否有内存泄漏是又费时又费力。所以内存泄漏应该在Code的生成过程就要时刻进行检查。
二: 原因
内存泄漏产生的原因一般是三种情况：
分配完内存之后忘了回收；
程序Code有问题，造成没有办法回收；
某些API函数操作不正确，造成内存泄漏。
1. 内存忘记回收，这个是不应该的事情。但是也是在代码种很常见的问题。分配内存之后，用完之后，就一定要回收。如果不回收，那就造成了内存的泄漏，造成内存泄漏的Code如果被经常调用的话，那内存泄漏的数目就会越来越多的。从而影响整个系统的运行。比如下面的代码：
for (int =0;I<100;I++)

Temp = new BYTE[100];

就会产生 100*100Byte的内存泄漏。
2. 在某些时候，因为代码上写的有问题，会导致某些内存想回收都收不回来，比如下面的代码：
Temp1 = new BYTE[100];
Temp2 = new BYTE[100];
Temp2 = Temp1;
这样，Temp2的内存地址就丢掉了，而且永远都找不回了，这个时候Temp2的内存空间想回收都没有办法。
3. API函 数应用不当，在Windows提供API函数里面有一些特殊的API，比如FormatMessage。 如果你给它参数中有FORMAT_MESSAGE_ALLOCATE_BUFFER，它会在函数内部New一块内存Buffer出来。但是这个 buffer需要你调用LocalFree来释放。 如果你忘了，那就会产生内存泄漏。
三: 检查方法
一 般的内存泄漏检查的确是很困难，但是也不是完全没有办法。如果你用VC的库来写东西的话，那么很幸运的是，你已经有了很多检查内存泄漏的工具，只是你想不 想用的问题了。Visual C++的Debug版本的C运行库(C Runtime Library)。它已经提供好些函数来帮助你诊断你的代码和跟踪内存泄漏。 而且最方便的地方是这些函数在Release版本中完全不起任何作用，这样就不会影响你的Release版本程序的运行效率。
比如下面的例子里面，有一个明细的内存泄漏。当然如果只有这么几行代码的话，是很容易看出有内存泄漏的。但是想在成千上万行代码里面检查内存泄漏问题就不是那么容易了。
char * pstr = new char[5];
lstrcpy(pstr,"Memory leak");
如 果我们在Debug版本的Code里面对堆(Heap)进行了操作，包括malloc， free， calloc， realloc， new 和 delete可以利用VC Debug运行时库中堆Debug函数来做堆的完整性和安全性检查。比如上面的代码，lstrcpy的操作明显破坏了pstr的堆结构。使其溢出，并破坏 了临近的数据。那我们可以在调用lstrcpy之后的代码里面加入 _CrtCheckMemory函数。_CrtCheckMemory函数发现前面的lstrcpy使得pstr的堆结构被破坏，会输出这样的报告：
emory check error at 0x00372FA5 = 0x79, should be 0xFD.
memory check error at 0x00372FA6 = 0x20, should be 0xFD.
memory check error at 0x00372FA7 = 0x6C, should be 0xFD.
memory check error at 0x00372FA8 = 0x65, should be 0xFD.
DAMAGE: after Normal block (#41) at 0x00372FA0.
Normal located at 0x00372FA0 is 5 bytes long.
它 告诉说 pstr的长度应该时5个Bytes，但是在5Bytes后面的几个Bytes也被非法改写了。提醒你产生了越界操作。_CrtCheckMemory 的返回值只有TRUE和FALSE，那么你可以用_ASSERTE()来报告出错信息。 上面的语句可以换成 _ASSERTE(_CrtCheckMemory())； 这样Debug版本的程序在运行的时候就会弹出一个警告对话框，这样就不用在运行时候一直盯着Output窗口看了。这个时候按Retry，就可以进入源 代码调试了。看看问题到底出在哪里。
其他类似的函数还有 _CrtDbgReport, _CrtDoForAllClientObjects, _CrtDumpMemoryLeaks,_CrtIsValidHeapPointer, _CrtIsMemoryBlock, _CrtIsValidPointer,_CrtMemCheckpoint, _CrtMemDifference, _CrtMemDumpAllObjectsSince, _CrtMemDumpStatistics, _CrtSetAllocHook, _CrtSetBreakAlloc, _CrtSetDbgFlag,_CrtSetDumpClient, _CrtSetReportFile, _CrtSetReportHook, _CrtSetReportMode
这 些函数全部都可以用来在Debug版本中检查内存的使用情况。具体怎么使用这些函数就不在这里说明了，各位可以去查查MSDN。在这些函数中用处比较大 的，或者说使用率会比较高的函数是_CrtMemCheckpoint， 设置一个内存检查点。这个函数会取得当前内存的运行状态。 _CrtMemDifference 检查两种内存状态的异同。 _CrtMemDumpAllObjectsSince 从程序运行开始，或者从某个内存检查点开始Dump出堆中对象的信息。还有就是_CrtDumpMemoryLeaks当发生内存溢出的时候Dump出堆 中的内存信息。 _CrtDumpMemoryLeaks一般都在有怀疑是内存泄漏的代码后面调用。比如下面的例子：
#include <windows.h>
#include <crtdbg.h>
void main()

char * pstr;
pstr = new char[5];
_CrtDumpMemoryLeaks();

输出:
Detected memory leaks! à提醒你,代码有内存泄漏.
Dumping objects ->
44 normal block at 0x00372DB8, 5 bytes long.
Data: < > CD CD CD CD CD
Object dump complete.
如 果你双击包含行文件名的输出行，指针将会跳到源文件中内存被分配地方的行。当无法确定那些代码产生了内存泄漏的时候，我们就需要进行内存状态比较。在可疑 的代码段的前后设置内存检查点，比较内存使用是否有可疑的变化。以确定内存是否有泄漏。为此要先定义三个_CrtMemState 对象来保存要比较的内存状态。两个是用来比较，一个用了保存前面两个之间的区别。
_CrtMemState Sh1,Sh2,Sh_Diff;
char *pstr1 = new char[100];
_CrtMemCheckPoint(&Sh1); ->设置第一个内存检查点
char *pstr2 = new char[100];
_CrtMemCheckPoint(&Sh2); ->设置第二个内存检查点
_CrtMemDifference(&Sh_Diff, &Sh1, &Sh2); ->检查变化
_CrtMemDumpAllObjectsSince(&Sh_Diff); ->Dump变化
如 果你的程序中使用了MFC类库，那么内存泄漏的检查方法就相当的简单了。因为Debug版本的MFC本身就提供一部分的内存泄漏检查。 大部分的new 和delete没有配对使用而产生的内存泄漏，MFC都会产生报告。这个主要是因为MFC重载了Debug版本的new 和delete操作符， 并且对前面提到的API函数重新进行了包装。在MFC类库中检查内存泄漏的Class就叫 CMemoryState，它重新包装了了_CrtMemState，_CrtMemCheckPoint， _CrtMemDifference， _CrtMemDumpAllObjectsSince这些函数。并对于其他的函数提供了Afx开头的函数，供MFC程序使用。比如 AfxCheckMemory， AfxDumpMemoryLeaks 这些函数的基本用法同上面提到的差不多。 CMemoryState和相关的函数的定义都在Afx.h这个头文件中。 有个简单的办法可以跟踪到这些函数的声明。在VC中找到MFC程序代码中下面的代码， 一般都在X.cpp的开头部分
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
把 光标移到DEBUG_NEW上面 按F12，就可以进入Afx.h中定义这些Class和函数的代码部分。 VC中内存泄漏的常规检查办法主要是上面的两种。当然这两种方法只是针对于Debug版本的Heap的检查。如果Release版本中还有内存泄漏，那么 检查起来就麻烦很多了。
4 .总结:
实际上Heap的内存泄漏问题是相当的好查的。VC的提供的检查工具也不太少，但是如果是栈出了什么问题，恐怕就麻烦很多了。栈出问题，一般不会产生内存泄漏，但是你的代码的逻辑上很有可能会有影响。这个是最最痛苦的事情。 编程，就是小心，小心再小心而已。 参考技术A 申请了内存不释放就是内存泄露 比如. void GetMemory(int len) int *p =new int[len]; p申请了内存，但是函数返回了，没有指针的首地址传出来，不能释放了

内存泄漏和僵尸有啥区别？

【中文标题】内存泄漏和僵尸有啥区别？

【英文标题】：What is the difference Memory Leak and a Zombie?内存泄漏和僵尸有什么区别？

【发布时间】：2012-09-21 23:15:51

【问题描述】：

我正在做一个基于 ARC 的项目。我从未从事过基于非 ARC 的项目。最近我

在我启用 ARC 的项目中遇到了一个僵尸。据我所知，不会有记忆

ARC 中的泄漏，因为对象将被自动释放。但我遇到了一个僵尸

说“消息传递给一个已释放的实例”。我的困惑是内存泄漏等价物

对僵尸。如果是这种情况，那么 ARC 中也会发生内存泄漏吗？有什么帮助吗？

【问题讨论】：

一具没有灵魂的尸体，据说是用巫术复活的。

这不是 ARC 的错。假设你有一些弱指针并且它被释放了，那么你就会看到。

@iBlue：当对象被解除分配时，ARC 下的适当弱指针将变为 nil，但“传递给解除分配实例的消息”的基本点是由持有指向具有的对象的指针引起的被释放是正确的。

@Isaac 是的，我是说如果在它被释放后你尝试对它做点什么，那么你会看到，这不是 ARC 的错。

这可能会帮助你：***.com/questions/8275805/…, ***.com/questions/10804865/…

【参考方案1】：

Objective-C 用语中的“僵尸”与泄漏相反。泄漏是您不再有任何引用的已分配内存，因此您无法释放它。僵尸是一个已经被释放的对象，但是对它的引用仍然存在并且消息仍然被发送给它（这可能导致各种不可预知的行为）。

【讨论】：

他“解决”了混乱：p

@guru 它们关系密切——僵尸是一种识别对象悬空指针的方法。

这在 Swift 中还能发生吗？我的意思是，如果您向已释放的对象发送消息，那么您将得到的只是（强制）解开 nil 对象的 fatalError 对吗？我假设在安全访问的情况下你不会有问题......但是如果我错了并且它可能发生在 Swift 中，那么你可以分享一个示例代码来重新创建一个僵尸对象，因为虽然我已经创建了内存周期，我认为我从来没有能够创建一个僵尸对象

有关我之前评论的答案，请参阅：How can I demonstrate a zombie leak for Swift?

【参考方案2】：

有多种可能性，如果不看代码就很难知道发生了什么。 “传递给已释放实例的消息”错误意味着您有一个指向对象所在位置的指针，但此后已被释放。这可以并且仍然会发生在 ARC 中。这可能是因为你有一些非 ARC 代码（或者可能是 Core Foundation 的东西）与 ARC 代码交互，并且在交接时事情会出错。也可能发生这种情况，因为虽然 ARC 几乎每次都会选择正确的时间点来释放对象，但这并不完美（通常有办法解决这些情况）。