NET第3章托管执行环境.pptVIP

程序集的分类 程序集被加载时，CLR会自动检查以强名称命名的程序集的版本号。对于无强名称的程序集，版本控制是创建和使用这些程序集的开发人员的责任。由于程序集拥有版本号，在同一时间内，同一台计算机上就有可能安装同一程序集的不同版本。 3.4 执行托管代码 3.4.1 装载程序集 3.4.2 编译MSIL 3.4.3 垃圾回收 3.4.4 应用程序域 3.4 执行托管代码 程序集提供了一种“将模块打包到相应单元以便部署”的方法。然而编写代码的目标并不是为了打包和部署，而是为了运行。运行托管代码包括装载程序集、编译MSIL两个步骤。 装载程序集 要运行一个以 .NET Framework 创建的应用程序，首先必须找到构成这个应用程序的程序集，并将其载入内存。非必要时，程序集不会被载入内存，因此如果应用程序从来不调用某个程序集里的任何方法，那个程序集就不会被装载。 然而在加载某个程序集的任何代码之前，首先必须找到这个程序集，那么查找过程究竟如何呢？ 装载程序集 答案并不简单。事实上CLR用于查找程序集的过程太复杂了，以至于无法完整描述，不过这个过程的概念还是相当直白的。如图3.5所示，首先CLR确定它要找的是哪个程序集的哪个版本。默认情况下，它将从发起调用的地方查找“程序集清单内指定”的程序集精确版本，可通过设置各种配置文件来修改这个默认值，因此着手查找之前CLR首先检查这些配置文件。 装载程序集 图3.5 程序集搜索顺序 装载程序集 一旦精确决定了所需版本，CLR就检查所需的程序集是否已被加载。如果是，搜索过程结束，已装载的版本将被使用；如果所需的程序集尚未被装载，CLR将搜索多个地方以找到它。CLR搜索的第一个地方通常是全局程序集缓存（Global Assembly Cache，GAC），这是一个特殊的磁盘目录，用于容纳“被不止一个应用程序所使用”的程序集，把程序集安装于GAC，所需操作只比简单复制程序集略微复杂一些，这个缓存区内只能放置拥有“强名称”的程序集。 装载程序集 如果CLR的搜索目标不在GAC，它将继续搜索工作，检查应用程序的某个配置文件内的codebase元素。如果找到一个codebase元素，CLR便查找该元素所指位置，如果找到了正确的程序集，就意味着搜索过程结束了，而且该程序集将被加载使用；即使codebase元素所指位置上并未包含搜索目标（程序集），搜索过程仍会结束。codebase元素意味着精确指定了“在哪儿可以找到这个程序集”，如果程序集不在那个位置，肯定存在一些问题，CLR也就放弃查找，那么装载程序集的操作也就失败了。 装载程序集 如果没有codebase元素，CLR便开始在被称为application base的地方查找需要的程序集。所谓application base既可以是应用程序安装所在的根目录，也可以是个URL，可能在另外某台计算机上。如果这个难以寻觅的程序集在这里还找不到，CLR会按照程序集的名字、文化背景等线索，在另外几个目录中查找，此处省略不提。 编译MSIL 将MSIL编译成本机代码最常见的方式是让CLR加载程序集，然后在首次调用方法时编译其中对应的方法。由于每个方法是在首次被调用时编译的，因此该过程称为即时（JIT）编译。 编译MSIL 图3.6～图3.8演示了程序集中的代码如何进行JIT编译。这个简单的示例只显示了3个类，分别称为X、Y和Z，每个类都包含若干个方法，每个方法对应一个模块。在图3.6中，只有Y类的方法1已得到编译，3个类的所有其他方法中的所有其他代码仍为MSIL，也就是它们加载时所使用的格式。当Y类的方法1调用Z类的方法1时，CLR会注意到这个新调用的方法不是可执行格式，CLR将调用JIT编译器编译Z类的方法1，并将对该方法的调用重定向到该方法编译后的本机代码，该方法即可执行。 编译MSIL 图3.6 首次调用 Z 类的方法1时 编译MSIL 图3.7中的情况类似，Y类的方法1调用其自己的方法4。如前所述，此方法仍为MSIL，因此将自动调用JIT编译器编译该方法。与前面一样，对该方法的MSIL代码的引用将替换为对新创建的本机代码的引用，然后执行该方法。 图3.8说明了当类Y的方法1再次调用Z类中的方法1时所发生的情况。此方法已经经过JIT编译，因此无需再进行任何其他工作。本机代码已经保存在内存中，因此可直接执行，而不会调用JIT编译器。整个过程将以同样的方式继续，每个方法在首次被调用时进行编译。 编译MSIL 图3.7 调用 Y 类的方法4时 编译MSIL 图 3.8 再次调用 Z 类的方法1时 编译MSIL 图3.7中的情况