从零开始:C#回收魔法—深入浅出揭开Dispose与释放模式的神秘面纱

一、什么是Dispose?

我们先来看一个简单例子(Net 8)。定义一个实现了Dispose方法的简单对象Defer。然后在控制台中我们执行以下代码。

// 定义Defer类型 ref struct Defer(Action action) { public void Dispose() => action?.Invoke();}   // Main入口 static void Main(string[] args) {     using var df = new Defer(() => Console.WriteLine("Run"));      Console.WriteLine("Hello, World!"); }  // 控制台输出: // Hello, World! // Run 

可以看到,hello,worldRun的输出顺序反过来了。
这个Defer结构体可以近似模拟GolangDefer关键词起到的延迟执行功能。using本身是一个语法糖,帮助我们更好把握Dispose()方法的调用时机。
对于ref struct,上述代码等效于:

{   Defer df = new Defer(() => Console.WriteLine("Run"));   try   {       Console.WriteLine("Hello, World!");   }   finally   {       df.Dispose();   } } 

在这里,try内部将要保住的代码为df对象生命周期以内的代码。

对于异步DisposeAsync(), using等效于:

{     ResourceType resource = «expression»;     try     {         «statement»;     }     finally     {         IAsyncDisposable d = (IAsyncDisposable)resource;         if (d != null)         {             await d.DisposeAsync();         }     } } 

二、为什么要设计Dispose?

C#采用垃圾回收机制来自动管理内存,这使得程序员不需要手动管理内存分配和释放,大大减少了内存泄漏和野指针等问题。然而,垃圾回收器只负责托管内存的回收,对于非托管资源,它无法自动管理。而且,垃圾回收器的运行时间是不确定的,它可能在资源已经不再需要很久之后才运行。因此,需要一种机制来主动释放非托管资源,这就是Dispose出现的原因之一。
在C#开发中,我们经常使用各种资源,比如文件、数据库连接等。这些资源用完后需要及时释放,否则会占用系统资源,影响程序性能。Dispose方法就是用来释放这些资源的。当我们不再需要某个对象时,需要主动/被动的调用Dispose方法,就能把资源归还给系统,避免资源泄露。

简单来说,Dispose就是约定号的一个“用完就收拾”的方法。可以方便的配合using关键词来使用。我们可以再看看几个例子。

案例1 通过using在指定代码完成后触发Dispose

// Main入口      using (Defer df1 = new(() => Console.WriteLine("Run")))     Console.WriteLine("Hello, World!1");  // 或 通过 { ... } 包住代码          Console.WriteLine("Hello, World!2");  // 控制台输出: // Hello, World!1 // Run // Hello, World!2 

案例2 通过using多重触发,最终按变量定义的顺序反着执行(出栈顺序):

// Main入口 using Defer df1 = new(() => Console.WriteLine("Run1")),             df2 = new(() => Console.WriteLine("Run2")),              df3 = new(() => Console.WriteLine("Run3")); Console.WriteLine("Hello, World!");  // 控制台输出: // Hello, World! // Run3 // Run2 // Run1 

案例3 异步IAsyncDisposable,调用await using:

public class A_Async:IAsyncDisposable {async ValueTask IAsyncDisposable.DisposeAsync() => await Task.CompletedTask;}  static async void Main(string[] args) {    await using A_Async a = new(); } 

三、为什么要用释放模式(Dispose Pattern)?

在C#实现接口时,Visual Studio的提示中经常会弹出通过释放模式实现接口,那么什么是释放模式?
释放模式是Dispose模式和析构函数(finalizer)的结合使用,目的是为了确保资源能够被正确释放,无论是通过显式的调用Dispose方法,还是在对象被垃圾回收器(GC)回收时触发析构函数。这种模式被称为“Dispose模式”,它是一种资源管理的最佳实践,用于处理托管资源和非托管资源。

从零开始:C#回收魔法—深入浅出揭开Dispose与释放模式的神秘面纱

举个例子,我们有一个对象,里面有一些非托管资源,也有一些托管资源。示例代码如下:

