.NET中的那些受特别对待的类型(CriticalFinalizerObject)

股票里面有个ST股，就是Special Treatment的意思。就是对那些财务出现异常的上市公司，特别处理，在股票名字前面挂个ST，警示投资者注意风险。

这是题外话，今天我们要谈的是，在.NET的世界里，也有这么一些类型啊，受特别的对待（世界的不公平无处不在啊）。当EE碰到这些类型时，并不是像普通的类型那样去对待。我“龌龊”的给这些类型起个名字： ST Type。那到底有哪些类型呢，就我目前所知道的有：

CriticalFinalizerObject

MarshalByRefObject

ContextBoundObject

ValueType

Array

String

Enum

上面几个是在CLR层面上的，也就是这几个类型深入到核心了，会影响到CLR对这些类型的处理行为。

下面就分别对这几个类型的具体作用做一些简单的描述：

首先是CriticalFinalizerObject类型，该类型在System.Runtime.ConstrainedExecution命名空间下，属于mscorlib.dll程序集。

其实CriticalFinalizerObject类型非常简单：

[ComVisible(true), SecurityPermission(SecurityAction.InheritanceDemand, UnmanagedCode=true)]
public abstract class CriticalFinalizerObject
{
    // Methods
    [ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
    protected CriticalFinalizerObject()
    {
    }

    [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
    ~CriticalFinalizerObject()
    {
    }
}

简单的居然是空的，不过这个类型有点与一般的类型不同的是，这个类型有个终结方法。大部分类型是没有定义终结方法的（注意，我说的是大部分哦）。如果你不知道给一个类型定义一个终结方法有什么影响，请翻翻MSDN，速查一下。

就这样一个几乎是空的类型，有些什么作用呢？

终结器方法的JIT编译行为不同

要解释这个类型的作用，我们先来了解一下终结方法是干啥的，为什么要定义一个终结方法。我们定义一个终结方法一般是这个类型“消费”了一些本地资源，这些资源是非托管的，也就是CLR管不了。那类型的开发者就必须显式的销毁这些资源，那我们就给这个类型定义一个终结方法（至于是否该定义终结方法，终结方法到底该怎么用，不在本文讨论之列）。当GC确定一个类型是垃圾的时候，就会着手清理这个类型，但是又发现这个类型实现了一个终结方法，GC就会把这些对象放到一个可终结对象的队列里面，然后一一调用这些对象的终结方法，在调用这些终结方法之前，JIT肯定先要编译这个终结方法。但是你想啊，为什么这个时候有GC，除了你手动的调用System.Collect()方法外，那肯定是有新的对象要分配，但是堆中空间不足，既然空间不足，那JITCompiler是否有足够的资源来编译这个方法都是一个问题，那如果没有足够的资源编译这个终结方法，终结方法也就无法调用，这样就造成终结方法内部要销毁的非托管资源也无法释放了。这就会引起资源泄露，资源泄露是一个很大的问题，会造成应用程序运行的不稳定。

上面这一段好像陷入了一种非常矛盾的境地，那有啥办法确保终结方法一定会被JIT呢？那就是CriticalFinalizerObject登场了。

一切直接或间接的从CriticalFinalizerObject派生的类型，在创建的时候JIT就会将这些个类型的终结方法先给编译了。这下好了，你要回收内存的时候可能没有资源即时编译终结方法，那你创建的时候总有资源吧。为了证明这点我们用Visual Studio + SOS来一探究竟，先上示例代码：

先来一个普通的类型

using System;
using System.Runtime.ConstrainedExecution;

public class Program
{
    static void Main()
    {
        Foo f = new Foo();
        //待会儿就在这里下个断点吧
        f.Test();

        Console.ReadLine();
    }
}

//普通的类型，直接从System.Object继承
public class Foo
{
    public void Test()
    {

    }

    ~Foo()
    {

    }
}

设好断点，F5调试（记得在VisualStudio的工程属性，调试那一栏里选择上“允许非托管代码调试”），然后在立即窗口里输入：

.load sos.dll
extension C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll loaded
!dso
PDB symbol for mscorwks.dll not loaded
OS Thread Id: 0xfd8 (4056)
ESP/REG  Object   Name
0012f16c 01312db8 Foo
0012f220 01312db8 Foo
0012f224 01312db8 Foo
0012f440 01312db8 Foo
0012f444 01312db8 Foo

!do 01312db8
Name: Foo
MethodTable: 00993090
EEClass: 00991358
Size: 12(0xc) bytes
 (E:\Study\ConsoleApplication9\ConsoleApplication9\bin\Debug\ConsoleApplication9.exe)
Fields:
None

!dumpmt -md 00993090
EEClass: 00991358
Module: 00992c5c
Name: Foo
mdToken: 02000003  (E:\Study\ConsoleApplication9\ConsoleApplication9\bin\Debug\ConsoleApplication9.exe)
BaseSize: 0xc
ComponentSize: 0x0
Number of IFaces in IFaceMap: 0
Slots in VTable: 6
--------------------------------------
MethodDesc Table
   Entry MethodDesc      JIT Name
79286a70   79104934   PreJIT System.Object.ToString()
79286a90   7910493c   PreJIT System.Object.Equals(System.Object)
79286b00   7910496c   PreJIT System.Object.GetHashCode()
0099c038   00993078     NONE Foo.Finalize()
0099c040   00993084      JIT Foo..ctor()
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派生呢？

using System;
using System.Runtime.ConstrainedExecution;

public class Program
{
    static void Main()
    {
        Foo f = new Foo();
        f.Test();

        Console.ReadLine();
    }
}

public class Foo : CriticalFinalizerObject
{
    public void Test()
    {

    }

    ~Foo()
    {

    }
}

代码几乎一模一样，真的有什么不同么：

前面一部分就不再列了

!dumpmt -md 00993090
EEClass: 00991360
Module: 00992c5c
Name: Foo
mdToken: 02000003  (E:\Study\ConsoleApplication9\ConsoleApplication9\bin\Debug\ConsoleApplication9.exe)
BaseSize: 0xc
ComponentSize: 0x0
Number of IFaces in IFaceMap: 0
Slots in VTable: 6
--------------------------------------
MethodDesc Table
   Entry MethodDesc      JIT Name
79286a70   79104934   PreJIT System.Object.ToString()
79286a90   7910493c   PreJIT System.Object.Equals(System.Object)
79286b00   7910496c   PreJIT System.Object.GetHashCode()
0099c038   00993078      JIT Foo.Finalize()
0099c040   00993084      JIT Foo..ctor()
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#》

MSDN

注

本来想把前面列出的四个类型都写一下，最后发现第一个类型就写的比较多，最后就决定将作为多篇叙说。而且，就我目前知道的只有这四个类型，如果谁还知道其他的类型或我日后了解到更多内容，我会一并总结如此。

声明：该文章虽为我所写，但主要是总结，大部分资料“抄袭”自上面两个参考资料，然后我再加工处理，添加些代码和Debug示例。算是半原创吧。特此声明。

祝编程愉快