C#基础--应用程序域(Appdomain)
AppDomain理解
为了保证代码的键壮性CLR希望不同服务功能的代码之间相互隔离，这种隔离可以通过创建多个进程来实现，但操作系统中创建进程是即耗时又耗费资源的一件事，所以在CLR中引入了AppDomain的概念，AppDomain主要是用来实现同一进程中的各AppDomain之间的隔离，AppDomain可以用以下特征来描述它的全貌：
-
AppDomain概念并不存在于操作系统，而只存在于.net中并且AppDomain不可脱离进程单独存在，它是属于某一CLR或寄宿着CLR的进程的。
-
一个进程中可以有多个AppDomain,并且每个之间相互隔离（只保证安全代码的隔离，不安全代码并不能保证）,此可以理解为AppDomain是.net程序中的"进程"，在一个AppDomain中创建的对象只属于本AppDomain，多个AppDomain之间的对象不能相互访问，除非遵循CLR的一些规则。
-
.net程序启动时在进程中创建一个默认的AppDomain，入口代码将运行于此AppDomain，默认应用程序域只有在进程终止时才会被销毁，如果主动的调用Unload去卸载默认应用程序域，会抛出一个CannotUnloadAppDomainException。
-
每个AppDomain都单独的加载程序集，这意味着在A应用程序域中加载了的程序集，并不一定在B应用程序域中也被加载了。每个APPDomain有单独的Loader堆，互相不影响，每个Loader堆都记录了自AppDomain建立以后所访问过的类型，Loader堆中的每个类型对象都有一个方法表，这些方法表指向已经被JIT编译过的本地代码（前提是这些方法是已经被至少执行过一次的）。因为AppDomain是相互隔离的所以相同的一个类型中的方法，在A应用程序域中是被JIT编译过的，但不一定在B应用程序域中也是被JIT编辑过的，方法是否被JIT编辑过取决于些方法是否在本AppDomain被调用过。
-
当AppDomain被卸载时，此AppDomain中的程序集会被卸载，因为每个APPDomain加载的程序集都是独立的所以一个应用程序域被卸载并不会影响其它AppDomain中加载的程序集,另外本AppDomain的loader堆也会被回收，每个程序域的loader堆是独立的所以也不会影响到其它程序域的Loader堆，因为loader堆是独立的（静态字段是存在于类型对象上的），所以一个类型中的静态字段在不同应用程序域中也是不同的存在，所以静态字段也是不被影响的，唯一受影响的是线程，因为线程可以跨越应用程序域访问不同的应用程序域上的代码，后面我们会介绍当卸载一个应用程序域时如果对线程做处理。
-
有一种程序集可以被多个AppDomain使用，这种程序集叫做"AppDomain中立"的程序集，比如MSCorLib.dll，该程序集包含了System.Object,System.Int32以及其它的与.net framework密不可分的类型，这个程序集在CLR初始化时会自动加载，JIT会为这些程序集创建一个特殊的Loader堆，并且程序集中的方法被编译成的本地代码可被所有AppDomain共享，这种程序集不可被卸载只有当进程结束时这种程序集才会被卸载。
AppDomain的创建与销毁
-
System.Threading.Thread .GetDomain()得到当前线程所在的应用程序域，或通过AppDomainr的一个静态只读属性：AppDomain.CurrentDomain
-
创建AppDomain使用AppDomain的静态方法CreateDomain这个方法有多个重载版本，最简单的AppDomain.CreateDomain("domain 1");参数传入的是AppDomain的友好名称，调用这个版本的方法，新建的AppDomain会使用当前AppDomain的权限集和配置设置。其它版本可自动查阅文档。
另一AppDomain中加载另执行程序
可以通过AppDomain的实例方法ExecuteAssemblyByName在某一应用程序域中执行可执行程序集，只需传入可执行程序集的名称即可(注意是可执行程序集的名称，而并非文件)
AppDomain之间的对象访问
AppDomain之间的对象传送有两种方式，以下分别介绍：
- 按引用封送方式
如果一种类型继承自MarshalByRefObject就标志着此类型所实例化出来的对象可以按引用封送传递到另一应用程序域中，所谓引用封送就是将对象传递到另一AppDomain后对对象所做的修改照实的反应到原对象身上，而不是创建副本对副本进行修改。这里面有个意外就是静态字段，静态字段的数据总是保存在当前应用程序域的Loader堆中，对静态字段的访问没有办法创建代理，所以就意味着按引用封送的类型的静态字段并没有引用原对象的静态字段，对目标类型的静态字段所做的修改也不会反映到原对象中。
先来看一段代码：
1 public class Person:MarshalByRefObject
2 {
3
4 public void SomeMethod()
5 {
6 Console.WriteLine("current domain is:"+AppDomain.CurrentDomain.FriendlyName);
7 }
8
9 public string Name
10 {
11 get;
12 set;
13 }
14
15 public int Age
16 {
17 get;
18 set;
19 }
20
21 public override string ToString()
22 {
23 return this.Name + ":" + this.Age.ToString();
24 }
25
26 }
27
28
29
30
31
32 class Program
33 {
34
35 static void Main(string[] args)
36 {
37 AppDomain exampleAppDomain = AppDomain.CreateDomain("new appdomain");
38 Person xylee=(Person)exampleAppDomain.CreateInstanceAndUnwrap("AOPTest", "AOPTest.Person");
39
40 Console.WriteLine("Type:{0}", xylee.GetType().ToString());
41 Console.WriteLine("Is proxy:{0}", System.Runtime.Remoting.RemotingServices.IsTransparentProxy(xylee));
42 xylee.SomeMethod();
43 AppDomain.Unload(exampleAppDomain);
44
45 try
46 {
47 xylee.SomeMethod();
48 Console.WriteLine("call is successed");
49 }
50 catch (AppDomainUnloadedException)
51 {
52 Console.WriteLine("throw AppDomainUnloadException");
53 }
54
55
56 Console.ReadKey();
57 }
58 }
以上代码运行后输出的信息为：
Type:AOPTest.Person
Is proxy:True
current domain is:new appdomain
throw AppDomainUnloadException
首先代码新建了个应用程序域，并给他赋予了一个友好名称“new appdomain",此时新创建的AppDomain的Loader堆是空的，此时线程还处于默认的AppDomain中，接着调用AppDomain的实例方法CreateInstanceAndUnwarp在创建的AppDomain中加载程序集并实例了一个AOPTest.Person类型的对象，执行CreateInstanceAndUnwarp时线程会跨越应用程序域来到new appdomain域中，创建好对象后把对象传递到默认AppDomain中，这里因为一个应用程序域的对象不能被另一个应用程序域的变量(根)所引用，因为应用程序域的主要作用就是隔离不同的应用程序域，当CreateInstanceAndUnwarp要将一个AppDomain中的对象传递到另一个AppDomain时发现对象的类型是继承自MarshalByRefObject类型时就会知道此对象要按引用封送，CLR会在目标AppDomain中创建代理类型并实例化，代理类型所公开的成员看起来跟源AppDomain中要传递的对象的类型看起来是一样的，但其成员的实现只是调用源AppDomain中相应的实现，在示例中我们用xylee.GetType()得到的信息跟原类型看起来是一样的就是这个道理，我们可以用System.Runtime.Remoting.RemotingServices.IsTransparentProxy(xylee)来判断一个对象是否是代理类型所创建的对象。
接下来示例中卸载了新建的AppDomain，新建的AppDomain中的程序集和Loader堆都会被销毁，这时由于代理对象所引用的原AppDomain已经不存在了，那么再调用代理对象中的任何成员都会抛出一个错误，即下一句的：AppDomainUnloadedException。
由于按引用封送对象，需要在目标应用程序域创建代理，对对象的所有成员的访问都通过代理转换的缘故，所以执行效率就不会太高，实际上继承自MarshalByRefObject的类型不但跨应用程序域访问效率不高，即使在本应用程序域实例化的对象对字段的访问效率也比较低，下面就是测试：
1 public class Demo1:Object
2 {
3 public Int32 Age;
4 }
5
6 public class Demo2 : MarshalByRefObject
7 {
8 public Int32 Age;
9 }
10
11 class Program
12 {
13
14 static void Main(string[] args)
15 {
16 const Int32 count=10000000;
17 Demo1 d1 = new Demo1();
18 Demo2 d2 = new Demo2();
19 Stopwatch watch = new Stopwatch();
20 watch.Start();
21
22 for (int i = 0; i < count; i++)
23 {
24 d1.Age += 1;
25 }
26
27 Console.WriteLine(watch.ElapsedMilliseconds);
28
29 watch.Restart();
30 for (int i = 0; i < count; i++)
31 {
32 d2.Age += 1;
33 }
34 Console.WriteLine(watch.ElapsedMilliseconds);
35 watch.Stop();
36 Console.ReadKey();
37 }
38 }
以下是运行结果：
48
720
在本例中由于源应用程序域所创建的对象并没有其应用程序域的根引用它，那它是否会被垃圾回收机制回收了呢？答案是如果一个对象被跨应用程序域按引用封送到另一个应用程序域后，那么它在源应用程序域在没有根引用的情况下会保留5分钟内不会被垃圾回收，在此时间内如果此对象被其它应用程序域的代理访问那么CLR会自动续约2分钟，当然两分钟这个时间是可以改的，你只需要重写继承自MarshalByRefObject类的虚函数public virtual object InitializeLifetimeService();即可定制这个时间。
- 按值封送方式
把一个类标识上可以序列化，即为类型添加SerializableAttribute即标志着类型实便化出来的对象可以按值封送传递到另一应用程序域中，其内部原理就是在原AppDomain中把类序列化成字节流，传递到另一AppDomain中，在目标AppDomain中再实例化出一个原对象的副本然后用传递过来的字节流对副本进行填充，这样目标对象看起来跟原对象是一样的，但其实只是原对象的一个副本，对副本所做的任何修改并不反应到原对象上。
示例：
1 [Serializable]
2 public class Person
3 {
4
5 public void SomeMethod()
6 {
7 Console.WriteLine("current domain is:"+AppDomain.CurrentDomain.FriendlyName);
8 }
9
10 public string Name
11 {
12 get;
13 set;
14 }
15
16 public int Age
17 {
18 get;
19 set;
20 }
21
22 public override string ToString()
23 {
24 return this.Name + ":" + this.Age.ToString();
25 }
26
27 }
28
29
30
31
32
33 class Program
34 {
35
36 static void Main(string[] args)
37 {
38 AppDomain exampleAppDomain = AppDomain.CreateDomain("new appdomain");
39 Person xylee=(Person)exampleAppDomain.CreateInstanceAndUnwrap("AOPTest", "AOPTest.Person");
40
41 Console.WriteLine("Type:{0}", xylee.GetType().ToString());
42 Console.WriteLine("Is proxy:{0}", System.Runtime.Remoting.RemotingServices.IsTransparentProxy(xylee));
43 xylee.SomeMethod();
44 AppDomain.Unload(exampleAppDomain);
45
46 try
47 {
48 xylee.SomeMethod();
49 Console.WriteLine("call is successed");
50 }
51 catch (AppDomainUnloadedException)
52 {
53 Console.WriteLine("throw AppDomainUnloadException");
54 }
55
56
57 Console.ReadKey();
58 }
59 }
输出：
Type:AOPTest.Person
Is proxy:False
current domain is:AOPTest.vshost.exe
current domain is:AOPTest.vshost.exe
call is successed
当调用CreateInstanceAndUnwarp后目标应用程序域加载了程序集并创建了对象之后，如果发现类型没有继承自MarshalByRefObject,而是标识了可序列化后，将会按值封送传递对象，首先将要封送的对象序列化为字节流，传递回目标应用程序域，然后在目标应用程序域中加载定义此对象类型所在的程序集，并实例化一个类型的实例，再用传递回来的字节流反序列化填充此实例。此时的实例是一个新的对象，跟源程序的对象并没有关系，调用其成员也会在目标应用程序域内的对象上完成，并不会跨域，源应用程序域被卸载也不会影响目标应用程序域里的此对象，所以上例中的AppDomainUnloadException异常并不会触发。
- 关于System.Runtime.Remoting.ObjectHandle
在上面两个例子中跨AppDomain访问对象的方法CreateInstanceAndUnwrap都自动的将传递过来的对象具体化了，方法名中的Unwrap也表达了这一点，在对象具体化时会在具体化所在的AppDomain中加载要具体化对象类型所在的程序集，然后如果对象是按引用封送的那会在当前AppDomain中创建代理类型各实例化，如果对象是按值封送的，那对象的副本会反序列化。
你也可以调用创建实例的非自动具体化版本的方法，即CreateInstance，这个方法返回的是System.Runtime.Remoting.ObjectHandle,这个类型继承自MarshalByRefObject,所以可以穿越AppDomain边界，并且可以使对象不具体化，只有当需要的时候才具体化，调用ObjectHandle的Unwarp实例方法即可。
- 如果对象即不继承自MarshalByRefObject又没有标识上SerializableAttribute，那对象在跨越应用程序域时会发生什么？
答案是通过CreateInstanceAndUnwarp是目标应用程序域的对象会创建但调用并不会成功，会抛出SerializationException，原因就是CreateInstanceAndUnwarp会自动具体化，当具体化时CLR发现类型即没有继承自MarshalByRefObject又没标识上可序列化。如果只需要在目标应用程序域里执行一些操作而又不想传递对象建议使用CreateInstance方法，当然如果你用这个方法返回的ObjectHandle实例试图Unwarp时也会报错。
AppDomain的销毁
卸载AppDomain使用AppDomain的静态方法AppDomain.Unload就可以了，传入要卸载的应用程序域对象。
销毁AppDomain时CLR会有以下几个动作。
- 挂起所有托管代码中的线程。
- 查找所有线程的线程栈，看有那些线程正在执行要卸载应用程序域中，或栈处于要卸载应用程序域中，并给这些线程抛出一个ThreadAbortException,并恢复这个线程的执行，将这个异常展开，在展开过程中遇到的所有Finally块，执行资源清理，如果没有代码捕获这个ThreadAbortException，CLR会吞噬这个异常，线程会终止，但进程可继续运行，这一点非常特别，因为对于其他所有未处理的异常CLR都会结束进程。
- 当所有线程都离开要卸载应用程序域后，CLR遍历所有域的堆，将所有对所有引用卸载应用程序域里对象的代理对象设置一个标识(flag),这样当这些代理对象再访问已卸载程序域里的对象时会抛出AppDomainUnloadedException.
- 垃圾回收器会回收所有要卸载应用程序域里的对象，期间对象的Finalize会被调用以保证资源清理干源。
- CLR恢复所有线程的执行，AppDomain.Unload的设用返回并继续执行接下来的代码，AppDomain.Unload的调用是同步的，当然调用也是有限时的，如果对AppDomain.Unload的调用在10秒内没有返回，CLR会抛出一个CannotUnloadAppDomainException的异常，并且应用程序域有可能被卸载也有可能未被卸载。
如果调用AppDomain.Unload的线程正好在被卸载的AppDomain中，那么CLR会新建一个线程序继续卸载，原线程会抛出一个ThreadAbortException并展开(unwind),新建的线程等待AppDomain的卸载，卸载成功后自动退出，如果卸载失败那么新线程处理CannotUnloadAppDomainException，因为我们并没有为新线程写这方面的代码，所以新线程无法捕获这个异常。
以下代码验证第二条：
示例代码输出：Has ThreadAbortException
对象创建后两个线程先后在新建的应用程序域里运行，_unload线程卸载当前应用程序域，此时_test线程还在Thread.Sleep中，收到ThreadAbortException后到达catch块打钱出信息。
如果一个线程当前正在finally块中，catch块中，类构造器，临界执行区域或非托管代码中，CLR不会立即终止该线程，只有在代码跳出这些块时CLR才会向此线程抛出ThreadAbortException.
AppDomain的异常通知
- AppDomain.CurrentDomain.UnhandledException
捕获应用程序域中未处理的异常，只是收到异常的通知并不能处理异常也不能吞噬掉异常最终异常还是会抛出，你可以在些事件处理函数中写日志或打印详细信息
- AppDomain.CurrentDomain.FirstChanceException
异常首次抛出时的通知，只是接收到异常通知并不能吞噬掉异常，当异常首次抛出时，CLR会调用在此登记过的回调方法然后CLR会在当前AppDomain栈上查找能处理掉这次异常的catch块如果catch可以处理掉这个异常那么继续执行，如果当前AppDomain中没有一个catch块可以处理那么CLR会沿着栈向上查找来到调用AppDomain,这时调用AppDomain会接到一个新的异常(序列化原来的异常并在本AppDomain中反序化)，CLR此时会调用订阅了当前AppDomain FirstChanceException 的回调方法，然后异常查找过程依旧，直至栈顶如果没有catch块可以处理此异常那CLR将终止进程。
需要注意的是以上两种异常回调均可以在另一个应用程序域中被订阅，UnhandleException指的是CLR通过搜索线程栈里的catch块一直搜索到栈顶还未搜索到的一种事件，如果此时线程栈在另一个AppDomain中则算为另一个AppDomain的UnhandleException,也就是说线程栈的栈顶在哪个AppDomain中，就算做哪个AppDomain的UnhandleExcetpion.
任何一个线程中的异常不管激发那个AppDomain中的UnhandleException之后都将结束线程，当然也有例外，其它章节我们会介绍。
AppDomain与线程的迷惑与理解
AppDomain是个静态的概念，线程是个动态的概念，一个线程可能运行于一个AppDomain中也可跨越多个AppDomain运行，CLR中的线程(System.Threading.Thread)其实是个Soft Thread，操作系统中的线程是Hard Thread并且操作系统只可识别Hard Thread,Soft Thread是CLR对Hard Thread的封装（在MSDN中的描述Hard Thread与Soft Thread没有一对一的对应关系，但就目前CLR的实现来说Hard Thread和Soft Thread是一对一的关系），Soft Thread只属于某个AppDomain,穿越AppDomain的是Hard Thread,当Hard Thread访问一个AppDomain时其会为之产生一个Soft Thread，Hard Thread中有个叫TLS的结构，这个区域被CLR用来存储Hard Thread当前执行代码的AppDomain引用以及Soft Thread的引用，当Hard Thread穿越到另一个AppDomain时，TLS中的这些引用也会随之改变。
