MyClass2 Constructor Parameters : Hello

C#支持变量的声明初始化。类内的成员变量声明初始化被编译器转换成赋值语句强加在类的每一个构造器的内部。那么初始化语句与调用父类构造器的语句的顺序是什么呢？看下面例子的输出：

using System;
public class MyClass1
{
	public MyClass1() 
	{
		Print();
	}
	public virtual void Print() {}
}
public class MyClass2: MyClass1
{
	int x = 1;
	int y;
	public MyClass2() 
	{
		y = -1;
		Print();
	}
	public override void Print() 
	{
		Console.WriteLine("x = {0}, y = {1}", x, y);
	}
}
public class Test
{
	static void Main() 
	{
		MyClass2 MyObject1 = new MyClass2();
	}
}

编译程序并运行可以得到下面的输出：

x = 1, y = 0
x = 1, y = -1

容易看到初始化语句在父类构造器调用之前，最后执行的才是本构造器内的语句。也就是说变量初始化的优先权是最高的。

我们看到类的构造器的声明中有public修饰符，那么当然也可以有protected/private/ internal修饰符。根据修饰符规则，我们如果将一个类的构造器修饰为private，那么我们在继承该类的时候，我们将不能对这个private的构造器进行调用，我们是否就不能对它进行继承了吗？正是这样。实际上这样的类在我们的类内的成员变量都是静态（static）时，而又不想让类的用户对它进行实例化，这时必须屏蔽编译器为我们暗中添加的构造器（编译器添加的构造器都为public），就很有必要作一个private的实例构造器了。protected/internal也有类似的用法。

类的构造器没有返回值,这一点是不言自明的。

静态构造器初始化类中的静态变量。静态构造器不象实例构造器那样在继承中被隐含调用，也不可以被用户直接调用。掌握静态构造器的要点是掌握它的执行时间。静态构造器的执行并不确定（编译器没有明确定义）。但有四个准则需要掌握：

1. 在一个程序的执行过程中，静态构造器最多只执行一次。
2. 静态构造器在类的静态成员初始化之后执行。或者讲编译器会将静态成员初始化语句转换成赋值语句放在静态构造器执行的最开始。
3. 静态构造器在任何类的静态成员被引用之前执行。
4. 静态构造器在任何类的实例变量被分配之前执行。

看下面例子的输出：

using System;

class MyClass1
{
	static MyClass1() 
	{
		Console.WriteLine("MyClass1 Static Contructor");
	}
	public static void Method1() 
	{
		Console.WriteLine("MyClass1.Method1");
	}
}
class MyClass2
{
	static MyClass2() 
	{
		Console.WriteLine("MyClass2 Static Contructor");
	}
	public static void Method1() 
	{
		Console.WriteLine("MyClass2.Method1");
	}
}
class Test
{
	static void Main() 
	{
		MyClass1.Method1();
		MyClass2.Method1();
	}
}

编译程序并运行可以得到下面的输出：

MyClass1 Static Contructor
MyClass1.Method1
MyClass2 Static Contructor
MyClass2.Method1

当然也可能输出：

MyClass1 Static Contructor
MyClass2 Static Contructor
MyClass1.Method1
MyClass2.Method1

值得指出的是实例构造器内可以引用实例变量，也可引用静态变量。而静态构造器内 能引用静态变量。这在类与对象的语义下是很容易理解的。
实际上如果我们能够深刻地把握类的构造器的唯一目的就是保证类内的成员变量能够得到正确的初始化，我们对各种C#中形形色色的构造器便有会心的理解--它没有理由不这样！

析构器

由于.NET平台的自动垃圾收集机制，C#语言中类的析构器不再如传统C++那么必要，析构器不再承担对象成员的内存释放--自动垃圾收集机制保证内存的回收。实际上C#中已根本没有delete操作！析构器只负责回收处理那些非系统的资源，比较典型的如：打开的文件，获取的窗口句柄，数据库连接，网络连接等等需要用户自己动手释放的非内存资源。我们看下面例子的输出：

using System;
class MyClass1
{
	~MyClass1() 
	{
		Console.WriteLine("MyClass1's destructor");
	}
}
class MyClass2: MyClass1
{
	~MyClass2() 
	{
		Console.WriteLine("MyClass2's destructor");
	}
}
public class Test
{
	public static void Main() 
	{
		MyClass2 MyObject = new MyClass2();
		MyObject = null;
		GC.Collect();
		GC.WaitForPendingFinalizers();
	}
}

编译程序并运行可以得到下面的输出：

MyClass2's destructor
MyClass1's destructor

其中程序中最后两句是保证类的析构器得到调用。GC.Collect()是强迫通用语言运行时进行启动垃圾收集线程进行回收工作。而GC.WaitForPendingFinalizers()是挂起目前的线程等待整个终止化（Finalizaion）操作的完成。终止化（Finalizaion）操作保证类的析构器被执行，这在下面会详细说明。