class SampleObject:IDisposable {     private ManagedObject _mo;  //托管     private UnmanagedObject _umo; //非托管      public void Dispose()   //资源释放     {       _mo.Dispose(); //释放托管       _umo.Dispose(); //释放非托管     } } 

3.1 防止重复调用Dispose()

正常情况下我们的代码问题不大。但假设ManagedObjectUnmanagedObject不是我们写的,所以要考虑重复Dispose可能会出现问题。为此,我们需要在SampleObject内部加上一个标志位来避免重复释放,此时代码变成了:

class SampleObject:IDisposable {   private ManagedObject _mo;   private UnmanagedObject _umo;   private bool disposedValue = false; // 新增: flag变量    public void Dispose()   {     if (!disposedValue) // 新增: 判断flag值,避免重复调用     {       _mo.Dispose();       _umo.Dispose();       disposedValue = true;     }   } } 

3.2 避免遗漏调用Dispose()

对于含非托管资源的对象,如果忘了调用Dispose(),轻点就是内存泄漏,严重的话可能是灾难。为了确保我们的对象能够调用Dispose(),我们考虑增加析构函数。期望在程序被GC回收的时候自动释放资源,示例代码如下:

class SampleObject:IDisposable {   private ManagedObject _mo;   private UnmanagedObject _umo;   private bool disposedValue = false;    public void Dispose()   {          DisposeFinal(); // 执行资源释放      // 新增: 如果手动调用了Dispose(),告诉终结器不要再执行析构函数      // 即不要重复调用DisposeFinal()方法     GC.SuppressFinalize(this);    }     public void DisposeFinal()  //重命名,从Dispose方法中分离出来   {     if (!disposedValue)     {             _mo.Dispose();       _umo.Dispose();       disposedValue = true;     }   }    // 新增: 析构函数,在忘记调用Dispose()时由终结器执行Dispose()   ~SampleObject()    {       DisposeFinal();   } } 

3.3 托管资源的提前回收

如果3.2中的对象忘了调用Dispose(),此时触发了析构函数,仍然可以执行Dispose()。
尽管看着好像一切都完美了。但这里还是有潜在的重复调用Dispose()隐患。因为终结器的执行顺序是不固定的,当SampleObject对象被终结器触发析构函数时,其他对象(比如_mo)可能也触发了析构函数。造纸在SampleObject执行Dispose时,有可能_mo的Dispose()方法被执行了2次(自身一次,外部调用一次),从而造成意外后果。

我们可以看一个例子。

3.3.1 定义一个有缺陷的托管资源类

这个类未对重复释放进行拦截。

// 我们定义一个有缺陷的托管资源的类 class ManagedData:IDisposable {     // 模拟托管资源,大数组尽量让GC多保留一会,增加测试结果多样性     private MemoryStream data= new MemoryStream(new byte[100_000000]);       private bool _finalized = false;     int id;     public ManagedData(int id)  //记录当前对象id     {         this.id = id;     }      ~ManagedData()     {         _finalized = true;  // 由析构函数释放         Console.WriteLine($"{id}:ManagedData 已终结.");     }      public void Dispose()     {         if (_finalized)             throw new ObjectDisposedException($"{id}:无法访问已终结的ManagedData.");          data.Dispose();         Console.WriteLine($"{id}:ManagedData 正常释放.");         _finalized = true;  // 由dispose释放     } } 
3.3.2 定义一个继承IDisposable接口的类

再定义一个实现IDisposabled接口的SampleObject来使用。在这里我们用标准的释放模式(Dispose Pattern)来写,但故意把托管资源放到disposing判定的外面来来执行。

class SampleObject:IDisposable {   private ManagedData _mo;   int id;    public SampleObject(int id) //记录当前对象id   {       this.id = id;        _mo = new ManagedData(id);   }    private bool disposedValue;    // 标准的释放模式写法   protected virtual void Dispose(bool disposing)   {       if (!disposedValue) //如果已执行dispose,则以下代码跳过       {           // 判定来源           // 如果是手动Dispose()调用的,disposing为true释放托管资源           // 如果是被动由终结器在析构函数调用的,disposing为false此时不应该释放托管资源           if (disposing)             {               // 本来应该写托管资源的地方           }                       try           {               _mo.Dispose();  // 为了测试,这里将托管资源的释放和操作放外面           }           catch (Exception ex)           {               Console.WriteLine($"{id}:异常: {ex.GetType().Name} - {ex.Message}");           }           disposedValue = true;       }   }    ~SampleObject()   {       Dispose(disposing: false);   }    public void Dispose()   {       Dispose(disposing: true);       GC.SuppressFinalize(this);   } } 
3.3.3 我们创建一些对象进行测试

尝试在一个循环中创建这个对象,然后调用GC,等待GC释放

 for (int i = 0; i <5; i++) {     new SampleObject(i); // 立即成为垃圾 }  Console.WriteLine("创建完成,开始GC..."); GC.Collect(); GC.WaitForPendingFinalizers(); Console.WriteLine($"GC完成"); Console.ReadLine(); // 需要有个暂停,等待最终打印结果  // 控制台输出 // 创建完成,开始GC... // 0:ManagedData 已终结. // 1:ManagedData 已终结. // 1:异常: ObjectDisposedException - Cannot access a disposed object. // Object name: '1:无法访问已终结的ManagedData.'. // 2:ManagedData 正常释放. // 2:ManagedData 已终结. // 3:ManagedData 正常释放. // 3:ManagedData 已终结. // 0:异常: ObjectDisposedException - Cannot access a disposed object. // Object name: '0:无法访问已终结的ManagedData.'. // GC完成 

上述的结果是不确定的,有时候所有的都能成功,有时候部分会触发失败。因为终结器触发不确定行,有时引用的子对象已经被回收,但父对象析构函数还在访问它。
总的来说,Dispose释放模式是对潜在的Dispose问题进行了充分考虑的。如果每个方法都按要求写,那么就很安全。

四、最后

总的来说,C#中的Dispoe()是一个很有用的,他不仅在资源释放场景下是一大助力,而且在很多需要延迟执行或需要统一结束的场合也是一个很好的范式(比如Stream既有Close()方法同时还支持Dispose(),二者等效)。很多事务处理的Transaction对象也经常使用using来控制Commit()时机。另外就是图形资源、网络资源、数据库连接、系统句柄、非托管内存管理等等,通过Dispose()实现可以极大提高代码的可读性和可维护性。

感谢您的耐心阅读,希望各位从零开始的新朋友和老朋友有所收获!如果你对这篇文章的内容有任何建议或想法,欢迎随时交流!关注微信公众号‘萤火初芒’

从零开始:C#回收魔法—深入浅出揭开Dispose与释放模式的神秘面纱

重要关注微信公众号‘萤火初芒’,有问题公众号留言,务必第一时间回复解答~!!!

发表评论

评论已关闭。

相关文章