在.NET程序中，垃圾回收器负责回收托管堆上的对象，但它的回收策略并不考虑对象持有的非托管资源是否仍然有效。一个FileStream对象即使已经不再被引用，它打开的文件句柄也不会因为GC而立即关闭，只有等到终结器线程执行时才会尝试释放。这种不确定性可能导致文件被锁定、数据库连接迟迟不归还连接池，甚至在高并发场景下出现句柄耗尽。C#提供IDisposable接口，就是为了给开发者一个明确的释放入口，让资源生命周期变得可控。
IDisposable接口到底解决什么问题
在托管环境中，引用类型对象可以分为两类：一类完全由托管内存组成，例如字符串、普通集合、自定义业务对象，这些对象即使没有手动清理，GC也会在合适的时机回收它们。另一类对象则持有非托管资源，例如操作系统文件句柄、数据库连接、网络套接字、互斥量、GDI绘图对象等。这些资源并不由CLR直接管理，GC无法准确知道它们何时应该被关闭或释放。
如果非托管资源只依赖终结器来释放，就会产生明显的时间差。终结器线程的运行时机由GC决定，程序繁忙时可能很久都不会执行，导致文件一直处于占用状态，或者数据库连接迟迟无法回到连接池。更严重的是，如果进程在终结器运行前就退出，某些非托管资源甚至永远得不到清理。IDisposable接口的作用就是提供一种确定性的释放机制，让开发者在使用完对象后立即调用Dispose方法，而不必等待GC的干预。
public interface IDisposable
{
void Dispose();
}
实现IDisposable接口的典型场景包括：类中直接或间接持有文件流、数据库连接、网络流、互斥锁、事件句柄、非托管内存指针等资源。只要一个类型中包含另一个实现了IDisposable接口的字段，那么该类型通常也需要实现IDisposable，以便把释放职责传递给聚合对象。
基础实现：Dispose与Dispose(bool)模式
最简单的实现方式是在Dispose方法中直接释放资源，并使用一个布尔字段防止重复释放。之所以要防止重复释放，是因为调用方可能多次调用Dispose，或者Dispose与终结器同时触发。幂等的释放逻辑可以避免重复关闭句柄时抛出异常。
public class SimpleResource : IDisposable
{
private bool _disposed;
public void Dispose()
{
if (_disposed) return;
// 在这里释放托管资源
_disposed = true;
}
}
这个实现虽然能满足最基本的需求，但存在两个问题：第一，它无法区分托管资源和非托管资源；第二，它没有为继承场景留下扩展点。如果某个子类也需要释放自己的资源，重写Dispose方法会破坏基类的释放逻辑。因此，.NET社区普遍推荐使用Dispose(bool)模式，也叫标准Dispose模式。
Dispose(bool)模式的核心思想是引入一个受保护的虚方法，由它统一处理释放逻辑。参数disposing表示当前调用是否来自开发者主动调用的Dispose方法。如果为true，说明对象仍然处于正常可访问状态，可以安全地访问其他托管对象；如果为false，说明方法由终结器触发，此时只能释放非托管资源，不能访问任何其他托管对象，因为这些对象可能已经被GC回收。
public class NativeResourceHolder : IDisposable
{
private bool _disposed;
private IntPtr _handle;
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (_disposed) return;
if (disposing)
{
// 释放类中引用的托管IDisposable成员
}
if (_handle != IntPtr.Zero)
{
// 关闭操作系统句柄
_handle = IntPtr.Zero;
}
_disposed = true;
}
}
Dispose方法中调用Dispose(true)之后，还会调用GC.SuppressFinalize(this)。这一句的作用是告诉垃圾回收器：这个对象的终结器已经不需要执行了，因为资源已经被主动释放。如果省略这一句，对象在垃圾回收时还会被放入终结器队列，额外增加一次终结器线程的调度开销。对于实现了终结器的类型，这一句尤其重要。
终结器如何参与资源释放
如果类中持有非托管资源，并且开发者忘记调用Dispose，终结器就是最后一道防线。C#中终结器是一个与类同名但前面带有波浪线的方法，编译器会将它转换为Finalize方法的覆盖实现。终结器只能由GC调用，开发者无法直接调用。带有终结器的类应该在终结器中调用Dispose(false)，以确保非托管资源最终仍然会被释放。
public class DatabaseConnection : IDisposable
{
private bool _disposed;
private SqlConnection _connection;
public DatabaseConnection(string connectionString)
{
_connection = new SqlConnection(connectionString);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (_disposed) return;
if (disposing)
{
_connection?.Dispose();
}
_disposed = true;
}
~DatabaseConnection()
{
Dispose(false);
}
}
在终结器中调用Dispose(false)时，disposing参数为false，因此托管资源_connection不会被释放。这是因为终结器执行时，_connection所引用的对象可能已经被GC判定为垃圾并回收，或者正处于不可预测的状态。如果此时仍然去调用它的Dispose方法，轻则抛出异常，重则导致难以排查的内存访问错误。非托管资源没有托管对象引用关系，所以可以在终结器中安全释放。
不过终结器并不是免费的午餐。每增加一个带终结器的对象，对象在创建时会被登记到终结器队列，垃圾回收时还需要经历从终结器队列到待终结队列的转移，最后由专用线程执行终结方法。这意味着对象在内存中存活的时间更长，回收过程也更复杂。如果类中没有直接持有非托管资源，就不要添加终结器。对于文件句柄、内核句柄等非托管资源，更推荐使用SafeHandle派生类来封装，因为它自带防重入和引用计数机制，可以进一步降低资源泄漏的风险。
using语句与继承中的注意事项
如果手动调用Dispose，代码很容易因为异常提前返回而漏掉释放逻辑。C#的using语句可以确保即使方法体内抛出异常，Dispose也会在finally中被调用。编译器会将using语句展开为try/finally结构，这是一种更可靠的资源管理方式。
using (var file = new FileStream("data.txt", FileMode.Open))
{
// 读取或写入文件
}
在继承体系中，子类如果也需要释放资源，不应该直接重写Dispose方法，而应该重写受保护的Dispose(bool)方法。子类先释放自己的资源，然后把disposing参数原样传递给基类，由基类继续释放它负责的部分。这样可以保证从子类到基类的释放顺序是稳定且完整的。
public class DerivedResource : NativeResourceHolder
{
private bool _derivedDisposed;
private FileStream _file;
protected override void Dispose(bool disposing)
{
if (_derivedDisposed) return;
if (disposing)
{
_file?.Dispose();
}
_derivedDisposed = true;
base.Dispose(disposing);
}
}
释放操作的幂等性和线程安全性同样值得关注。多个线程同时调用Dispose时，如果没有同步措施，_disposed字段的读写可能会产生竞态。对于可能被并发访问的资源包装类，可以在Dispose入口处使用lock或Interlocked.CompareExchange来保证只有第一个线程执行实际清理。清理完成后，其他线程再次调用Dispose应当直接返回，而不是抛出ObjectDisposedException。通常只有业务方法在对象释放后继续执行时，才需要主动检查_disposed并抛出ObjectDisposedException，以暴露使用已释放对象的逻辑错误。
C#IDisposable接口资源释放修改时间：2026-08-25 09:34:40