我看到很多答案都转向了讨论对托管和非托管资源使用IDisposable。我认为这篇文章是我找到的关于如何实际使用IDisposable的最佳解释之一。

https://www.codeproject.com/Articles/29534/IDisposable-What-Your-Mother-Never-Told-You-About

对于实际问题；如果您使用IDisposable清理占用大量内存的托管对象，简短的答案是否定的。原因是，一旦持有内存的对象超出范围，它就可以进行收集了。此时，任何引用的子对象也超出范围，将被收集。

唯一真正的例外是，如果托管对象中占用了大量内存，并且您已经阻止了该线程等待某个操作完成。如果在调用完成后不需要这些对象，那么将这些引用设置为null可能会让垃圾收集器更快地收集它们。但那个场景将代表需要重构的坏代码——而不是IDisposable的用例。

大多数关于“非托管资源”的讨论的一个问题是，它们并没有真正定义这个术语，但似乎暗示它与非托管代码有关。虽然许多类型的非托管资源确实与非托管代码交互，但用这种术语来思考非托管资源是没有帮助的。

相反，我们应该认识到所有被管理的资源都有共同点：它们都包含一个对象，要求某个外部“事物”代表它做一些事情，而损害了其他一些“事物”，而另一个实体同意这样做，直到另行通知。如果物体被抛弃并消失得无影无踪，那么任何东西都不会告诉外部的“事物”，它不再需要代表不再存在的物体改变自己的行为；因此，“东西”的有用性将永久性地降低。

因此，非托管资源表示外部“事物”代表对象改变其行为的协议，如果对象被放弃并不再存在，这将毫无用处地损害外部“事物的有用性。被管理的资源是一个对象，它是此类协议的受益人，但如果它被放弃，它已签署接收通知，并将使用该通知在其被销毁之前整理其事务。

我看到很多答案都转向了讨论对托管和非托管资源使用IDisposable。我认为这篇文章是我找到的关于如何实际使用IDisposable的最佳解释之一。

https://www.codeproject.com/Articles/29534/IDisposable-What-Your-Mother-Never-Told-You-About

对于实际问题；如果您使用IDisposable清理占用大量内存的托管对象，简短的答案是否定的。原因是，一旦持有内存的对象超出范围，它就可以进行收集了。此时，任何引用的子对象也超出范围，将被收集。

唯一真正的例外是，如果托管对象中占用了大量内存，并且您已经阻止了该线程等待某个操作完成。如果在调用完成后不需要这些对象，那么将这些引用设置为null可能会让垃圾收集器更快地收集它们。但那个场景将代表需要重构的坏代码——而不是IDisposable的用例。

我使用IDisposable的场景：清理非托管资源、取消订阅事件、关闭连接

我用于实现IDisposable（非线程安全）的习惯用法：

class MyClass : IDisposable {
    // ...

    #region IDisposable Members and Helpers
    private bool disposed = false;

    public void Dispose() {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    private void Dispose(bool disposing) {
        if (!this.disposed) {
            if (disposing) {
                // cleanup code goes here
            }
            disposed = true;
        }
    }

    ~MyClass() {
        Dispose(false);
    }
    #endregion
}

在对对象调用Dispose后，不应再调用该对象的方法（尽管对象应允许进一步调用Dispose）。因此，问题中的例子是愚蠢的。如果调用Dispose，则可以丢弃对象本身。因此，用户只需丢弃对整个对象的所有引用（将其设置为null），其内部的所有相关对象将自动被清理。

关于托管/非托管的一般性问题以及其他答案中的讨论，我认为对这个问题的任何回答都必须从非托管资源的定义开始。

归根结底，你可以调用一个函数来让系统进入一种状态，而你可以调用另一个函数来使它恢复到那种状态。现在，在典型示例中，第一个可能是返回文件句柄的函数，第二个可能是对CloseHandle的调用。

但是-这是关键-它们可以是任何匹配的函数对。一个建立一个国家，另一个摧毁它。如果状态已构建但尚未拆除，则资源的实例存在。您必须安排在正确的时间进行拆卸-资源不由CLR管理。唯一自动管理的资源类型是内存。有两种：GC和堆栈。值类型由堆栈管理（或通过在引用类型内搭便车），引用类型由GC管理。

这些函数可能会导致可以自由交错的状态变化，或者可能需要完美嵌套。状态更改可能是线程安全的，也可能不是。

看看Justice问题中的例子。对日志文件缩进的更改必须完全嵌套，否则会出错。此外，它们也不太可能是线程安全的。

可以搭上垃圾收集器的便车来清理未管理的资源。但前提是状态更改函数是线程安全的，并且两个状态的生存期可以以任何方式重叠。因此，正义的资源示例不能有终结器！这对任何人都没有帮助。

对于这些类型的资源，您可以只实现IDisposable，而不需要终结器。终结器是绝对可选的-它必须是。这在很多书中都被掩盖了，甚至没有提到。

然后，您必须使用using语句来确保调用Dispose。这本质上就像在堆栈上搭车一样（因为终结器是在GC上，而使用是在堆栈上）。

缺少的部分是您必须手动编写Dispose，并将其调用到字段和基类中。C++/CLI程序员不必这样做。在大多数情况下，编译器会为它们编写代码。

还有一种选择，我更喜欢嵌套完美且不线程安全的状态（除了其他之外，避免IDisposable避免了与无法抗拒为每个实现IDisposale的类添加终结器的人发生争论的问题）。

不用编写类，而是编写函数。该函数接受要回调的委托：

public static void Indented(this Log log, Action action)
{
    log.Indent();
    try
    {
        action();
    }
    finally
    {
        log.Outdent();
    }
}

然后一个简单的例子是：

Log.Write("Message at the top");
Log.Indented(() =>
{
    Log.Write("And this is indented");

    Log.Indented(() =>
    {
        Log.Write("This is even more indented");
    });
});
Log.Write("Back at the outermost level again");

传入的lambda作为一个代码块，因此就像您创建自己的控制结构以实现与使用相同的目的，只是您不再有调用方滥用它的危险。它们不可能不清理资源。

如果资源的生存期可能重叠，那么这种技术就不太有用了，因为这样你就可以构建资源A，然后构建资源B，然后杀死资源A，再杀死资源B。但是，您需要使用IDisposable（但仍然没有终结器，除非您实现了线程安全，这不是免费的）。

我不再重复关于使用或释放非托管资源的通常内容，这些内容已经全部介绍过了。但我想指出一个常见的误解。给定以下代码

Public Class LargeStuff
  Implements IDisposable
  Private _Large as string()

  'Some strange code that means _Large now contains several million long strings.

  Public Sub Dispose() Implements IDisposable.Dispose
    _Large=Nothing
  End Sub

我意识到一次性实现没有遵循当前的指导原则，但希望你们都能理解。现在，当调用Dispose时，释放了多少内存？答：没有。调用Dispose可以释放非托管资源，它不能回收托管内存，只有GC可以这样做。这并不是说上述模式不是一个好主意，事实上遵循上述模式仍然是一个好想法。一旦Dispose运行完毕，没有什么可以阻止GC重新声明_Large使用的内存，即使LargeStuff的实例可能仍在范围内。_Large中的字符串也可能在第0代，但LargeStuff的实例可能在第2代，因此，内存将很快被重新占用。但是，添加一个finalizer来调用上面显示的Dispose方法是没有意义的。这将延迟内存的重新声明，以允许终结器运行。