处理 .NET IDisposable 对象

Question

我使用 C# 工作，对于使用 using 块来声明实现 IDisposable 的对象，我一直相当宽松，而您显然总是应该这样做。 然而，我没有找到一种简单的方法来知道我何时犯了错误。 Visual Studio 似乎没有以任何方式表明这一点（我只是错过了什么吗？）。 我是否应该在每次声明任何内容时检查帮助，并逐渐建立一个百科全书式的记忆，哪些对象是一次性的，哪些对象不是一次性的？ 似乎没有必要、痛苦且容易出错。

你如何处理这个问题？

编辑：

查看相关问题侧边栏，我发现另一个问题，它清楚地表明 Dispose() 无论如何都应该由对象的终结器调用。 因此，即使您从未自己调用它，它最终也会发生，这意味着如果您不使用 using ，您就不会出现内存泄漏（这就是我想我一直以来真正担心的问题） ）。 唯一需要注意的是，垃圾收集器不知道对象作为非托管内容保留了多少额外内存，因此它无法准确了解收集对象将释放多少内存。 这将导致垃圾收集器的性能不如平时理想。

简而言之，如果我错过了 using，那也不是世界末日。 我只是希望某些东西至少会产生一个警告。

（题外话：为什么没有特殊的降价链接到另一个问题？）

编辑：

好吧，好吧，别吵了。 这是超级骗人的全火戏剧花栗鼠级重要调用Dispose()，否则我们都会死。

现在。 既然如此，为什么这么容易——见鬼，为什么它甚至被允许——做错事呢？ 你必须不遗余力地把事情做好。 像其他事情一样这样做会导致世界末日（显然）。 封装就这么多吧？

[厌恶地走开]

Answer 1

如果一个对象实现了 IDisposable 接口，那么它是有原因的，你应该调用它，并且它不应该被视为可选的。 最简单的方法是使用 using 块。

Dispose() 不仅仅旨在由对象的终结器调用，事实上，许多对象将实现 Dispose() 但没有终结器（这是完全有效的）。

处置模式背后的整个想法是，您提供了一种某种确定性的方式来释放对象（或其继承链中的任何对象）维护的非托管资源。 如果不正确调用 Dispose()，您绝对可能遇到内存泄漏（或任何其他问题）。

Dispose() 方法与析构函数没有任何关系。 .NET 中最接近析构函数的是终结器。 using 语句不会执行任何释放操作...事实上，调用 Dispose() 不会在托管堆上执行任何释放操作； 它仅释放已分配的非托管资源。 在 GC 运行并收集分配给该对象图的内存空间之前，托管资源并未真正释放。

确定类是否实现 IDisposable 的最佳方法是：

• IntelliSense（如果它具有 Dispose() 或 Close() 方法）
• MSDN
• 反射器
• 编译器（如果它没有实现IDisposable，你会得到一个编译器错误）
• 常识（如果感觉你应该在完成后关闭/释放对象，那么你可能应该）
• （如果有Open()，则可能应该调用相应的Close()）
• 语义 编译器。 尝试将其放在 using 语句中。 如果它没有实现 IDisposable，编译器将生成错误。

将处置模式视为与作用域生命周期管理有关的全部内容。 你希望尽可能最后获取资源，尽可能快地使用，并尽快释放。 using 语句通过确保即使出现异常也会调用 Dispose() 来帮助实现此目的。

Answer 2

这就是为什么（恕我直言）C++ 的 RAII 优于 .NET 的 using 语句。

很多人说 IDisposable 仅适用于非托管资源，这仅取决于您如何定义“资源”。 您可以拥有一个实现 IDisposable 的读/写锁，然后“资源”就是对代码块的概念访问。 您可以有一个对象，在构造函数中将光标更改为沙漏形，并返回到之前在 IDispose 中保存的值，然后“资源”就是更改后的光标。 我想说，当您希望在离开范围时执行确定性操作时，无论范围如何离开，您都可以使用 IDisposable，但我必须承认，它远不如说“它用于管理非托管资源管理”那么吸引人。

另请参阅有关为什么 .NET 中没有 RAII 的问题。

Answer 3

简而言之，如果我错过了一次使用，也不是世界末日。 我只是希望某些东西至少会产生一个警告。

这里的问题是，您不能总是通过将 IDisposable 包装在 using 块中来处理它。 有时您需要让物体停留更长时间。 在这种情况下，您必须自己显式调用其 Dispose 方法。

一个很好的例子是 类使用私有 EventWaitHandle (或 AutoResetEvent) 来在两个线程之间进行通信，并且您希望在线程完成后释放 WaitHandle。

因此，它并不像某些工具只是检查您是否只在 using 块中创建 IDisposable 对象那么简单。

Answer 4

@Atario，不仅接受的答案是错误的，您自己的编辑也是错误的。 想象一下以下情况（实际发生在 Visual Studio 2005 的一个 CTP 中）：

