总体了解C#（24. 受控执行环境）

24. 受控执行环境

对[C#/IL码/CLR]和[Java/字节码/JVM]进行比较是不可避免的也是正当的。我想，最好的办法是首先搞清楚为什么会创造出这些技术来。

用C和C++写程序，一般是把源代码编译成汇编语言代码，它只能运行在特定的处理器和特定的操作系统上。编译器需要知道目标处理器，因为不同的处理器指令集不同。编译器也要知道目标操作系统，因为不同的操作系统对诸如如何执行工作以及怎样实现象内存分配这些基本的C/C++的概念不同。C/C++这种模型获得了巨大的成功（你所使用的大多数软件可能都是这样编译的），但也有其局限性：

l 程序无丰富的接口以和其它程序进行交互（微软的COM就是为了克服这个限制而创建的）

l 程序不能以跨平台的形式分发

l 不能把程序限制执行在一个安全操作的沙箱里

为了解决这些问题，Java采用了Smalltalk采用过的方式，即编译成字节码，运行在虚拟机里。在被编译前，字节码维持程序的基本结构。这就使得Java程序和其它程序进行各种交互成为可能。字节码也是机器中立的，这也意味着同样的class文件可以运行于不同的平台。最后，Java语言没有显式的内存操作（通过指针）的事实使得它很适合于编写“沙箱程序”。

最初的虚拟机利用解释器来把字节码指令流转换为机器码。但是这个过程慢得可怕以致于对于那些关注性能的程序员来说，从来都没有吸引力。如今，绝大多数JVM都利用JIT编译器，基本编译成机器码—在进入类框架的范围之前和方法体执行之前。在它运行前，还有可能将Java程序转换为汇编语言，可以避免启动时间和即时编译的内存负担。和编译Visual C++程序相比，这个过程并不需要移去程序对运行时的依赖。Java运行时（这个术语隐藏在术语Java虚拟机下之下）将处理程序执行的很多至关重要的方面，比如垃圾收集和安全管理。运行时也被认为是受控执行环境。

尽管术语有点含糊不清，尽管从不用解释器，但.NET基本模型也是使用如上所述方式。.NET的重要的改进将来自于IL自身的设计的改进。Java可以匹敌的唯一方式是修改字节码规范以达到严格的兼容。我不想讨论这些改进的细节，这应该留给那些极个别的既了解字节码也了解IL码的开发人员去讨论。99%的象我这样的开发人员不打算去研究IL代码规范，这儿列出了一些意欲改进字节码的IL设计决策：

l 提供更好的类型中立（有助于实现模板）；

l 提供更好的语言中立；

l 执行前永远都编译成汇编语言，从不解释；

l 能够向类、方法等加入附加的声明性信息。参见15.特性；

目前，CLR还提供多操作系统支持，而且在其它领域还提供了对JVM的更好的互用性的支持。参见26.互用性。