为什么.NET 没有内存泄漏？

Question

忽略不安全的代码，.NET 不会有内存泄漏。我从许多专家那里读了无数遍，我相信这一点。但是，我不明白为什么会这样。

据我了解，框架本身是用 C++ 编写的，而 C++ 容易出现内存泄漏。

• 底层框架写得这么好，绝对没有内存泄露的可能吗？
• 框架的代码中是否有一些东西可以自我管理甚至治愈它自己的潜在内存泄漏？
• 我还没有考虑其他答案吗？

Answer 1

.NET 可能有内存泄漏。

大多数情况下，人们指的是垃圾收集器，它决定何时可以摆脱一个对象（或整个对象循环）。这避免了 classic c 和 c++ 风格的内存泄漏，我的意思是分配内存而不是稍后释放它。

但是，很多时候程序员没有意识到对象仍然有悬空引用并且没有被垃圾回收，从而导致...内存泄漏。

通常情况下，事件已注册（使用+=）但稍后未取消注册，但也适用于访问非托管代码（使用 pInvokes 或使用底层系统资源的对象，例如文件系统或数据库连接）和没有正确处理资源。

Answer 2

由于垃圾回收，您不会经常发生内存泄漏（除了不安全代码和 P/Invoke 等特殊情况）。但是，您当然可以无意中使引用永远保持活动状态，这实际上会泄漏内存。

编辑

到目前为止，我见过的真正泄漏的最佳示例是事件处理程序 += 错误。

编辑

请参阅下面的错误解释，以及在何种条件下它被认为是真正的泄漏而不是几乎真正的泄漏。

Answer 3

在查看 Microsoft 文档后，特别是“Identifying Memory Leaks in the CLR”，Microsoft 确实声明，只要您不在应用程序中实现不安全代码，就不可能发生内存泄漏

现在，他们还指出了感知内存泄漏的概念，或者如 cmets 中所指出的“资源泄漏”，即使用具有延迟引用且未正确处理的对象。 IO 对象、数据集、GUI 元素等可能会发生这种情况。在使用 .NET 时，它们通常等同于“内存泄漏”，但它们不是传统意义上的泄漏。

Answer 4

.NET 可能存在内存泄漏，但它可以帮助您避免它们。所有引用类型对象都从一个托管堆中分配，该堆跟踪当前正在使用的对象（值类型通常分配在堆栈上）。每当在 .NET 中创建新的引用类型对象时，都会从这个托管堆中分配它。垃圾收集器负责定期运行和释放任何不再使用的对象（不再被应用程序中的任何其他对象引用）。​​

Jeffrey Richter 的书 CLR via C# 有一个很好的章节介绍了如何在 .NET 中管理内存。

Answer 5

嗯，.NET 有一个 garbage collector 在它认为合适的时候清理东西。这就是它与其他非托管语言的区别。

但是 .NET 可能存在内存泄漏。例如，GDI leaks 在 Windows 窗体应用程序中很常见。我帮助开发的其中一个应用程序经常遇到这种情况。当办公室的员工整天使用它的多个实例时，达到 Windows 固有的 10,000 个 GDI 对象限制的情况并不少见。

Answer 6

如果您不是指使用 .NET 的应用程序，这些答案对此进行了很好的讨论，但实际上指的是运行时本身，那么它在技术上可能存在内存泄漏，但在这一点上垃圾收集器的实现可能几乎没有错误。我听说过一种情况，在这种情况下，在运行时或标准库中的某些内容存在内存泄漏时发现了一个错误。但我不记得它是什么（非常模糊的东西），而且我想我再也找不到它了。

Answer 7

我想可以编写软件，例如.NET 运行时环境（CLR），如果足够小心，它不会泄漏内存。但由于 Microsoft 不时通过 Windows Update 发布 .NET 框架的更新，我相当确定即使在 CLR 中也存在偶尔的错误。

所有软件都可能泄漏内存。

