“内存泄漏”的剖析

Question

在 .NET 方面：

• 什么是内存泄漏？
• 您如何确定您的应用程序是否泄漏？ 有哪些影响？
• 如何防止内存泄漏？
• 如果您的应用程序存在内存泄漏，它会在进程退出或被终止时消失吗？ 或者即使在进程完成后，您的应用程序中的内存泄漏是否会影响系统上的其他进程？
• 那么通过 COM Interop 和/或 P/Invoke 访问的非托管代码呢？

Answer 1

我见过的最好的解释是在免费的编程基础电子书的第 7 章。

基本上，在.NET 中，当引用的对象有根并且不能被垃圾收集时，就会发生内存泄漏。 当您保留超出预期范围的引用时，会意外发生这种情况。

当您开始出现 OutOfMemoryExceptions 或您的内存使用量超出您的预期（ PerfMon有很好的内存计数器）时，您就会知道您有泄漏。

了解.NET的内存模型是避免它的最佳方法。 具体来说，了解垃圾收集器的工作原理以及引用的工作原理——我再次向您推荐电子书的第 7 章。 此外，请注意常见的陷阱，可能最常见的是事件。 如果对象A注册到对象B上的事件，则对象A将一直存在，直到对象B消失，因为B持有对A的引用。 解决方案是在完成后取消注册您的事件。

当然，一个好的内存配置文件会让你看到你的对象图并探索你的对象的嵌套/引用，看看引用来自哪里以及什么根对象负责（红门蚂蚁配置文件，JetBrains dotMemory， memprofiler真的很好选择，或者您可以使用纯文本WinDbg和SOS ，但我强烈建议您使用商业/视觉产品，除非您是真正的大师）。

我相信非托管代码受其典型内存泄漏的影响，除了共享引用由垃圾收集器管理。 最后一点我可能是错的。

Answer 2

严格来说，内存泄漏正在消耗程序“不再使用”的内存。

“不再使用”的含义不止一种，它可能意味着“不再引用它”，即完全不可恢复，或者它可能意味着已引用、可恢复、未使用，但程序无论如何都会保留这些引用。 只有后者适用于 .Net 的完美管理对象。 然而，并不是所有的类都是完美的，在某些时候，底层的非托管实现可能会永久地泄漏该进程的资源。

在所有情况下，应用程序消耗的内存都比严格需要的多。 副作用，取决于泄漏的数量，可能从无到因过度收集导致的速度减慢，到一系列内存异常，最后是致命错误，然后是强制进程终止。

当监控显示在每个垃圾回收周期后分配给您的进程的内存越来越多时，您就知道应用程序存在内存问题。 在这种情况下，您要么在内存中保留了太多内容，要么某些底层的非托管实现正在泄漏。

对于大多数泄漏，在进程终止时会恢复资源，但是在某些特定情况下并不总是会恢复某些资源，GDI 游标句柄因此而臭名昭著。 当然，如果您有进程间通信机制，则在另一个进程释放或终止之前，不会释放分配给另一个进程的内存。

Answer 3

我认为“什么是内存泄漏”和“影响是什么”的问题已经得到很好的回答，但我想在其他问题上再添加一些东西......

如何了解您的应用程序是否泄漏

一种有趣的方法是打开perfmon并为所有堆中的 # bytes和# Gen 2 集合添加跟踪，在每种情况下都只查看您的进程。 如果执行特定功能导致总字节数增加，并且该内存在下一个 Gen 2 收集后仍保持分配状态，您可能会说该功能泄漏了内存。

如何预防

已经给出了其他好的意见。 我只想补充一点，可能最常被忽视的 .NET 内存泄漏原因是向对象添加事件处理程序而不删除它们。 附加到对象的事件处理程序是对该对象的引用的一种形式，因此即使在所有其他引用都消失后也会阻止收集。 永远记住分离事件处理程序（在 C# 中使用-=语法）。

当进程退出时，泄漏是否消失，COM 互操作呢？

