public class Class1 : IDisposable { public Class1() { } ~Class1 () { //垃圾回收器将调用该方法，因此参数需要为false。 Dispose (false); } //该方法定义在IDisposable接口中。 public void Dispose () { //该方法由程序调用，在调用该方法之后对象将被终结。 //因为我们不希望垃圾回收器再次终结对象，因此需要从终结列表中去除该对象。 GC.SuppressFinalize (this); //因为是由程序调用该方法的，因此参数为true。 Dispose (true); } //所有与回收相关的工作都由该方法完成 private void Dispose(bool disposing) { lock(this) //避免产生线程错误。 { if (disposing) { //需要程序员完成释放对象占用的资源。 } //对象将被垃圾回收器终结。在这里添加其它和清除对象相关的代码。 } } }

对.Net 垃圾回收Finalize 和Dispose的理解

我们先来谈谈析构函数。

析构函数是不可继承的。因此，除了自已所声明的析构函数外，一个类不具有其他析构函数。

由于析构函数要求不能带有参数，因此它不能被重载，所以一个类至多只能有一个析构函数。

析构函数是自动调用的，它不能被显式调用。当任何代码都不再可能使用一个实例时，该实例就符合被销毁的条件。此后，它所对应的实例析构函数随时均可能被调用。销毁一个实例时，按照从派生程度最大到派生程度最小的顺序，调用该实例的继承链中的各个析构函数。析构函数可以在任何线程上执行。

下列示例的输出

using System;

class A

{

~A() {

Console.WriteLine("A's destructor");

}

}

class B: A

{

~B() {

Console.WriteLine("B's destructor");

}

}

class Test

{

static void Main() {

B b = new B();

b = null;

GC.Collect();

GC.WaitForPendingFinalizers();

}

}

为

B's destructor

A's destructor

这是由于继承链中的析构函数是按照从派生程度最大到派生程度最小的顺序调用的。

析构函数实际上是重写了 System.Object 中的虚方法 Finalize。C# 程序中不允许重写此方法或直接调用它（或它的重写）。例如，下列程序

class A

{

override protected void Finalize() {}   // error

public void F() {

this.Finalize();                     // error

}

}

包含两个错误。

编译器的行为就像此方法和它的重写根本不存在一样。因此，以下程序：

class A

{

void Finalize() {}                     // permitted

}

是有效的，所声明的方法隐藏了 System.Object 的 Finalize 方法。


好，现在我们开始来谈谈Finalize 和Dispose。

Finalize 和Dispose(bool disposing)和 Dispose() 的相同点:

这三者都是为了释放非托管资源服务的.

Finalize 和 Dispose() 和Dispose(bool disposing)的不同点:

1. Finalize是CLR提供的一个机制, 它保证如果一个类实现了Finalize方法,那么当该类对象被垃圾回收时,垃圾回收器会调用Finalize方法.而该类的开发者就必须在Finalize方法中处理 非托管资源的释放. 但是什么时候会调用Finalize由垃圾回收器决定,该类对象的使用者(客户)无法控制.从而无法及时释放掉宝贵的非托管资源.由于非托管资源是比较宝贵了,所以这样会降低性能.
2. Dispose(bool disposing)不是CRL提供的一个机制, 而仅仅是一个设计模式(作为一个IDisposable接口的方法),它的目的是让供类对象的使用者(客户)在使用完类对象后,可以及时手动调用非托管资源的释放,无需等到该类对象被垃圾回收那个时间点.这样类的开发者就只需把原先写在Finalize的释放非托管资源的代码,移植到Dispose(bool disposing)中.  而在Finalize中只要简单的调用 "Dispose(false)"(为什么传递false后面解释)就可以了.

这个时候我们可能比较疑惑,为什么还需要一个Dispose()方法?难道只有一个Dispose(bool disposing)或者只有一个Dispose()不可以吗?
答案是: 
        只有一个Dispose()不可以. 为什么呢?因为如果只有一个Dispose()而没有Dispose(bool disposing)方法.那么在处理实现非托管资源释放的代码中无法判断该方法是客户调用的还是垃圾回收器通过Finalize调用的.无法实现判断如果是客户手动调用,那么就不希望垃圾回收器再调用Finalize()(调用GC.SupperFinalize方法).另一个可能的原因(:我们知道如果是垃圾回收器通过Finalize调用的,那么在释放代码中我们可能还会引用其他一些托管对象,而此时这些托管对象可能已经被垃圾回收了, 这样会导致无法预知的执行结果(千万不要在Finalize中引用其他的托管对象).

        所以确实需要一个bool disposing参数, 但是如果只有一个Dispose(bool disposing),那么对于客户来说,就有一个很滑稽要求,Dispose(false)已经被Finalize使用了,必须要求客户以Dispose(true)方式调用,但是谁又能保证客户不会以Dispose(false)方式调用呢?所以这里采用了一中设计模式:重载  把Dispose(bool disposing)实现为 protected, 而Dispose()实现为Public,那么这样就保证了客户只能调用Dispose()(内部调用Dispose(true)//说明是客户的直接调用),客户无法调用Dispose(bool disposing).

范例如下:

public class BaseResource: IDisposable
{
  //前面我们说了析构函数实际上是重写了 System.Object 中的虚方法 Finalize, 默认情况下,一个类是没有析构函数的,也就是说,对象被垃圾回收时不会被调用Finalize方法
  ~BaseResource()     
   {
      // 为了保持代码的可读性性和可维护性,千万不要在这里写释放非托管资源的代码
      // 必须以Dispose(false)方式调用,以false告诉Dispose(bool disposing)函数是从垃圾回收器在调用Finalize时调用的
      Dispose(false);
   }
  
  
   // 无法被客户直接调用
   // 如果 disposing 是 true, 那么这个方法是被客户直接调用的,那么托管的,和非托管的资源都可以释放
   // 如果 disposing 是 false, 那么函数是从垃圾回收器在调用Finalize时调用的,此时不应当引用其他托管对象所以,只能释放非托管资源
   protected virtual void Dispose(bool disposing)
   {
     
         // 那么这个方法是被客户直接调用的,那么托管的,和非托管的资源都可以释放
         if(disposing)
         {
            // 释放 托管资源
            OtherManagedObject.Dispose();
         }
        
        
         //释放非托管资源
         DoUnManagedObjectDispose();
        
                
         // 那么这个方法是被客户直接调用的,告诉垃圾回收器从Finalization队列中清除自己,从而阻止垃圾回收器调用Finalize方法.        
         if(disposing) 
           GC.SuppressFinalize(this);  
          
   } 
  
   //可以被客户直接调用
   public void Dispose()
   {
     //必须以Dispose(true)方式调用,以true告诉Dispose(bool disposing)函数是被客户直接调用的
      Dispose(true);     
   }
}

上面的范例达到的目的:

1/ 如果客户没有调用Dispose(),未能及时释放托管和非托管资源,那么在垃圾回收时,还有机会执行Finalize(),释放非托管资源,但是造成了非托管资源的未及时释放的空闲浪费

2/ 如果客户调用了Dispose(),就能及时释放了托管和非托管资源,那么该对象被垃圾回收时,不回执行Finalize(),提高了非托管资源的使用效率并提升了系统性能

• 可扩展性：有了新的需求，新的性能可以容易添加到系统中，不影响现有的性能，也不会带来新的缺陷。
• 可修改性：系统一部分的代码要修改时不会破坏系统的现有结构，也不会影响到其它的部分。
• 可替换性：可以将系统中的某些代码替换为相同接口的其它类，不会影响到系统。

设计模式的设计原则：

• “开放--封闭”原则：
  设计模式的核心原则。软件实体（类，模块，函数）对于扩展是开放的,对于修改是关闭的 。实现开闭原则的关键就是抽象化。“开放--封闭”原则中，不允许修改的是抽象的类或者接口。允许扩展的是具体的实现类,抽象类和接口在“开-闭”原则中扮演着极其重要的角色 。
• 封装变化点原则：
  这是对"开-闭"原则最好的实现..不要把你的可变因素放在多个类中,或者散落在程序的各个角落..你应该将可变的因素,封套起来..并且切忌不要把所用的可变因素封套在一起..最好的解决办法是,分块封套你的可变因素!!避免超大类,超长类,超长方法的出现!!给你的程序增加艺术气息,将程序艺术化是我们的目标!!
• 里氏代换原则：
  任何基类可以出现的地方，子类也可以出现 。
• 依赖倒转原则：
  要依赖抽象,而不要依赖具体的实现。抽象不应当依赖于细节，细节应当依赖于抽象；要针对接口编程，不要针对实现编程
• 单一职责原则：
  一个类应该只有一个引起它变化的原因。
• 接口隔离法则 ：
  为了做到尽可能小的耦合性，我们需要使用接口来规范类，用接口来约束类。要达到迪米特法则的要求，最好就是实现接口隔离法则。使用多个专门的接口比使用单一的总接口要好.从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口应当简单地代表一个角色，而不是多个角色。多个演员可以同时演一个角色，就象孙悟空的孩儿一样。
• 合成/聚合原则：
  要尽量使用合成/聚合原则,而不是继承关系达到软件复用的目的。聚合用来表示“拥有”或整体与部分的关系，而合成则用来表示一种强得多的“拥有”关系。在一个合成关系里，部分和整体的生命周期是一样的。合成就象所说的“合成品”，拆开就坏。
• 迪米特法则：
  系统中的类,尽量不要与其他类互相作用，减少类之间的耦合度。 一个对象应当对其它对象有尽可能少的了解，两个类不必直接通信，可以通过第三者(抽象)转发这个调用，这个抽象的第三者可以是门面，可以是调停者，甚至是一个抽象类或接口，模块要独立，独立被封装，他们只靠public的API来通信，只要有可能，一个类应当设计成不变类，其属性都应该是私有的，如果一个类有太多的public访问权限的方法，可以考虑使用多个类把一个类的私有方法和公有方法分开。

聚合(Aggregation):

   这是一种松散的对象间的关系.举个例子:计算机和他的外围设备就是一例.

  用来表示拥有关系或者整体与部分的关系。

组合(Composition):

这是一种非常强的对象间的关系,举个例子,树和它的树叶之间的关系.

在一个合成里，部分与整体的生命周期都是一样的。一个合成的新对象完全拥有对其组成

部分的支配权。包括他们的创建和毁灭。

最后总结一下：

聚合：

•  聚合有时能够不依赖部分而存在，有时又不能
• 部分可以独立于聚合而存在
• 如果有一部分遗失，聚合会给人一种不完全的感觉
• 部分的所有权可以由几个聚合来共享，比如打印机

合成：

• 部分某一时刻只能属于某一个组成
• 组成唯一的负责处理它的所有部分--这就意味着负责他们的创建与销毁
• 倘若对于部分的职责由其他对象来承担的话，组成也就可以放松这些职责。
• 如果组成销毁的话，它必须销毁所有的部分，或者把负责他们的权利转移给其他对象。

设计模式所解决的问题：
通过显示指定类创建对象:
     相关的设计模式：简单工厂、工厂方法、抽象工厂。
紧耦合:
    相关的设计模式：抽象工厂、命令模式、外观模式、中介者模式、观察者模式、职责链模式等。
对对象表示或实现的依赖:
     相关的设计模式：抽象工厂、桥接模式、备忘录模式、代理模式等。
通过生成子类扩展功能:
     相关的设计模式：桥接模式、职责链模式、组合模式、装饰模式、观察者模式、策略模式等。
有能方便地修改类:
     相关的设计模式：适配器模式、装饰模式、访问者模式等。
对算法的依赖:
     相关设计模式： 生成器模式、迭代模式、策略模式、模板方法模式、访问者模式等。
对软硬件环境的依赖:
     相关设计模式：抽象工厂模式、桥接模式等。

参考：http://ankye1234.blog.163.com/blog/static/964828920075444512292/