为了绘制图形，您创建笔而不处理它们。 笔不需要大量内存，但它们在内部使用 GDI+ 句柄。 如果不处理笔，GDI+ 手柄将不会被释放。 如果您的应用程序不是内存密集型的，则可能会花费相当长的时间而不会调用 GC。 但是，可用的 GDI+ 句柄数量受到限制，很快，当您尝试创建新笔时，操作就会失败。

事实上，在Visual Studio 2005 CTP中，如果您使用该应用程序足够长的时间，所有字体都会突然切换为“System”。

这正是依赖 GC 进行处置不够的原因。 内存使用量不一定与您获取（且不释放）的非托管资源数量相关。 因此，这些资源可能早在GC被调用之前就被耗尽了。

此外，当然，这些资源可能具有的副作用（例如访问锁）会阻止其他应用程序正常工作。

Answer 5

我实际上没有任何内容可以添加到Using块的一般用法中，只是想向规则添加一个例外：

任何实现IDisposable的对象显然不应在其Dispose()方法期间抛出异常。 在 WCF 之前（可能还有其他），这种方法工作得很好，现在 WCF 通道在 Dispose() 期间可能会引发异常。 如果在 using 块中使用它时发生这种情况，则会导致问题，并需要实施异常处理。 这显然需要更多关于内部工作原理的知识，这就是为什么微软现在建议不要在使用块中使用WCF通道（抱歉找不到链接，但谷歌中有很多其他结果），即使它实现了IDisposable..只是为了让事情变得更多复杂的！

Answer 6

不幸的是，FxCop 或 StyleCop 似乎都没有对此发出警告。 正如其他评论者所提到的，确保调用 dispose 通常非常重要。 如果我不确定，我总是检查对象浏览器 (Ctrl+Alt+J) 以查看继承树。

Answer 7

我主要在这种情况下使用 using 块：

我正在使用一些外部对象（在我的情况下通常是 IDisposable 包装的 COM 对象）。 对象本身的状态可能会导致它抛出异常，或者它对我的代码的影响可能会导致我抛出异常，而且可能在许多不同的地方。 一般来说，我不相信当前方法之外的代码能够自行运行。

为了便于论证，假设我的方法有 11 个退出点，其中 10 个位于此 using 块内，1 个位于其后面（这在我编写的某些库代码中可能很常见）。

由于退出 using 块时会自动释放该对象，因此我不需要 10 次不同的 .Dispose() 调用——它就这样发生了。 这会产生更干净的代码，因为现在处理调用不再那么混乱（在本例中减少了大约 10 行代码）。

如果有人在我之后更改了代码，如果他们忘记调用 dispose，那么引入 IDisposable 泄漏错误（这可能很耗时）的风险也较小，因为 using 块不需要这样做。

Answer 8

与 Fxcop（与其相关）一样，VS 中的代码分析工具（如果您有更高版本之一）也会找到这些情况。

Answer 9

始终尝试使用“using”块。 对于大多数对象来说，这没有太大区别，但我最近遇到了一个问题，我在类中实现了 ActiveX 控件，并且除非正确调用 Dispose，否则无法正常清理。 最重要的是，即使它看起来没有多大影响，也要尝试正确地做，因为有时它会产生影响。

Answer 10

根据此链接CodeRush 加载项 将在您键入时实时检测并标记本地 IDisposable 变量未清理的情况。

可以在你的追求中途遇见你。

Answer 11

我没明白你问题的重点。 多亏了垃圾收集器，内存泄漏几乎不可能发生。 但是，您需要一些强大的逻辑。

我通常这样创建 IDisposable 类：

public MyClass: IDisposable
{

    private bool _disposed = false;

    //Destructor
    ~MyClass()
    { Dispose(false); }

    public void Dispose()
    { Dispose(true); }

    private void Dispose(bool disposing)
    {
        if (_disposed) return;
        GC.SuppressFinalize(this);

        /* actions to always perform */

        if (disposing) { /* actions to be performed when Dispose() is called */ }

        _disposed=true;
}

现在，即使您错过使用 using 语句，该对象最终也会被垃圾收集，并执行正确的销毁逻辑。 您可以停止线程，结束连接，保存数据，无论您需要什么（在 此示例，我取消订阅远程服务并在需要时执行远程删除调用）

[编辑]显然，尽快调用 Dispose 有助于提高应用程序性能，并且是一个很好的做法。 但是，由于我的示例，如果您忘记调用 Dispose，它最终会被调用并清理对象。

Answer 12

FxCop可能有帮助（尽管它没有发现我刚刚向它发起的测试）； 但是是的：你应该检查一下。 IDisposable 是系统的重要组成部分，您需要养成这个习惯。 使用智能感知来查找 .D 是一个好的开始（尽管并不完美）。

然而，不需要很长时间就能熟悉需要处理的类型； 例如，通常涉及任何外部事物（连接、文件、数据库）。

ReSharper 也可以完成这项工作，提供“投入使用构造”选项。 不过，它不会将其作为错误提供...当然

，如果您不确定 - 尝试 使用它：如果您不确定，编译器会嘲笑您偏执：

using (int i = 5) {}

Error   1   'int': type used in a using statement must be implicitly convertible to 'System.IDisposable'