C#的析构函数是什么？如何使用？-小浪学习网

析构函数是C#中用于在对象被GC回收前释放非托管资源的特殊方法，以~类名声明，无参数无返回值，由GC自动调用且时间不确定。它不能替代IDisposable接口的确定性资源清理，因会增加GC负担、导致对象需两次回收，并可能阻塞终结器线程，故性能开销大，仅应作为Dispose模式的备用机制。

C#的析构函数是什么？如何使用？

C#中的析构函数，简单来说，是一种特殊的方法，它在垃圾回收器（GC）回收对象所占用的内存之前被调用。它的主要作用是释放非托管资源，比如文件句柄、数据库连接或者指向操作系统资源的指针。你可以把它看作是对象的“临终遗言”，确保在它彻底消失前，把一些“身后事”处理妥当。

解决方案

在C#中，析构函数的声明方式很特别，它没有访问修饰符，没有参数，也没有返回值。它的名字是类名前面加上一个波浪号（

）。

public class MyResourceHolder {     private IntPtr unmanagedResourceHandle; // 假设这是一个非托管资源句柄      public MyResourceHolder()     {         // 构造函数中分配非托管资源         Console.WriteLine("MyResourceHolder 实例被创建，分配非托管资源。");         unmanagedResourceHandle = new IntPtr(123); // 模拟分配     }      // 析构函数     ~MyResourceHolder()     {         // 在这里释放非托管资源         Console.WriteLine("MyResourceHolder 析构函数被调用，释放非托管资源。");         ReleaseUnmanagedResource(unmanagedResourceHandle); // 模拟释放     }      private void ReleaseUnmanagedResource(IntPtr handle)     {         // 实际的非托管资源释放逻辑         Console.WriteLine($"非托管资源句柄 {handle} 已释放。");     }      // 示例方法，模拟对象生命周期     public void DoSomething()     {         Console.WriteLine("MyResourceHolder 正在工作...");     } }  // 在Main方法中测试 // static void Main(string[] args) // { //     CreateAndForgetObject(); //     GC.Collect(); // 强制垃圾回收，但不保证立即执行析构函数 //     GC.WaitForPendingFinalizers(); // 等待所有终结器完成 //     Console.WriteLine("主程序结束。"); // }  // static void CreateAndForgetObject() // { //     MyResourceHolder obj = new MyResourceHolder(); //     obj.DoSomething(); //     // obj超出作用域，等待GC回收 // }

析构函数由垃圾回收器自动调用，你无法手动调用它。它的执行时间是不确定的，这带来了一些管理上的复杂性。对我个人而言，除非万不得已，我其实不太愿意直接依赖析构函数来做清理工作，因为它充满了不确定性。

C#析构函数与IDisposable接口有何不同？何时该选择哪种方式？

这几乎是C#资源管理中最核心的一个问题了。析构函数，正如我们之前提到的，提供的是一种“非确定性”的资源清理机制。它依赖于GC的调度，你无法预测它何时会被触发。这意味着，如果你有一个文件句柄或数据库连接，你不能指望它在用完之后立即被释放，这可能导致资源长时间占用，甚至耗尽。

而

IDisposable

接口，则提供了一种“确定性”的资源清理方式。当你实现这个接口时，你实际上是承诺提供一个

Dispose()

方法，让使用者可以主动、明确地调用它来释放资源。结合

using

语句，这种模式变得异常强大和优雅：

public class MyDisposableResource : IDisposable {     private bool disposed = false;     private FileStream fileStream;      public MyDisposableResource(string filePath)     {         Console.WriteLine($"MyDisposableResource 实例被创建，打开文件: {filePath}");         fileStream = new FileStream(filePath, FileMode.OpenOrCreate);     }      public void WriteData(string data)     {         if (disposed)         {             throw new ObjectDisposedException(nameof(MyDisposableResource));         }         byte[] bytes = System.Text.Encoding.UTF8.GetBytes(data);         fileStream.Write(bytes, 0, bytes.Length);         Console.WriteLine($"数据 '{data}' 已写入文件。");     }      public void Dispose()     {         Dispose(true);         GC.SuppressFinalize(this); // 阻止GC再次调用析构函数     }      protected virtual void Dispose(bool disposing)     {         if (!disposed)         {             if (disposing)             {                 // 释放托管资源                 if (fileStream != null)                 {                     fileStream.Close();                     fileStream.Dispose();                     Console.WriteLine("托管资源 FileStream 已关闭并释放。");                 }             }             // 释放非托管资源（如果有的话）             Console.WriteLine("非托管资源（如果有）已释放。");             disposed = true;         }     }      // 析构函数（作为备用，防止用户忘记调用Dispose）     ~MyDisposableResource()     {         Dispose(false);     } }  // 使用示例 // static void Main(string[] args) // { //     string filePath = "test.txt"; //     using (MyDisposableResource res = new MyDisposableResource(filePath)) //     { //         res.WriteData("Hello, C#!"); //     } // res.Dispose() 会在这里自动调用 //     Console.WriteLine("资源已通过 using 语句释放。");  //     // 演示不使用 using 且不调用 Dispose 的情况（析构函数会作为备用） //     // MyDisposableResource anotherRes = new MyDisposableResource("another.txt"); //     // anotherRes.WriteData("This will be cleaned by GC eventually."); //     // GC.Collect(); //     // GC.WaitForPendingFinalizers(); // }

所以，什么时候选择哪个？几乎所有时候，当你需要释放资源（尤其是非托管资源）时，都应该优先考虑实现

IDisposable

接口，并鼓励用户使用

using

语句。这不仅能保证资源及时释放，还能提高程序的响应性和效率。析构函数则更像是一个“安全网”，它通常与

IDisposable

结合使用，构成所谓的“Dispose模式”。它的作用是，如果开发者忘记调用

Dispose()

方法，析构函数会在GC回收对象时尝试做最后的清理，防止资源泄漏。但请记住，它只是一个备用方案，不应该成为主要的资源管理策略。

为什么C#中不推荐频繁使用析构函数？它的性能开销体现在哪里？

嗯，我个人觉得，频繁使用析构函数简直是自找麻烦。这不仅仅是编码风格的问题，更是实实在在的性能损耗。它的性能开销主要体现在以下几个方面：

首先，带有析构函数的对象，在垃圾回收时，不会被立即回收。GC会先将这些对象识别出来，并把它们的引用放到一个特殊的队列里，我们称之为“终结器队列”（Finalization Queue）。这意味着，即使对象已经不再被引用，它的内存也不会马上被释放。它必须等到GC的另一个线程（终结器线程）来执行它的析构函数之后，才能在下一次GC运行时被真正回收。这相当于给GC增加了额外的工作量，延迟了内存的释放。

其次，由于这种“两次回收”的机制，带有析构函数的对象实际上会经历两次垃圾回收。第一次GC只是将它们移到终结器队列，第二次GC才能真正清理它们的内存。这无疑增加了GC的运行频率和时间，从而影响了应用程序的整体性能。在一些对性能要求极高的场景下，这种延迟可能是不可接受的。

再者，终结器线程是单线程的。如果你的析构函数中包含了耗时的操作，或者更糟糕的是，抛出了未处理的异常，它可能会阻塞整个终结器队列，导致其他对象的析构函数也无法执行，进而引发更严重的资源泄漏问题。这就像一个交通堵塞，一个车道堵了，所有车都过不去。

所以，我的建议是，除非你确实需要直接管理非托管资源，并且已经深思熟虑了

IDisposable

模式的实现，否则尽量避免使用析构函数。它带来的复杂性和性能开销，往往超过了它能带来的便利。

如何正确实现Dispose模式以安全地管理非托管资源？

正确实现Dispose模式是C#中管理非托管资源的关键，也是一个相当标准的模式。它旨在提供一个明确的机制来释放资源，同时兼顾了防止用户忘记释放和处理继承层级中的资源释放。这个模式通常包含以下几个核心部分：

一个公共的

Dispose()

方法：这是
IDisposable
接口要求的方法。用户会显式调用它来释放资源。在这个方法里，我们会调用一个私有的或受保护的
```
Dispose(bool disposing)
```
方法，并传递
```
true
```
。同时，我们会调用
```
GC.SuppressFinalize(this)
```
来告诉垃圾回收器，这个对象的析构函数（如果有的话）不需要再执行了，因为资源已经被手动释放了。
一个受保护的

Dispose(bool disposing)

方法：这是模式的核心。它接受一个布尔参数
```
disposing
```
。
- 当
  disposing
  为
```
true
```
  时，表示
  Dispose()
  方法是由用户显式调用的。此时，我们应该释放所有托管资源（比如
```
FileStream
```
  、
```
SqlConnection
```
  等实现了
  IDisposable
  接口的对象）和非托管资源。
- 当
  disposing
  为
```
false
```
  时，表示
  Dispose()
  方法是由析构函数调用的。此时，我们只能安全地释放非托管资源。这是因为在析构函数被调用时，托管对象的状态已经不可靠了，它们可能已经被GC回收了。
一个析构函数（可选，但推荐用于非托管资源）：作为备用机制，如果用户忘记调用
Dispose()
，析构函数会在GC回收对象时被调用。它会调用
```
Dispose(false)
```
来确保非托管资源得到释放。
一个布尔字段：通常命名为
```
disposed
```
，用来跟踪对象是否已经被释放过，防止多次释放。

下面是一个完整的示例，它演示了如何实现这个模式：

using System; using System.IO;  public class MyComplexResource : IDisposable {     private bool disposed = false; // 标记是否已释放     private FileStream managedFileStream; // 托管资源     private IntPtr unmanagedBuffer; // 模拟非托管资源      public MyComplexResource(string filePath, int bufferSize)     {         Console.WriteLine($"MyComplexResource 实例被创建，文件: {filePath}, 缓冲区大小: {bufferSize}");         managedFileStream = new FileStream(filePath, FileMode.OpenOrCreate, FileAccess.ReadWrite);         // 模拟分配非托管内存         unmanagedBuffer = System.Runtime.InteropServices.Marshal.AllocHGlobal(bufferSize);         Console.WriteLine($"非托管缓冲区已分配，地址: {unmanagedBuffer}");     }      public void WriteToResource(byte[] data)     {         if (disposed)         {             throw new ObjectDisposedException(nameof(MyComplexResource), "对象已释放，无法操作。");         }         managedFileStream.Write(data, 0, data.Length);         Console.WriteLine($"数据已写入文件。");         // 模拟写入非托管缓冲区         System.Runtime.InteropServices.Marshal.Copy(data, 0, unmanagedBuffer, Math.Min(data.Length, 10)); // 仅复制部分         Console.WriteLine($"数据已写入非托管缓冲区。");     }      // 实现IDisposable接口的公共Dispose方法     public void Dispose()     {         Console.WriteLine("公共 Dispose() 方法被调用。");         // 调用核心的 Dispose(bool disposing) 方法，并告知它是由用户显式调用的         Dispose(true);         // 阻止GC再次调用析构函数，因为资源已经在这里被清理了         GC.SuppressFinalize(this);     }      // 核心的 Dispose 方法，处理资源释放逻辑     protected virtual void Dispose(bool disposing)     {         if (!disposed) // 确保只释放一次         {             if (disposing)             {                 // 释放托管资源                 if (managedFileStream != null)                 {                     managedFileStream.Close();                     managedFileStream.Dispose();                     managedFileStream = null;                     Console.WriteLine("托管资源 FileStream 已关闭并释放。");                 }             }              // 释放非托管资源             if (unmanagedBuffer != IntPtr.Zero)             {                 System.Runtime.InteropServices.Marshal.FreeHGlobal(unmanagedBuffer);                 unmanagedBuffer = IntPtr.Zero;                 Console.WriteLine("非托管缓冲区已释放。");             }              disposed = true;         }     }      // 析构函数：作为备用，防止用户忘记调用 Dispose()     ~MyComplexResource()     {         Console.WriteLine("析构函数 ~MyComplexResource() 被调用。");         // 调用核心的 Dispose(bool disposing) 方法，并告知它是由GC调用的         Dispose(false);     } }  // 示例用法： // static void Main(string[] args) // { //     string filePath = "complex_resource_test.txt"; //     // 使用 using 语句确保资源被正确释放 //     using (MyComplexResource resource = new MyComplexResource(filePath, 1024)) //     { //         byte[] data = System.Text.Encoding.UTF8.GetBytes("Hello, complex world!"); //         resource.WriteToResource(data); //     } // Dispose() 会在这里自动调用 //     Console.WriteLine("using 块结束，资源已通过 Dispose 模式释放。");  //     // 演示不使用 using 且不调用 Dispose 的情况（析构函数会作为备用） //     // Console.WriteLine("n--- 演示资源未手动释放的情况 ---"); //     // MyComplexResource leakedResource = new MyComplexResource("leaked_resource.txt", 512); //     // leakedResource.WriteToResource(System.Text.Encoding.UTF8.GetBytes("This might be cleaned by GC.")); //     // leakedResource = null; // 失去引用 //     // GC.Collect(); // 强制GC，但不保证立即执行 //     // GC.WaitForPendingFinalizers(); // 等待终结器线程完成 //     // Console.WriteLine("程序结束，等待GC清理未释放的资源。"); // }

这个模式看起来可能有点复杂，但它确实是处理资源管理的最佳实践。它提供了一种健壮、可预测且高效的方式来确保你的应用程序不会因为资源泄漏而崩溃。在我的经验里，遵循这个模式能省去很多不必要的调试麻烦。

文章版权归作者所有，未经允许请勿转载。

THE END