A little late to the party, but there is one scenario that I don't think has been mentioned here - if class A implements IDisposable, and exposes public properties that are also IDisposable objects, then I think it's good practice for class A not only to dispose of the disposable objects that it has created in its Dispose method, but also to set them to null. The reason for this is that disposing an object and letting it get GCed (because there are no more references to it) are by no means the same thing, although it is pretty definitely a bug if it happens. If a client of Class A does dispose its object of type ClassA, the object still exists. If the client then tries to access one of these public properties (which have also now been disposed) the results can be quite unexpected. If they have been nulled as well as disposed, there will be a null reference exception immediately, which will make the problem easier to diagnose.

当对象不再被使用并且垃圾回收器认为合适时，对象将被清理。有时，您可能需要将一个对象设置为null以使其超出作用域(例如您不再需要其值的静态字段)，但总体而言，通常不需要将其设置为null。

关于处置对象，我同意@Andre的观点。如果对象是IDisposable的，那么在不再需要它时释放它是个好主意，特别是当对象使用非托管资源时。不处理非托管资源将导致内存泄漏。

一旦程序离开using语句的作用域，就可以使用using语句自动处理对象。

using (MyIDisposableObject obj = new MyIDisposableObject())
{
    // use the object here
} // the object is disposed here

其功能等价于:

MyIDisposableObject obj;
try
{
    obj = new MyIDisposableObject();
}
finally
{
    if (obj != null)
    {
        ((IDisposable)obj).Dispose();
    }
}

在c#中，你永远不需要将对象设置为空。编译器和运行时将负责找出它们何时不再在作用域中。

是的，你应该处理实现IDisposable的对象。

A little late to the party, but there is one scenario that I don't think has been mentioned here - if class A implements IDisposable, and exposes public properties that are also IDisposable objects, then I think it's good practice for class A not only to dispose of the disposable objects that it has created in its Dispose method, but also to set them to null. The reason for this is that disposing an object and letting it get GCed (because there are no more references to it) are by no means the same thing, although it is pretty definitely a bug if it happens. If a client of Class A does dispose its object of type ClassA, the object still exists. If the client then tries to access one of these public properties (which have also now been disposed) the results can be quite unexpected. If they have been nulled as well as disposed, there will be a null reference exception immediately, which will make the problem easier to diagnose.

如果它们实现了IDisposable接口，那么你应该释放它们。垃圾收集器会处理剩下的事情。

EDIT:处理一次性物品时最好使用using命令:

using(var con = new SqlConnection("..")){ ...

总是调用dispose。不值得冒这个险。大型托管企业应用程序应该受到尊重。不能做任何假设，否则它会反过来咬你一口。

别听她的。

很多对象实际上并没有实现IDisposable，所以你不必担心它们。如果他们真的超出了范围，他们将自动被释放。此外，我从来没有遇到过必须将某些内容设置为null的情况。

可能发生的一件事是，很多物体都可以保持打开状态。这将极大地增加应用程序的内存使用。有时很难判断这究竟是内存泄漏，还是您的应用程序只是在做很多事情。

内存配置文件工具可以帮助解决这类问题，但它可能很棘手。

此外，始终取消对不需要的事件的订阅。还要注意WPF绑定和控件。不常见的情况，但我遇到了这样的情况，我有一个WPF控件被绑定到一个底层对象。底层对象很大，占用了大量内存。WPF控件正在被一个新的实例所取代，而旧的实例由于某种原因仍然存在。这导致了一个大的内存泄漏。

在后台，代码写得很糟糕，但关键是你要确保没有使用的东西超出了范围。这需要很长时间才能用内存分析器找到，因为很难知道内存中的哪些东西是有效的，哪些不应该在那里。