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

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

如果对象实现了IDisposable，那么是的，你应该释放它。对象可能挂在本地资源(文件句柄、操作系统对象)上，否则这些资源可能不会立即释放。这可能导致资源短缺、文件锁定问题和其他本来可以避免的微妙错误。

参见在MSDN上实现一个Dispose方法。

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

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

当对象不再被使用并且垃圾回收器认为合适时，对象将被清理。有时，您可能需要将一个对象设置为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();
    }
}

我同意这里常见的答案，是的，你应该处理，不，你通常不应该设置变量为null…但是我想指出dispose主要不是关于内存管理的。是的，它可以帮助内存管理(有时确实如此)，但它的主要目的是让您确定地释放稀缺资源。

For example, if you open a hardware port (serial for example), a TCP/IP socket, a file (in exclusive access mode) or even a database connection you have now prevented any other code from using those items until they are released. Dispose generally releases these items (along with GDI and other "os" handles etc. which there are 1000's of available, but are still limited overall). If you don't call dipose on the owner object and explicitly release these resources, then try to open the same resource again in the future (or another program does) that open attempt will fail because your undisposed, uncollected object still has the item open. Of course, when the GC collects the item (if the Dispose pattern has been implemented correctly) the resource will get released... but you don't know when that will be, so you don't know when it's safe to re-open that resource. This is the primary issue Dispose works around. Of course, releasing these handles often releases memory too, and never releasing them may never release that memory... hence all the talk about memory leaks, or delays in memory clean up.

I have seen real world examples of this causing problems. For instance, I have seen ASP.Net web applications that eventually fail to connect to the database (albeit for short periods of time, or until the web server process is restarted) because the sql server 'connection pool is full'... i.e, so many connections have been created and not explicitly released in so short a period of time that no new connections can be created and many of the connections in the pool, although not active, are still referenced by undiposed and uncollected objects and so can't be reused. Correctly disposing the database connections where necessary ensures this problem doesn't happen (at least not unless you have very high concurrent access).

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

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

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