建议按照下面的模式实现IDisposable接口:

 public class Foo: IDisposable
{
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
} protected virtual void Dispose(bool disposing)
{
if (!m_disposed)
{
if (disposing)
{
// Release managed resources
} // Release unmanaged resources m_disposed = true;
}
} ~Foo()
{
Dispose(false);
} private bool m_disposed;
}

  

在.NET的对象中实际上有两个用于释放资源的函数:Dispose和Finalize。Finalize的目的是用于释放非托管的资源,而Dispose是用于释放所有资源,包括托管的和非托管的。

在这个模式中,void Dispose(bool disposing)函数通过一个disposing参数来区别当前是否是被Dispose()调用。如果是被Dispose()调用,那么需要同时释放托管和非托管的资源。如果是被~Foo()(也就是C#的Finalize())调用了,那么只需要释放非托管的资源即可。

这是因为,Dispose()函数是被其它代码显式调用并要求释放资源的,而Finalize是被GC调用的。在GC调用的时候Foo所引用的其它托管对象可能还不需要被销毁,并且即使要销毁,也会由GC来调用。因此在Finalize中只需要释放非托管资源即可。另外一方面,由于在Dispose()中已经释放了托管和非托管的资源,因此在对象被GC回收时再次调用Finalize是没有必要的,所以在Dispose()中调用GC.SuppressFinalize(this)避免重复调用Finalize。

然而,即使重复调用Finalize和Dispose也是不存在问题的,因为有变量m_disposed的存在,资源只会被释放一次,多余的调用会被忽略过去。

因此,上面的模式保证了:

1、 Finalize只释放非托管资源;

2、 Dispose释放托管和非托管资源;

3、 重复调用Finalize和Dispose是没有问题的;

4、 Finalize和Dispose共享相同的资源释放策略,因此他们之间也是没有冲突的。

在C#中,这个模式需要显式地实现,其中C#的~Foo()函数代表了Finalize()。而在C++/CLI中,这个模式是自动实现的,C++的类析构函数则是不一样的。

按照C++语义,析构函数在超出作用域,或者delete的时候被调用。在Managed C++(即.NET 1.1中的托管C++)中,析构函数相当于CLR中的Finalize()方法,在垃圾收集的时候由GC调用,因此,调用的时机是不明确的。在.NET 2.0的C++/CLI中,析构函数的语义被修改为等价与Dispose()方法,这就隐含了两件事情:

1、 所有的C++/CLI中的CLR类都实现了接口IDisposable,因此在C#中可以用using关键字来访问这个类的实例。

2、 析构函数不再等价于Finalize()了。

对于第一点,这是一件好事,我认为在语义上Dispose()更加接近于C++析构函数。对于第二点,Microsoft进行了一次扩展,做法是引入了“!”函数,如下所示:

 public ref class Foo
{
public:
Foo();
~Foo(); // destructor
!Foo(); // finalizer
};

“!”函数(我实在不知道应该怎么称呼它)取代原来Managed C++中的Finalize()被GC调用。MSDN建议,为了减少代码的重复,可以写这样的代码:

 ~Foo()
{
//释放托管的资源
this->!Foo();
} !Foo()
{
//释放非托管的资源
}

对于上面这个类,实际上C++/CLI生成对应的C#代码是这样的:

对于上面这个类,实际上C++/CLI生成对应的C#代码是这样的:

 public class Foo

 {
private void !Foo()
{
// 释放非托管的资源
} private void ~Foo()
{
// 释放托管的资源
!Foo();
} public Foo()
{
} public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
} protected virtual void Dispose(bool disposing)
{
if (disposing)
{
~Foo();
}
else
{
try
{
!Foo();
}
finally
{
base.Finalize();
}
}
} protected void Finalize()
{
Dispose(false);
}
}

由于~Foo()和!Foo()不会被重复调用(至少MS这样认为),因此在这段代码中没有和前面m_disposed相同的变量,但是基本的结构是一样的。

并且,可以看到实际上并不是~Foo()和!Foo()就是Dispose和Finalize,而是C++/CLI编译器生成了两个Dispose和Finalize函数,并在合适的时候调用它们。C++/CLI其实已经做了很多工作,但是唯一的一个问题就是依赖于用户在~Foo()中调用!Foo()。