但正如其他人已经指出的那样，还有其他类型的内存泄漏。虽然垃圾收集器处理“经典”内存泄漏，但仍然存在释放所谓的非托管资源（如数据库连接、打开的文件、GUI 元素等）的问题。 .这就是IDisposable 接口的用武之地。

另外，我最近在 .NET-COM 互操作 设置中遇到了可能的内存泄漏。 COM 组件使用引用计数来决定何时可以释放它们。 .NET 为此添加了另一种引用计数机制，该机制可以通过静态 System.Runtime.InteropServices.Marshal 类进行影响。

毕竟，即使在 .NET 程序中，您仍然需要小心资源管理。

Answer 8

这是 .NET 中的内存泄漏示例，它不涉及 unsafe/pinvoke，甚至不涉及事件处理程序。

假设您正在编写一个后台服务，该服务通过网络接收一系列消息并对其进行处理。所以你创建一个类来保存它们。

class Message 
{
  public Message(int id, string text) { MessageId = id; Text = text; }
  public int MessageId { get; private set; }
  public string Text { get; private set; }
}

好的，到目前为止一切顺利。后来您意识到，如果您在处理时参考了先前可用的消息，那么系统中的某些要求肯定会变得更容易。想要这个可能有很多原因。

所以你添加了一个新属性...

class Message
{
  ...
  public Message PreviousMessage { get; private set; }
  ...
}

然后你编写代码来设置它。当然，在主循环的某个地方，你必须有一个变量来跟上最后一条消息：

  Message lastMessageReceived;

然后你发现比你的服务更晚了几天，因为它已经用一长串过时的消息填满了所有可用的内存。

Answer 9

我发现的最好的例子实际上来自 Java，但同样的原则也适用于 C#。

我们正在读取由许多长行组成的文本文件（每行在堆中只有几 MB）。从每个文件中，我们搜索了几个关键子字符串并只保留了这些子字符串。在处理了几百个文本文件后，内存不足。

结果表明 string.substring(...) 会保留对原始长字符串的引用...即使我们只保留了 1000 个左右的字符，这些子字符串仍然会使用几个 MB 的内存。实际上，我们将每个文件的内容保存在内存中。

这是导致内存泄漏的悬空引用示例。 substring 方法试图重用对象，但最终浪费了内存。

编辑：不确定这个特定问题是否困扰 .NET。这个想法是为了说明在垃圾收集语言中执行的实际设计/优化，在大多数情况下，这种语言是智能且有用的，但可能会导致不必要的内存使用。

Answer 10

您绝对可以在 .NET 代码中出现内存泄漏。在某些情况下，某些对象会根植于自己（尽管这些对象通常是IDisposable）。在这种情况下，未能在对象上调用 Dispose() 绝对会导致真正的 C/C++ 风格的内存泄漏，并且分配的对象是您无法引用的。

在某些情况下，某些计时器类可能具有这种行为，例如。

如果您有可能重新安排自身的异步操作，则可能存在泄漏。异步操作通常会根回调对象，防止收集。在执行过程中，对象被执行线程根，然后新调度的操作重新根对象。

这里有一些使用System.Threading.Timer的示例代码。

public class Test
{
    static public int Main(string[] args)
    {
        MakeFoo();
        GC.Collect();
        GC.Collect();
        GC.Collect();
        System.Console.ReadKey();
        return 0;
    }

    private static void MakeFoo()
    {
        Leaker l = new Leaker();
    }
}

internal class Leaker
{
    private Timer t;
    public Leaker()
    {
        t = new Timer(callback);
        t.Change(1000, 0);
    }

    private void callback(object state)
    {
        System.Console.WriteLine("Still alive!");
        t.Change(1000, 0);
    }
}

很像GlaDOS，Leaker 对象将无限期地“仍然存在” - 然而，没有办法访问该对象（除了内部，对象如何知道它何时不再被引用？）

Answer 11

这里已经有一些很好的答案，但我想补充一点。让我们再仔细看看你的具体问题：

---

据我了解，框架本身是用 C++ 编写的，而 C++ 容易出现内存泄漏。

