如果.NET中的MemoryStream没有关闭，是否会造成内存泄漏？

Question

我有以下代码：

MemoryStream foo(){
    MemoryStream ms = new MemoryStream();
    // write stuff to ms
    return ms;
}

void bar(){
    MemoryStream ms2 = foo();
    // do stuff with ms2
    return;
}

我分配的 MemoryStream 是否有可能在以后以某种方式无法处理？

我有一个同行评审坚持要求我手动关闭它，但我找不到信息来判断他的观点是否有效。

Answer 1

不需要调用 .Dispose() （或用 Using 包装）。

调用 .Dispose() 的原因是为了尽快释放资源。

想想 Stack Overflow 服务器，我们的内存有限，但有数千个请求进来。我们不想等待计划的垃圾收集，我们希望尽快释放该内存，以便它可用对于新传入的请求。

Answer 2

这已经得到了回答，但我只是补充一点，信息隐藏的老式原则意味着您可能在将来的某个时候想要重构：

MemoryStream foo()
{    
    MemoryStream ms = new MemoryStream();    
    // write stuff to ms    
    return ms;
}

到：

Stream foo()
{    
   ...
}

这强调调用者不应该关心返回的 Stream 类型，并且使得改变内部实现成为可能（例如，当模拟单元测试时）。

如果您没有在 bar 实现中使用 Dispose，那么您将会遇到麻烦：

void bar()
{    
    using (Stream s = foo())
    {
        // do stuff with s
        return;
    }
}

Answer 3

所有流都实现 IDisposable。 将您的内存流包装在 using 语句中，您就会变得很好。 无论如何，using 块将确保您的流被关闭和处置。

无论你在哪里调用 Foo ，你都可以使用(MemoryStream ms = foo())，我认为你应该没问题。

Answer 4

我建议将 MemoryStream 包装在 using 语句中的 bar() 中，主要是为了保持一致性：

• 现在 MemoryStream 不会释放 .Dispose() 上的内存>，但有可能在将来的某个时候，或者您（或您公司的其他人）可能会用您自己的自定义 MemoryStream 来替换它，等等。
• 它有助于在您的项目中建立一种模式，以确保所有流都被处置——这条线通过“所有流必须被处置”而不是“某些流必须被处置，但某些流不必被处置”来更明确地划定...
• 如果如果您更改了代码以允许返回其他类型的流，则无论如何您都需要更改它以进行处置。

在创建和返回 IDisposable 时，我通常在诸如 foo() 之类的情况下做的另一件事是确保构造对象和返回之间的任何失败都会被异常捕获，释放该对象，并重新抛出异常：

MemoryStream x = new MemoryStream();
try
{
    // ... other code goes here ...
    return x;
}
catch
{
    // "other code" failed, dispose the stream before throwing out the Exception
    x.Dispose();
    throw;
}

Answer 5

您不会泄漏内存，但您的代码审阅者正确地指示您应该关闭流。 这样做是有礼貌的。

唯一可能泄漏内存的情况是当您不小心留下对流的引用并且从未关闭它时。 您仍然没有真正泄漏内存，但您不必要地延长了您声称使用内存的时间。

Answer 6

如果对象实现了 IDisposable，则完成后必须调用 .Dispose 方法。

在某些对象中，Dispose 与 Close 的含义相同，反之亦然，在这种情况下，两者都可以。

现在，对于您的特定问题，不，您不会泄漏内存。

Answer 7

我不是 .net 专家，但也许这里的问题是资源，即文件句柄，而不是内存。 我猜垃圾收集器最终会释放流并关闭句柄，但我认为最好的做法是显式关闭它，以确保将内容刷新到磁盘。

Answer 8

在垃圾收集语言中，非托管资源的处置是不确定的。 即使您显式调用 Dispose，您也绝对无法控制何时实际释放后备内存。 当对象超出范围时，无论是退出 using 语句，还是从从属方法弹出调用堆栈，都会隐式调用 Dispose。 话虽如此，有时对象实际上可能是托管资源（例如文件）的包装器。 这就是为什么最好在finally 语句中显式关闭或使用using 语句。
干杯

Answer 9

MemorySteam只不过是字节数组，它是托管对象。
忘记处置或关闭除了最终确定之外没有副作用。
只需检查反射器中 MemoryStream 的构造函数或刷新方法，就会清楚为什么您不需要担心关闭或处置它，而只是为了遵循良好的实践。

Answer 10

你不会泄露任何东西——至少在当前的实现中。

调用 Dispose 不会更快地清理 MemoryStream 使用的内存。 它将阻止您的流在调用后进行读/写调用，这对您可能有用，也可能没有用。

如果您绝对确定您永远不想从MemoryStream移动到另一种流，那么不调用Dispose不会对您造成任何损害。 然而，这通常是一个很好的做法，部分原因是，如果您确实更改为使用不同的 Stream，您不想被难以发现的错误所困扰，因为您尽早选择了简单的出路在。 （另一方面，还有 YAGNI 论点...）

无论如何都要这样做的另一个原因是新的实现可能会引入在 Dispose 上释放的资源。

Answer 11

如果某物是一次性的，您应该始终丢弃它。 您应该在 bar() 方法中使用 using 语句来确保 ms2 得到 Dispose。

它最终会被垃圾收集器清理掉，但调用 Dispose 始终是一个好习惯。 如果您在代码上运行 FxCop，它会将其标记为警告。

Answer 12

是的，存在泄漏，具体取决于您如何定义泄漏以及您的意思是“稍后”......

如果泄漏您的意思是“内存仍然分配，无法使用，甚至尽管你已经用完了它”，而后者是指在调用 dispose 之后的任何时间，那么是的，可能会出现泄漏，尽管它不是永久性的（即在应用程序运行时的生命周期内）。

要释放 MemoryStream 使用的托管内存，您需要取消引用它，方法是取消对它的引用，以便它立即符合垃圾回收的条件。 如果你不这样做，那么从你使用完它开始，直到你的引用超出范围，你就会创建一个临时泄漏，因为在此期间内存将不可用于分配。

using 语句的好处（相对于简单地调用 dispose）是您可以在 using 语句中声明您的引用。 当 using 语句完成时，不仅会调用 dispose，而且您的引用也会超出范围，从而有效地使引用无效并使您的对象立即符合垃圾回收的条件，而无需您记住编写“reference=null”代码。

虽然未能立即取消引用某些内容并不是典型的“永久”内存泄漏，但它肯定具有相同的效果。 例如，如果您保留对 MemoryStream 的引用（即使在调用 dispose 之后），并且在方法中再往下一点，您会尝试分配更多内存...仍然引用的内存流使用的内存将不可用直到您使引用无效或它超出范围，即使您调用了 dispose 并完成了使用它。