关于资源释放,最后一点需要提的是Close函数。在语义上它和Dispose很类似,按照MSDN的说法,提供这个函数是为了让用户感觉舒服一点,因为对于某些对象,例如文件,用户更加习惯调用Close()。

然而,毕竟这两个函数做的是同一件事情,因此MSDN建议的代码就是:

 public void Close()
{
Dispose(();
}

这里直接调用不带参数的Dispose函数以获得和Dispose相同的语义。这样似乎就圆满了,但是从另外一方面说,如果同时提供了Dispose和Close,会给用户带来一些困惑。没有看到代码细节的前提下,很难知道这两个函数到底有什么区别。因此在.NET的代码设计规范中说,这两个函数实际上只能让用户用一个。因此建议的模式是:

 public class Foo: IDisposable
{
public void Close()
{
Dispose();
} void IDisposable.Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
} protected virtual void Dispose(bool disposing)
{
// 同前
}
}

这里使用了一个所谓的接口显式实现:void IDisposable.Dispose()。这个显式实现只能通过接口来访问,但是不能通过实现类来访问。因此:

 Foo foo = new Foo();

 foo.Dispose(); // 错误
(foo as IDisposable).Dispose(); // 正确

----------------------------------以下是CSDN上一位高手的总结----------------------------------------------

