C#中的析构函数

待我称王封你为后i 2022-12-11 03:21 161阅读 0赞

析构函数

析构函数(destructor) 与构造函数相反，当对象脱离其作用域时（例如对象所在的函数已调用完毕），系统自动执行析构函数。析构函数往往用来做“清理善后” 的工作（例如在建立对象时用new开辟了一片内存空间，应在退出前在析构函数中用delete释放）。

以C++语言为例，析构函数名也应与类名相同，只是在函数名前面加一个波浪符~，例如~stud( )，以区别于构造函数。它不能带任何参数，也没有返回值（包括void类型）。只能有一个析构函数，不能重载。如果用户没有编写析构函数，编译系统会自动生成一个缺省的析构函数，它也不进行任何操作。所以许多简单的类中没有用显式的析构函数。  
  
解构器

我们知道，‘解构器’被用来清除类的事例。当我们在C\#中使用解构器是，我们必须记住以下几点：

一个类只能有一个解构器。  
       解构器不能被继承或重载。  
       解构器不能被调用。他们是自动被（编译器）调用的。  
       解构器不能带修饰或参数。  
   下面是类MyClass解构器的一个声明：

~ Class()     
\{    
    // Cleaning up code goes here    
\}

程序员不能控制解构器何时将被执行因为这是由垃圾收集器决定的。垃圾收集器检查不在被应用程序使用的对象。它认为这些条件是符合清楚的并且收回它们的内存。解构器也在程序退出时被调用。当解构器执行时其背后所发生的那一幕是解构器隐式调用对象基类的Object.Finalize方法。因此上述解构器代码被隐含转化成：

protected override void Finalize()    
\{    
    try    
    \{    
       // Cleaning up .    
    \}    
    finally    
    \{    
       base.Finalize();    
    \}  
\}

现在，让我们看一个解构器怎样被调用的例子。我们有三个类A，B和C 。B派生自A，C派生自B。每个类有它们自己的构造器和解构。在类App的main函数中，我们创建C的对象。

using System;    
class A    
\{    
public A()    
\{    
   Console.WriteLine("Creating A");    
\}    
~A()    
\{    
   Console.WriteLine("Destroying A");    
\}    
\}    
     
class B:A    
\{    
public B()    
\{    
   Console.WriteLine("Creating B");    
\}    
~B()    
\{    
   Console.WriteLine("Destroying B");    
\}    
     
\}    
class C:B    
\{    
public C()    
\{    
   Console.WriteLine("Creating C");    
\}    
     
~C()    
\{    
   Console.WriteLine("Destroying C");    
\}    
\}    
class App    
\{    
public static void Main()    
\{    
   C c=new C();    
   Console.WriteLine("Object Created ");    
   Console.WriteLine("Press enter to Destroy it");    
   Console.ReadLine();    
   c=null;    
   //GC.Collect();    
   Console.Read();    
\}    
\}  
    
     正如我们预料的，基类的构造器将会被执行并且程序会等待用户按‘enter’。当这个发生，我们把类C的对象置为null.但解构器没有被执行..！！？？正像我们所说的，程序员无法控制解构器何时被执行因为这是由垃圾搜集器决定的。但程序退出时解构器被调用了。你能通过重定向程序的o/p到文本文件来检查这个。我将它输出在这里。注意到基类的解构器被调用了，因为在背后base.Finalize()被调用了。

Creating A  
Creating B  
Creating C  
Object Created  
Press enter to Destroy it  
Destroying C  
Destroying B  
Destroying A  
　  
     所以，如果一旦你使用完对象你就想调用解构器，你该怎么做？有两个方法：

调用垃圾搜集器来清理。

实现IDisposable的Dispose方法。

调用垃圾搜集器

你能通过调用GC.Collect方法强制垃圾搜集器来清理内存，但在大多数情况下，这应该避免因为它会导致性能问题。在上面的程序中，在GC.Collect()处移除注释。编译并运行它。现在，你能看到解构器在控制台中被执行了。

实现IDisposable接口

IDisposable 接口包括仅有的一个公共方法，其声明为void Dispose()。我们能实现这个方法来关闭或释放非托管资源如实现了这个接口的类事例所控制的文件，流，和句柄等。这个方法被用做所有任务联合对象的资源释放。当实现了这个方法，对象必须寻求确保所有拥有的资源被继承结构中关联的资源也释放（不能把握，翻不出来）。

class MyClass:IDisposable    
\{    
     public void Dispose()    
\{    
   //implementation    
\}    
\}

当我们实现了IDisposable接口时，我们需要规则来确保Dispose被适当地调用。

联合使用解构器和IDisposable接口

Public class MyClass:IDisposable    
\{    
private bool IsDisposed=false;    
public void Dispose()    
\{    
   Dispose(true);    
   GC.SupressFinalize(this);    
\}    
protected void Dispose(bool Diposing)    
\{    
   if(!IsDisposed)    
   \{    
   if(Disposing)    
   \{    
    //Clean Up managed resources    
   \}    
   //Clean up unmanaged resources    
\}    
IsDisposed=true;    
\}    
~MyClass()    
\{    
   Dispose(false);    
\}    
\}

在这里重载了Dispose(bool)来做清理工作，并且所有的清理代码都仅写在这个方法中。这个方法被解构器和IDisposable.Dispose()两着调用。我们应该注意Dispose(bool)没有在任何地方被调用除了在IDisposable.Dispose()和解构器中。

当一个客户调用IDisposable.Dispose()时,客户特意地想要清理托管的和非托管资源，并且因此完成清理工作。有一件你必须注意的事情是我们在清理资源之后立即调用了GC.SupressFinalize(this)。这个方法通知垃圾搜集器不需要调用解构器，因为我们已经做了清理。

注意上面的例子，解构器使用参数false调用Dispose。这里，我们确信垃圾搜集器搜集了托管资源。我们仅仅做非托管资源的清理。

结论

尽管如此我们花费一些时间实现IDisposable接口，如果客户不能合适地调用它们会怎样？为此C\#有一个酷的解决方案。‘using’代码块。它看起来像这样：

using (MyClass objCls =new MyClass())    
\{    
     
\}  
　  
     当控制从using块通过成功运行到结束或者抛出异常退出时，MyClass的IDispose.Dispose()将会被执行。记住你例示的对象必须实现System.IDisposable接口。using语句定义了哪个对象将被清除的一个范围。  
  
注：  
   构造函数与析构函数的区别：  
      构造函数和析构函数是在类体中说明的两种特殊的成员函数。  
      构造函数的功能是在创建对象时，使用给定的值来将对象初始化。  
      析构函数的功能是用来释放一个对象的。在对象删除前，用它来做一些清理工作，它与构造函数的功能正好相反。

[https://www.cnblogs.com/paper/archive/2009/07/31/1535998.html][https_www.cnblogs.com_paper_archive_2009_07_31_1535998.html]

[https_www.cnblogs.com_paper_archive_2009_07_31_1535998.html]: https://www.cnblogs.com/paper/archive/2009/07/31/1535998.html