现在是虚拟机时代了,Java称作JVM(Java 虚拟机),.NET称作 FrameWork(框架)。对照着两个体系,当中有很多异同,不过我感兴趣的是.NET中称作“AppDomain”(应用程序域)的东东。这个概念如何准确的理解,对于.NET开发来讲有何意义?使用它需要注意些什么?
微软的.NET文档中appDomain的解释相当简略(却不是很清楚J): “一个应用程序在其中执行的独立环境”。为执行托管代码提供隔离、卸载和安全边界。到底如何理解呢?我想是不是可以这样来准确体会这个概念:
1、appDomain是.NET框架独有的概念。找不到其他技术体系中贴切的参照概念,是微软自己的东东。很多人认为可以同进程的概念相同,我很不赞同:其一,“进程”是操作系统中的概念,在虚拟机/框架之类的体系中有着自己的定义和功能,显然这样理解appDomain是错误的;其二,“在应用程序域和线程之间没有一对一的关联,多个线程可以属于一个应用程序域,尽管给定的线程并不局限于一个应用程序域,但在任何给定时间,线程都在一个应用程序域中执行。”(.NET FrameWork SDK 中的描述),如果这里的“应用程序域”换成“进程”讲得通么?
2、隔离性。也不怪有人直接套解为进程,AppDomain有着代码执行隔绝的特性,就好像进程做的一样。appDomain的对象、代码可以认为相互隔离,甚至一个appDomain中的代码调用另外appDomain的对象(的数据或者方法等),需要类似DCOM中的“列集/散集”才可以进行(在类继承关系中appDomain类 继承自 MarshalByRefObject类)。每一个appDomain可以单独被调试、启动、停止,有着自己的默认的异常处理,一个appDomain崩溃了,不会影响其他的appDomain。可以理解为.NET的“逻辑进程”。
.NET中允许同一个应用程序的不同版本可以并存,消除了所谓的“dll hell”。通过创建不同的appDomain,我们可以让某个托管的程序集的1.0和2.0的版本同时执行(只要他们自身并不存在某个特定资源的非兼容性的存取访问)
3、安全性。由于代码隔离,可以防止某个危险代码对于其他的appDomain的影响。而且可以通过分配特定的安全分配,确定appDomain中的执行代码对于系统安全保护资源的访问。
4、独立性。每一个appDomain都由.NET的框架分配了专用的存储区(应用域局部存储)。任何对象都可以访问自己当前所在的appDomain的局部存储区,这个局部存储区被整个appDomain中的对象共享,也包括进入appDomain的线程(运行于同一个appDomain的线程可以通过这个局部存储进行通信)。
5、同进程、线程、程序集的关系。同进程属于多对一的关系,即一个进程中可以有多个appDomain,但是appDomain只能存在于某个进程中(显然,正如同上文:进程同appDomain属于不同的概念)。缺省情况下,如果你没有自己创建多个appDomain,一个进程启动后自动创建一个 appDomain。而线程执行可以涉及多个appDomain,但某个特定时刻,线程仅存在于一个appDomain中,且线程可以进入其他的 appDomain。某个程序集的某个实例属于具体的appDomain,由appDomain在自己的范围内加载,并按照程序集创建相应的对象。 AppDomain是程序集的执行环境,同时程序集作为静态实体,可以被多个appDomain加载执行。
很多人文章讲了相关的编程(但没有将清楚什么是appDomain),鄙人也不想抄,基本上涉及appDomain的创建、卸载、获得当前 appDomain实例、操作appDomain、appDomain中创建对象调用对象、加载特定程序集、执行程序、appDomain之间协调(回调、事件等)。可以参考我收集的一些URL:
appDomain参考
http://tech.ccidnet.com/pub/article/c1136_a30763_p1.html
http://www.yesky.com/SoftChannel/7234 ... /20030819/1722679_2.shtml
http://www.microsoft.com/china/msdn/l ... l/html/csharp05162002.asp
http://wwwb.pconline.com.cn/pcedu/empolder/gj/vb/doc/10712_2.htm
http://www.csdn.net/Develop/Read_Article.asp?Id=19285
http://www.WebDN.com/web_file/program/asp.net/06020806153.asp
SDK文档中的参考:
ms-help://MS.VSCC/MS.MSDNVS.2052/cpref/html/frlrfsystemappdomainclasstopic.htm
ms-help://MS.VSCC/MS.MSDNVS.2052/cpref/html/frlrfsystemappdomainmemberstopic.htm
通过前面讨论知道,其实在一般情况下我们是不需要理会appDomain的,不过,出现此概念在.NET中决非多余,有着自己存在的理由,那么具体载那些情境下要使用appDomain呢?
1、 需要隔离的程序集,譬如一些特别容易引起崩溃的代码可以考虑单独运行于一个特定的appDomain
2、 不同安全级别的程序集,如果需要为自己的代码划分安全执行的边界,可以考虑将不同安全级别的代码单独创建于某个设定了不同安全信息的appDomain
3、 从性能上考虑,有些程序集可能会消耗大量资源,尽管在托管环境下,基本上不存在资源消耗漏洞,但是总会存在特定时间访问密集造成消耗大量资源的情况,这时可以考虑创建单独的appDomain,在资源消耗超过临界点后进行appDomain的卸载,适应系统运行要求。Asp.net中利用不同得appDomain来提供支持就是为了防止一个应用程序的崩溃影响其他asp.net应用程序,同时,在不重新启动的系统不重新启动IIS不影响asp.net自身服务提供的情况下将一个appDomain卸掉同时启动新的appDomain,理想情况下可以实现web系统的长时间在线(这以往是昂贵的unix的特性,终于被MS“借鉴”了)。
4、 不同版本的同一应用程序集的同时运行。这个在COM时代是一个大问题,现在通过appDomain,实现了在一个进程中执行版本不同的两个程序集,可以做到良好的兼容性。
5、动态加载一些程序。
微软的.NET文档中appDomain的解释相当简略(却不是很清楚J): “一个应用程序在其中执行的独立环境”。为执行托管代码提供隔离、卸载和安全边界。到底如何理解呢?我想是不是可以这样来准确体会这个概念:
1、appDomain是.NET框架独有的概念。找不到其他技术体系中贴切的参照概念,是微软自己的东东。很多人认为可以同进程的概念相同,我很不赞同:其一,“进程”是操作系统中的概念,在虚拟机/框架之类的体系中有着自己的定义和功能,显然这样理解appDomain是错误的;其二,“在应用程序域和线程之间没有一对一的关联,多个线程可以属于一个应用程序域,尽管给定的线程并不局限于一个应用程序域,但在任何给定时间,线程都在一个应用程序域中执行。”(.NET FrameWork SDK 中的描述),如果这里的“应用程序域”换成“进程”讲得通么?
2、隔离性。也不怪有人直接套解为进程,AppDomain有着代码执行隔绝的特性,就好像进程做的一样。appDomain的对象、代码可以认为相互隔离,甚至一个appDomain中的代码调用另外appDomain的对象(的数据或者方法等),需要类似DCOM中的“列集/散集”才可以进行(在类继承关系中appDomain类 继承自 MarshalByRefObject类)。每一个appDomain可以单独被调试、启动、停止,有着自己的默认的异常处理,一个appDomain崩溃了,不会影响其他的appDomain。可以理解为.NET的“逻辑进程”。
.NET中允许同一个应用程序的不同版本可以并存,消除了所谓的“dll hell”。通过创建不同的appDomain,我们可以让某个托管的程序集的1.0和2.0的版本同时执行(只要他们自身并不存在某个特定资源的非兼容性的存取访问)
3、安全性。由于代码隔离,可以防止某个危险代码对于其他的appDomain的影响。而且可以通过分配特定的安全分配,确定appDomain中的执行代码对于系统安全保护资源的访问。
4、独立性。每一个appDomain都由.NET的框架分配了专用的存储区(应用域局部存储)。任何对象都可以访问自己当前所在的appDomain的局部存储区,这个局部存储区被整个appDomain中的对象共享,也包括进入appDomain的线程(运行于同一个appDomain的线程可以通过这个局部存储进行通信)。
5、同进程、线程、程序集的关系。同进程属于多对一的关系,即一个进程中可以有多个appDomain,但是appDomain只能存在于某个进程中(显然,正如同上文:进程同appDomain属于不同的概念)。缺省情况下,如果你没有自己创建多个appDomain,一个进程启动后自动创建一个 appDomain。而线程执行可以涉及多个appDomain,但某个特定时刻,线程仅存在于一个appDomain中,且线程可以进入其他的 appDomain。某个程序集的某个实例属于具体的appDomain,由appDomain在自己的范围内加载,并按照程序集创建相应的对象。 AppDomain是程序集的执行环境,同时程序集作为静态实体,可以被多个appDomain加载执行。
很多人文章讲了相关的编程(但没有将清楚什么是appDomain),鄙人也不想抄,基本上涉及appDomain的创建、卸载、获得当前 appDomain实例、操作appDomain、appDomain中创建对象调用对象、加载特定程序集、执行程序、appDomain之间协调(回调、事件等)。可以参考我收集的一些URL:
appDomain参考
http://tech.ccidnet.com/pub/article/c1136_a30763_p1.html
http://www.yesky.com/SoftChannel/7234 ... /20030819/1722679_2.shtml
http://www.microsoft.com/china/msdn/l ... l/html/csharp05162002.asp
http://wwwb.pconline.com.cn/pcedu/empolder/gj/vb/doc/10712_2.htm
http://www.csdn.net/Develop/Read_Article.asp?Id=19285
http://www.WebDN.com/web_file/program/asp.net/06020806153.asp
SDK文档中的参考:
ms-help://MS.VSCC/MS.MSDNVS.2052/cpref/html/frlrfsystemappdomainclasstopic.htm
ms-help://MS.VSCC/MS.MSDNVS.2052/cpref/html/frlrfsystemappdomainmemberstopic.htm
通过前面讨论知道,其实在一般情况下我们是不需要理会appDomain的,不过,出现此概念在.NET中决非多余,有着自己存在的理由,那么具体载那些情境下要使用appDomain呢?
1、 需要隔离的程序集,譬如一些特别容易引起崩溃的代码可以考虑单独运行于一个特定的appDomain
2、 不同安全级别的程序集,如果需要为自己的代码划分安全执行的边界,可以考虑将不同安全级别的代码单独创建于某个设定了不同安全信息的appDomain
3、 从性能上考虑,有些程序集可能会消耗大量资源,尽管在托管环境下,基本上不存在资源消耗漏洞,但是总会存在特定时间访问密集造成消耗大量资源的情况,这时可以考虑创建单独的appDomain,在资源消耗超过临界点后进行appDomain的卸载,适应系统运行要求。Asp.net中利用不同得appDomain来提供支持就是为了防止一个应用程序的崩溃影响其他asp.net应用程序,同时,在不重新启动的系统不重新启动IIS不影响asp.net自身服务提供的情况下将一个appDomain卸掉同时启动新的appDomain,理想情况下可以实现web系统的长时间在线(这以往是昂贵的unix的特性,终于被MS“借鉴”了)。
4、 不同版本的同一应用程序集的同时运行。这个在COM时代是一个大问题,现在通过appDomain,实现了在一个进程中执行版本不同的两个程序集,可以做到良好的兼容性。
5、动态加载一些程序。