如果 .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

所有流都实现 IDisposable。将你的内存流包装在 using 语句中，你会很好而且花花公子。 using 块将确保您的流无论如何都关闭和处置。

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

Answer 2

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

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

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

Answer 3

如果某物是一次性的，则应始终将其丢弃。您应该在您的 bar() 方法中使用 using 语句来确保 ms2 被 Disposed。

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

Answer 4

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

Answer 5

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

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

想想 Stack Overflow 服务器，我们有一组有限的内存和数千个请求进入。我们不想等待计划的垃圾收集，我们希望尽快释放内存因此它可用于新的传入请求。

Answer 6

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

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

Answer 7

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

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

如果您绝对确定您从不想要从 MemoryStream 移动到另一种流，那么不调用 Dispose 不会对您造成任何伤害。但是，这通常是一种很好的做法，部分原因是如果您确实更改为使用不同的 Stream，您不希望被难以找到的错误所困扰，因为您早早选择了简单的方法在。 （另一方面，还有 YAGNI 论点……）

这样做的另一个原因是新的实现可能引入了将在 Dispose 上释放的资源。

Answer 8

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

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

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

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 9

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

Answer 10

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

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 11

是的，有一个泄漏，这取决于您如何定义 LEAK 以及您的意思是多长时间...

如果泄漏是指“内存仍处于分配状态，无法使用，即使您已经使用完毕”，而后者是指在调用 dispose 后的任何时间，那么是的，可能存在泄漏，尽管它不是永久性的（即在您的应用程序运行时的整个生命周期内）。

要释放 MemoryStream 使用的托管内存，您需要取消对它的引用，方法是取消对它的引用，这样它就可以立即进行垃圾回收了。如果你没有做到这一点，那么你会在你完成使用它时创建一个临时泄漏，直到你的引用超出范围，因为在此期间内存将无法用于分配。

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

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

Answer 12

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