当您的进程退出时，操作系统会回收映射到其地址空间的所有内存，包括从 DLL 提供的所有 COM 对象。 比较少见的是，COM 对象可以从单独的进程提供服务。 在这种情况下，当您的进程退出时，您可能仍需负责在您使用的任何 COM 服务器进程中分配的内存。

Answer 4

如果您需要诊断 .NET 中的内存泄漏，请查看以下链接：

http://msdn.microsoft.com/en-us/magazine/cc163833.aspx

http://msdn.microsoft.com/en-us/magazine/cc164138.aspx

这些文章描述了如何创建进程的内存转储以及如何对其进行分析，以便您可以首先确定您的泄漏是不受管理的还是受管理的，如果是受管理的，如何找出它的来源。

微软还有一个更新的工具来帮助生成故障转储，以取代 ADPlus，称为 DebugDiag。

http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

Answer 5

我将内存泄漏定义为一个对象，它在完成后不释放所有分配的内存。 我发现如果您在框架和第三方组件中使用 Windows API 和 COM（即其中存在错误或未正确管理的非托管代码），这可能会发生在您的应用程序中。 我还发现在使用某些物体（如钢笔）后不整理会导致问题。

我个人曾遇到过内存不足异常，这可能是由 dot net 应用程序中的内存泄漏引起的，但并非仅限于此。 （OOM 也可以来自 pinning，参见Pinning Artical ）。 如果您没有收到 OOM 错误或需要确认是否是内存泄漏导致它，那么唯一的方法就是分析您的应用程序。

我也会尝试确保以下几点：

a) 实现 Idisposable 的所有内容都使用 finally 块或 using 语句进行处理，包括画笔、钢笔等（有些人认为将所有内容都设置为空）

b) 使用 finally 或 using 语句再次关闭任何具有 close 方法的内容（尽管我发现 using 并不总是关闭，具体取决于您是否在 using 语句之外声明了对象）

c) 如果您使用的是非托管代码/windows API，则这些代码将在之后正确处理。 （有些有释放资源的清理方法）

希望这可以帮助。

Answer 6

使用 Microsoft 的 CLR Profiler http://www.microsoft.com/downloads/details.aspx?familyid=86ce6052-d7f4-4aeb-9b7a-94635beebdda&displaylang=en是确定哪些对象占用内存的好方法，哪些执行流程导致创建这些对象，并监视哪些对象位于堆上的位置（碎片、LOH 等）。

Answer 7

关于垃圾收集器如何工作的最佳解释是 Jeff Richters CLR via C# book，（第 20 章）。 阅读本文为理解对象如何持久化奠定了良好的基础。

意外生根对象的最常见原因之一是将事件挂接到类之外。 如果你连接一个外部事件

例如

SomeExternalClass.Changed += new EventHandler(HandleIt);

并且在处理时忘记取消挂钩，然后 SomeExternalClass 会引用您的类。

如上所述， SciTech 内存分析器非常擅长向您显示您怀疑正在泄漏的对象的根。

但是还有一种非常快速的检查特定类型的方法就是使用 WnDBG（您甚至可以在附加的 VS.NET 即时窗口中使用它）：

.loadby sos mscorwks
!dumpheap -stat -type <TypeName>

现在做一些你认为会处理该类型对象的事情（例如关闭一个窗口）。 在这里有一个调试按钮可以很方便地运行System.GC.Collect()几次。

然后再次运行!dumpheap -stat -type <TypeName> 。 如果数字没有下降，或者没有像您预期的那样下降，那么您就有了进一步调查的基础。 （我从Ingo Rammer举办的研讨会上得到了这个提示）。

Answer 8

我猜在托管环境中，泄漏将是您保留对大量内存的不必要引用。

Answer 9

为什么人们认为 .NET 中的内存泄漏与任何其他泄漏不同？

内存泄漏是当您附加到资源并且不放手时。 您可以在托管和非托管编码中执行此操作。

