.NET中的那些受特别对待的类型(CriticalFinalizerObject)
转自:http://www.cnblogs.com/yuyijq/archive/2009/08/09/1542435.html
股票里面有个ST股,就是Special Treatment的意思。就是对那些财务出现异常的上市公司,特别处理,在股票名字前面挂个ST,警示投资者注意风险。
这是题外话,今天我们要谈的是,在.NET的世界里,也有这么一些类型啊,受特别的对待(世界的不公平无处不在啊)。当EE碰到这些类型时,并不是像普通的类型那样去对待。我“龌龊”的给这些类型起个名字: ST Type。那到底有哪些类型呢,就我目前所知道的有:
CriticalFinalizerObject
MarshalByRefObject
ContextBoundObject
ValueType
Array
String
Enum
上面几个是在CLR层面上的,也就是这几个类型深入到核心了,会影响到CLR对这些类型的处理行为。
下面就分别对这几个类型的具体作用做一些简单的描述:
首先是CriticalFinalizerObject类型,该类型在System.Runtime.ConstrainedExecution命名空间下,属于mscorlib.dll程序集。
其实CriticalFinalizerObject类型非常简单:
1: [ComVisible(true), SecurityPermission(SecurityAction.InheritanceDemand, UnmanagedCode=true)]
2: public abstract class CriticalFinalizerObject
3: {
4: // Methods
5: [ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
6: protected CriticalFinalizerObject()
7: {
8: }
9:
10: [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
11: ~CriticalFinalizerObject()
12: {
13: }
14: }
简单的居然是空的,不过这个类型有点与一般的类型不同的是,这个类型有个终结方法。大部分类型是没有定义终结方法的(注意,我说的是大部分哦)。如果你不知道给一个类型定义一个终结方法有什么影响,请翻翻MSDN,速查一下。
就这样一个几乎是空的类型,有些什么作用呢?
终结器方法的JIT编译行为不同
要解释这个类型的作用,我们先来了解一下终结方法是干啥的,为什么要定义一个终结方法。我们定义一个终结方法一般是这个类型“消费”了一些本地资源,这些资源是非托管的,也就是CLR管不了。那类型的开发者就必须显式的销毁这些资源,那我们就给这个类型定义一个终结方法(至于是否该定义终结方法,终结方法到底该怎么用,不在本文讨论之列)。当GC确定一个类型是垃圾的时候,就会着手清理这个类型,但是又发现这个类型实现了一个终结方法,GC就会把这些对象放到一个可终结对象的队列里面,然后一一调用这些对象的终结方法,在调用这些终结方法之前,JIT肯定先要编译这个终结方法。但是你想啊,为什么这个时候有GC,除了你手动的调用System.Collect()方法外,那肯定是有新的对象要分配,但是堆中空间不足,既然空间不足,那JITCompiler是否有足够的资源来编译这个方法都是一个问题,那如果没有足够的资源编译这个终结方法,终结方法也就无法调用,这样就造成终结方法内部要销毁的非托管资源也无法释放了。这就会引起资源泄露,资源泄露是一个很大的问题,会造成应用程序运行的不稳定。
上面这一段好像陷入了一种非常矛盾的境地,那有啥办法确保终结方法一定会被JIT呢?那就是CriticalFinalizerObject登场了。
一切直接或间接的从CriticalFinalizerObject派生的类型,在创建的时候JIT就会将这些个类型的终结方法先给编译了。这下好了,你要回收内存的时候可能没有资源即时编译终结方法,那你创建的时候总有资源吧。为了证明这点我们用Visual Studio + SOS来一探究竟,先上示例代码:
先来一个普通的类型
1: using System;
2: using System.Runtime.ConstrainedExecution;
3:
4: public class Program
5: {
6: static void Main()
7: {
8: Foo f = new Foo();
9: //待会儿就在这里下个断点吧
10: f.Test();
11:
12: Console.ReadLine();
13: }
14: }
15:
16: //普通的类型,直接从System.Object继承
17: public class Foo
18: {
19: public void Test()
20: {
21:
22: }
23:
24: ~Foo()
25: {
26:
27: }
28: }
设好断点,F5调试(记得在VisualStudio的工程属性,调试那一栏里选择上“允许非托管代码调试”),然后在立即窗口里输入:
1: .load sos.dll
2: extension C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll loaded
3: !dso
4: PDB symbol for mscorwks.dll not loaded
5: OS Thread Id: 0xfd8 (4056)
6: ESP/REG Object Name
7: 0012f16c 01312db8 Foo
8: 0012f220 01312db8 Foo
9: 0012f224 01312db8 Foo
10: 0012f440 01312db8 Foo
11: 0012f444 01312db8 Foo
12:
13: !do 01312db8
14: Name: Foo
15: MethodTable: 00993090
16: EEClass: 00991358
17: Size: 12(0xc) bytes
18: (E:\Study\ConsoleApplication9\ConsoleApplication9\bin\Debug\ConsoleApplication9.exe)
19: Fields:
20: None
21:
22: !dumpmt -md 00993090
23: EEClass: 00991358
24: Module: 00992c5c
25: Name: Foo
26: mdToken: 02000003 (E:\Study\ConsoleApplication9\ConsoleApplication9\bin\Debug\ConsoleApplication9.exe)
27: BaseSize: 0xc
28: ComponentSize: 0x0
29: Number of IFaces in IFaceMap: 0
30: Slots in VTable: 6
31: --------------------------------------
32: MethodDesc Table
33: Entry MethodDesc JIT Name
34: 79286a70 79104934 PreJIT System.Object.ToString()
35: 79286a90 7910493c PreJIT System.Object.Equals(System.Object)
36: 79286b00 7910496c PreJIT System.Object.GetHashCode()
37: 0099c038 00993078 NONE Foo.Finalize()
38: 0099c040 00993084 JIT Foo..ctor()
39: 0099c030 00993068 NONE Foo.Test()
(对命令稍做解释,.load sos.dll加载sos模块,!dso就是DumpStackObjects,输出栈上所有的对象,然后找到我们的测试类型Foo的地址为01312db8,使用!do 01312db8,输出堆中这个对象的一些信息,我们这里需要的是方法表MethodTable的地址00993090,然后使用!dumpmt –md 00993090输出这个方法的方法表)
在最后列出的方法表的条目里,我们发现终结方法Foo.Finalize(注意,虽然在C#里,终结方法的定义是在类型名称前面加一个~,但是经过C#编译器后,这个方法在IL里就是Finalize)这个时候没有被JIT。好了,我们看看如果是从CriticalFinalizerObject派生呢?
1: using System;
2: using System.Runtime.ConstrainedExecution;
3:
4: public class Program
5: {
6: static void Main()
7: {
8: Foo f = new Foo();
9: f.Test();
10:
11: Console.ReadLine();
12: }
13: }
14:
15: public class Foo : CriticalFinalizerObject
16: {
17: public void Test()
18: {
19:
20: }
21:
22: ~Foo()
23: {
24:
25: }
26: }
代码几乎一模一样,真的有什么不同么:
前面一部分就不再列了
1: !dumpmt -md 00993090
2: EEClass: 00991360
3: Module: 00992c5c
4: Name: Foo
5: mdToken: 02000003 (E:\Study\ConsoleApplication9\ConsoleApplication9\bin\Debug\ConsoleApplication9.exe)
6: BaseSize: 0xc
7: ComponentSize: 0x0
8: Number of IFaces in IFaceMap: 0
9: Slots in VTable: 6
10: --------------------------------------
11: MethodDesc Table
12: Entry MethodDesc JIT Name
13: 79286a70 79104934 PreJIT System.Object.ToString()
14: 79286a90 7910493c PreJIT System.Object.Equals(System.Object)
15: 79286b00 7910496c PreJIT System.Object.GetHashCode()
16: 0099c038 00993078 JIT Foo.Finalize()
17: 0099c040 00993084 JIT Foo..ctor()
18: 0099c030 00993068 NONE Foo.Test()
呀,这个时候Finalize真的已经被JIT了呢。可这个时候明明类型才刚刚初始化啊,离调用终结方法很远啊,这就是CriticalFinalizeObject的作用。
终结器方法的执行顺序不同
除了上面这一点以外啊,还有就是,CLR会先调用不是从CriticalFinalizerObject派生的类型的终结方法,然后再调用从CriticalFinalizerObject类型派生的类型终结方法。这样有什么好处呢?这样就确保了在普通的类型里的终结方法里,一定可以访问得到从CriticalFinalizerObject类型派生的类型,以免造成很微妙的现象。
比如文件流FileStream类型,它的终结器方法如下所示:
~FileStream()
{
if (this._handle != null)
{
this.Dispose(false);
}
}
注意到,这里的_handle字段是SafeFileHandle类型的,而SafeFileHandle的继承树是:
SafeFileHandle->SafeHandleZeroOrMinusOneIsInvalid->SafeHandle->CriticalFinalizerObject,这样在FileStream的终结方法执行时,就会确保_handle还没有被垃圾回收了。
终结器方法必定会执行
除此之外,即使是AppDomain被宿主给卸载了,从CriticalFinalizerObject派生的类型的终结方法还是会被执行,这样确保了非托管资源一定会得到回收。
有人肯定会说:你说了这么多,可在我的编程生涯中根本就没碰到过CriticalFinalizerObject类型啊。确实,我们几乎没有碰到过这个类型,更没有自己要实现从这个类型派生的类型。这是为什么呢?实际上这一切都被微软给封装起来了,同在mscorlib.dll程序集内,System.Runtime.InteropServices命名空间下有一个类型SafeHandle,因为对一些非托管资源来说基本上都是一些句柄,所以SafeHandle提供了一种统一的处理方式,来处理这些句柄。然后,对于所有的非托管资源在类库里基本上都有对应的SafeHandle的派生类,你可以在Microsoft.Win32.SafeHandles找到这些句柄。还有一些其他的句柄在FCL中,但它们都是internal的,没有开放给我们开发人员,比如在System.Data.SqlClient下的SNIHandle表示与数据库连接的句柄。
参考资料
《CLR via C#》