• 底层框架写得这么好，绝对没有内存泄露的可能吗？
• 框架的代码中是否有一些东西可以自我管理甚至修复它自己的潜在内存泄漏？
• 我还没有考虑其他答案吗？

---

这里的关键是区分你的代码和他们的代码。 .Net 框架（以及 Java、Go、python 和其他垃圾收集语言）承诺，如果您依赖他们的代码，您的代码不会泄漏内存。 . 至少在传统意义上。您可能会发现自己处于某些对象未按预期释放的情况，但这些情况与传统的内存泄漏略有不同，因为这些对象在您的程序中仍然可以访问。

您感到困惑，因为您正确理解这与说您创建的任何程序根本不可能有传统的内存泄漏是不同的。 他们的代码中仍然可能存在泄漏内存的错误。

所以现在您必须问自己：您更愿意相信您的代码还是他们的代码？请记住，他们的代码不仅经过原始开发人员的测试（就像您的一样，对吗？），而且还经过成千上万（也许数百万）像您这样的其他程序员的日常使用，经过了实战考验。任何重大的内存泄漏问题都将首先被识别和纠正。同样，我并不是说这是不可能的。只是相信他们的代码通常比你自己的代码更好……至少在这方面。

因此，这里的正确答案是它是您第一个建议的变体：

底层框架写得这么好，绝对没有内存泄露的可能吗？

不是没有可能，而是比自己管理要安全得多。我当然不知道框架中有任何已知漏洞。

Answer 12

以下是此人使用 ANTS .NET Profiler 发现的其他内存泄漏：http://www.simple-talk.com/dotnet/.net-tools/tracing-memory-leaks-in-.net-applications-with-ants-profiler/

Answer 13

如果您使用托管 dll 但 dll 包含不安全的代码怎么办？我知道这很麻烦，但是如果您没有源代码，那么从您的角度来看，您只是在使用托管代码，但仍然可以泄漏。

Answer 14

.Net 中不存在有效的 C/C++ 内存泄漏的一个主要来源是何时释放共享内存

以下内容来自 Brad Abrams 领导的关于设计 .NET 类库的课程

“嗯，第一点当然是没有内存泄漏，对吧？不是吗？还有内存泄漏？嗯，还有一种不同的内存泄漏。那怎么样？那么内存的那种我们没有的泄漏是，在旧世界中，您过去常常 malloc 一些内存，然后忘记执行 free 或添加 ref 并忘记执行释放，或者任何一对。而在新世界中，垃圾收集器最终拥有所有内存，当不再有任何引用时，垃圾收集器将释放这些东西。但是仍然可能存在泄漏，对吗？什么是泄漏？好吧，如果您保留对那个对象是活着的，那么垃圾收集器就不能释放它。很多时候，发生的事情是你认为你已经摆脱了整个对象图，但仍然有一个人用引用抓住它，并且那么你就被卡住了。除非你删除所有对它的引用，否则垃圾收集器无法释放它。

我认为另一个问题是个大问题。没有内存所有权问题。如果你去阅读 WIN32 API 文档，你会看到，好吧，我先分配这个结构并把它传入，然后你填充它，然后我释放它。还是我告诉你大小，你分配它，然后我稍后释放它，或者你知道，关于谁拥有该内存以及应该在哪里释放它的所有这些争论都在进行。很多时候，开发人员只是放弃了，然后说，“好吧，随便。好吧，当应用程序关闭时它会免费，”这不是一个好计划。

在我们的世界中，垃圾收集器拥有所有托管内存，因此不存在内存所有权问题，无论您创建它并将其传递给应用程序，应用程序创建并开始使用它。这些都没有问题，因为没有歧义。垃圾收集器拥有这一切。 "

Full Transcript

Answer 15

请记住，缓存和内存泄漏之间的区别在于策略。如果您的缓存有一个错误的策略（或更糟糕的是，没有）来删除对象，那么它与内存泄漏是无法区分的。

Answer 16

此参考说明如何在 .Net 中使用弱事件模式发生泄漏。 http://msdn.microsoft.com/en-us/library/aa970850.aspx