关于 .NET 和其他编程工具，已经有关于垃圾收集的想法，以及其他减少应用程序泄漏情况的方法。 但是，防止内存泄漏的最佳方法是您需要了解您所使用的平台上的底层内存模型以及工作原理。

相信 GC 和其他魔法会清理你的烂摊子是内存泄漏的捷径，以后很难找到。

当编码不受管理时，您通常确保清理，您知道您掌握的资源将是您清理的责任，而不是看门人的。

另一方面，在 .NET 中，很多人认为 GC 会清理所有内容。 嗯，它对你有一些帮助，但你需要确保它确实如此。 .NET 确实包含了很多东西，因此您并不总是知道您是在处理托管资源还是非托管资源，您需要确定您正在处理什么。 处理字体、GDI 资源、活动目录、数据库等通常是您需要注意的事情。

在管理方面，我会说，一旦进程被终止/删除，它就会消失。

我看到很多人都有这个，我真的希望这会结束。 你不能要求用户终止你的应用程序来清理你的烂摊子！ 看看浏览器，可以是 IE、FF 等，然后打开，比如说，谷歌阅读器，让它停留几天，看看会发生什么。

如果您然后在浏览器中打开另一个选项卡，浏览某个站点，然后关闭托管另一个导致浏览器泄漏的页面的选项卡，您认为浏览器会释放内存吗？ IE 并非如此。 如果我使用 Google 阅读器，IE 在我的电脑上很容易在短时间内（大约 3-4 天）吃掉 1 GiB 的内存。 一些新闻页面甚至更糟。

Answer 10

我猜在托管环境中，泄漏将是您保留对大量内存的不必要引用。

绝对地。 此外，在适当的时候不在一次性对象上使用 .Dispose() 方法会导致内存泄漏。 最简单的方法是使用 using 块，因为它会在最后自动执行 .Dispose() ：

StreamReader sr;
using(sr = new StreamReader("somefile.txt"))
{
    //do some stuff
}

如果您创建一个使用非托管对象的类，如果您没有正确实现 IDisposable，您可能会导致类用户的内存泄漏。

Answer 11

所有内存泄漏都通过程序终止来解决。

泄漏足够的内存，操作系统可能会决定代表您解决问题。

Answer 12

我会同意 Bernard 在 .net 中的内存泄漏会是什么。

您可以分析您的应用程序以查看其内存使用情况，并确定它是否在不应该管理大量内存时您可以说它存在泄漏。

在管理方面，我会说，一旦进程被终止/删除，它就会消失。

非托管代码是它自己的野兽，如果其中存在泄漏，它将遵循标准内存。 泄漏定义。

Answer 13

还要记住，.NET 有两个堆，一个是大对象堆。 我相信大约 85k 或更大的对象被放在这个堆上。 该堆与常规堆具有不同的生命周期规则。

如果您正在创建大型内存结构（字典或列表），最好去查找确切的规则是什么。

至于在进程终止时回收内存，除非您正在运行 Win98 或其等效版本，否则一切都会在终止时释放回操作系统。 唯一的例外是跨进程打开的东西，而另一个进程仍然打开了资源。

COM 对象可能很棘手。 如果你总是使用IDispose模式，你会很安全。 但是我遇到了一些实现IDispose互操作程序集。 这里的关键是在完成后调用Marshal.ReleaseCOMObject 。 COM 对象仍然使用标准的 COM 引用计数。

Answer 14

在.Net 中查找内存泄漏时，我发现.Net Memory Profiler非常有用。 它不像 Microsoft CLR Profiler 那样免费，但在我看来更快、更重要。 一种

Answer 15

一种定义是：无法释放无法访问的内存，在分配进程执行期间不能再分配给新进程。 它主要可以通过使用 GC 技术治愈或通过自动化工具检测。

有关更多信息，请访问http://all-about-java-and-weblogic-server.blogspot.in/2014/01/what-is-memory-leak-in-java.html 。