1、Finalize方法(C#中是析构函数,以下称析构函数)是用于释放非托管资源的,而托管资源会由GC自动回收。所以,我们也可以这样来区分托管和非托管资源。所有会由GC自动回收的资源,就是托管的资源,而不能由GC自动回收的资源,就是非托管资源。在我们的类中直接使用非托管资源的情况很少,所以基本上不用我们写析构函数。

2、大部分的非托管资源会给系统带来很多负面影响,例如数据库连接不被释放就可能导致连接池中的可用数据库连接用尽。文件不关闭会导致其它进程无法读写这个文件等等。

实现模型:   
    1、由于大多数的非托管资源都要求可以手动释放,所以,我们应该专门为释放非托管资源公开一个方法。实现IDispose接口的Dispose方法是最好的模型,因为C#支持using语句快,可以在离开语句块时自动调用Dispose方法。 
  
     2、虽然可以手动释放非托管资源,我们仍然要在析构函数中释放非托管资源,这样才是安全的应用程序。否则如果因为程序员的疏忽忘记了手动释放非托管资源,那么就会带来灾难性的后果。所以说在析构函数中释放非托管资源,是一种补救的措施,至少对于大多数类来说是如此。

3、由于析构函数的调用将导致GC对对象回收的效率降低,所以如果已经完成了析构函数该干的事情(例如释放非托管资源),就应当使用SuppressFinalize方法告诉GC不需要再执行某个对象的析构函数。

4、析构函数中只能释放非托管资源而不能对任何托管的对象/资源进行操作。因为你无法预测析构函数的运行时机,所以,当析构函数被执行的时候,也许你进行操作的托管资源已经被释放了。这样将导致严重的后果。

5、(这是一个规则)如果一个类拥有一个实现了IDispose接口类型的成员,并创建(注意是创建,而不是接收,必须是由类自己创建)它的实例对象,则这个类也应该实现IDispose接口,并在Dispose方法中调用所有实现了IDispose接口的成员的Dispose方法。 只有这样的才能保证所有实现了IDispose接口的类的对象的Dispose方法能够被调用到,确保可以手动释放任何需要释放的资源。

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

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

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

  1. Finalize是CRL提供的一个机制, 它保证如果一个类实现了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
{
//析构函数自动生成 Finalize 方法和对基类的 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(),提高了非托管资源的使用效率并提升了系统性能

可以参考SqlConnection对象的New, Open, Close(内部调用Dispose())的使用经历可以加深对他们的理解.谢谢!

.net 高效管理稀缺资源(数据库资源,文件资源等)的更多相关文章

  1. Android 的assets文件资源与raw文件资源读取

    版权声明:本文为博主原创文章,未经博主同意不得转载. https://blog.csdn.net/zpf8861/article/details/34504183   res/raw和assets的同 ...

  2. PyQt(Python+Qt)学习随笔:Qt Designer中图像资源的使用及资源文件的管理

    一.概述 在Qt Designer中要使用图片资源有三种方法:通过图像文件指定.通过资源文件指定.通过theme主题方式指定,对应的设置界面在需要指定图像的属性栏如windowIcon中通过点击属性设 ...

  3. Visual Studio下,打开资源视图rc文件,提示在另一个编辑器中打开

    在网上搜索关键字: rc文件   提示在另一个编辑器中打开 很多地方的回答都是说: rc文件以代码形式打开了,只要关掉后再打开就可以了. 但是,很多时候,当关闭掉RC的代码文件以后,发现VS的RC文件 ...

  4. Spring Security教程(五):自定义过滤器从数据库从获取资源信息

    在之前的几篇security教程中,资源和所对应的权限都是在xml中进行配置的,也就在http标签中配置intercept-url,试想要是配置的对象不多,那还好,但是平常实际开发中都往往是非常多的资 ...

  5. 2017.2.28 activiti实战--第五章--用户与组及部署管理(二)部署流程资源

    学习资料:<Activiti实战> 第五章 用户与组及部署管理(二)部署流程资源 内容概览:讲解流程资源的读取与部署. 5.2 部署流程资源 5.2.1 流程资源 流程资源常用的有以下几种 ...

  6. Robot Framework(八) 资源和变量文件

    2.7资源和变量文件 测试用例文件和测试套件初始化文件中的用户关键字和变量只能在创建它们的文件中使用,但资源文件提供了共享它们的机制.由于资源文件结构非常接近测试用例文件,因此很容易创建它们. 变量文 ...

  7. JavaWeb中读取文件资源的路径问题

    在做javaweb开发的时候,我们可能会需要从本地硬盘上读取某一个文件资源,或者修改某一个文件,这个时候就需要先找到这个文件,然后用FileInputStrem等文件字节.字符流来将这个文件读取到内存 ...

  8. 一份关于Swift语言学习资源的整理文件

    一份关于Swift语言学习资源的整理文件     周银辉 在这里下载 https://github.com/ipader/SwiftGuide

  9. iOS WebView 加载本地资源(图片,文件等)

    https://www.cnblogs.com/dhui69/p/5596917.html iOS WebView 加载本地资源(图片,文件等) NSString *path = [[NSBundle ...

随机推荐

  1. Entity FrameWork 与 NHibernate

      1 Nhibernate 展示了NHibernate在数据库和用程序之间提供了一个持久层. 应用程序自己提供ADO.NET连接,并且自行管理事务.NHibernate体系结构如图1-51所示.它体 ...

  2. linux取某个字段排重

    排重统计 cat a.txt | awk -F ';' '{print $2}' | sort -u | wc -l

  3. ASP.NET MVC 开源项目学习之ProDinner (一)

    首先在github上面将ProDinner项目通过 Git Bash 克隆到本地,接下来我们开始分析这个项目吧~ 系统采用.Net 4.5, Asp.net Mvc 5,VS2012,Sql serv ...

  4. [drp 7]转发和重定向的区别

    导读:类似于response.sendRedirect(request.getContextPath()+"/servlet/item/SearchItemServlet");和r ...

  5. 【缓存】Sql Server 2005/2008 SqlCacheDependency查询通知的使用总结

    Sql server 7.0/2000下 SqlCacheDependency使用轮询的方式进行缓存失效检查, 虽然ms说对服务器压力不大, 但还是有一些的, 而且对于不常改动的混存内容无休止的轮询感 ...

  6. com.google.inject.CreationException: Guice creation errors

    错误的原因:xml文件中方法名重复或错误

  7. 二十一、contextMap中放的常用数据

    二十一.contextMap中放的常用数据 request:请求范围的数据.即ServletRequest中的那个Map parameters:请求参数的数据.即request.getParamete ...

  8. .NET Web开发总结(三)

    第五章 ASP.NET 页面语法 本章详细讲解.NET页面的语法结构     一般情况下  一个ASP.NET页面要包括页面编译指令 HTML页面框架及Web窗体     服务器端控件  服务器端代码 ...

  9. SMTP Failed on Process Scheduler

    If you are seeing messages like this in your message log when running a process through the process ...

  10. 一些peoplecode小技巧平【二】

    1. Set component changed page field property: For understanding this open a page in application desi ...