析构器不会被继承，也就是说类内必须明确的声明析构器，该类才存在析构器。用户实现析构器时，编译器自动添加调用父类的析构器，这在下面的Finalize方法中会详细说明。析构器由于垃圾收集机制会被在合适的的时候自动调用，用户不能自己调用析构器。只有实例析构器，而没有静态析构器。

那么析构器是怎么被自动调用的？这在 .Net垃圾回收机制由一种称作终止化（Finalizaion）的操作来支持。.Net系统缺省的终止化操作不做任何操作，如果用户需要释放非受管资源，用户只要在析构器内实现这样的操作即可--这也是C#推荐的做法。我们看下面这段代码：

using System;
class MyClass1
{
	~MyClass1()
	{
		Console.WritleLine("MyClass1 Destructor");
	}
}

而实际上，从生成的中间代码来看我们可以发现，这些代码被转化成了下面的代码：

using System;
class MyClass1
{
	protected override void Finalize()
	{
		try
		{
Console.WritleLine("My Class1 Destructor");				
		}
		finally
		{
			base.Finalize();
		}
	}
}

实际上C#编译器不允许用户自己重载或调用Finalize方法--编译器彻底屏蔽了父类的Finalize方法（由于C#的单根继承性质，System.Object类是所有类的祖先类，自然每个类都有Finalize方法），好像这样的方法根本不存在似的。我们看下面的代码实际上是错的：

using System;
class MyClass
{
	override protected void Finalize() {}// 错误
	public void MyMethod() 
	{
		this.Finalize();// 错误
	}
}

但下面的代码却是正确的：

using System;
class MyClass
{
	public void Finalize()
	{
		Console.WriteLine("My Class Destructor");
	}

}
public class Test
{
	public static void Main() 
	{
		MyClass MyObject=new MyClass();

		MyObject.Finalize();
	}
}

实际上这里的Finalize方法已经彻底脱离了“终止化操作”的语义，而成为C#语言的一个一般方法了。值得注意的是这也屏蔽了父类System.Object的Finalize方法，所以要格外小心！

终止化操作在.Net运行时里有很多限制，往往不被推荐实现。当对一个对象实现了终止器（Finalizer）后，运行时便会将这个对象的引用加入一个称作终止化对象引用集的队列，作为要求终止化的标志。当垃圾收集开始时，若一个对象不再被引用但它被加入了终止化对象引用集的队列，那么运行时并不立即对此对象进行垃圾收集工作，而是将此对象标志为要求终止化操作对象。待垃圾收集完成后，终止化线程便会被运行时唤醒执行终止化操作。显然这之后要从终止化对象引用集的链表中将之删去。而只有到下一次的垃圾收集时，这个对象才开始真正的垃圾收集，该对象的内存资源才被真正回收。容易看出来，终止化操作使垃圾收集进行了两次，这会给系统带来不小的额外开销。终止化是通过启用线程机制来实现的，这有一个线程安全的问题。.Net运行时不能保证终止化执行的顺序，也就是说如果对象A有一个指向对象B的引用，两个对象都有终止化操作，但对象A在终止化操作时并不一定有有效的对象A引用。.Net运行时不允许用户在程序运行中直接调用Finalize()方法。如果用户迫切需要这样的操作，可以实现IDisposable接口来提供公共的Dispose()方法。需要说明的是提供了Dispose()方法后，依然需要提供Finalize方法的操作，即实现假托的析构函数。因为Dispose()方法并不能保证被调用。所以.Net运行时不推荐对对象进行终止化操作即提供析构函数，只是在有非受管资源如数据库的连接，文件的打开等需要严格释放时，才需要这样做。

大多数时候，垃圾收集应该交由.Net运行时来控制，但有些时候，可能需要人为地控制一下垃圾回收操作。例如在操作了一次大规模的对象集合后，我们确信不再在这些对象上进行任何的操作了，那我们可以强制垃圾回收立即执行，这通过调用System.GC.Collect() 方法即可实现，但频繁的收集会显著地降低系统的性能。还有一种情况，已经将一个对象放到了终止化对象引用集的链上了，但如果我们在程序中某些地方已经做了终止化的操作，即明确调用了Dispose()方法，在那之后便可以通过调用System.GC.SupressFinalize()来将对象的引用从终止化对象引用集链上摘掉，以忽略终止化操作。终止化操作的系统负担是很重的。

在深入了解了.NET运行时的自动垃圾收集功能后，我们便会领会C#中的析构器为什么绕了这么大的弯来实现我们的编程需求，才能把内存资源和非内存资源的回收做的游刃有余--这也正是析构的本原！