java和.NET的比较
前面wuxq贴的文章比较详细的分析了C#和
Java在语法上的异同，(后面几章是分析C#的特征的)
下面再看看他们的编译实现,还有一些相关技术背景。
c#和java的确很相像，但是他们之间最大的不同是java采用解释执行，
而c#采用编译。但是c#的编译和c的编译又完全不同，他是一种jit编译
ava也有，但是他们工作方式又有不同。
语言编译器(如CSC)将.cs文件编译成扩展了PE格式的文件中(eg:exe or .dll)
PE文件中= IL伪代码(p代码,Microsoft Intermediate Language, MSIL)+
元数据（Metadata）.
* [
元数据是类型库、注册表内容和其它用于COM的信息,反正就是
一些各种类型的定义、各种类型成员的签名以及其它数据
]
* [ IL代码是CPU无关的，这也意味着. 你要用目标机器上的一个
编译器才能把IL代码转换成原始代码。
MSIL将负责算术和逻辑操作符,控制流,直接内存访问,堆栈操作
参数和局部变量,堆栈分配,对象模式,实例类型值,临界区,数组...
IL代码自身变成了NGWS runtime的受管执行进程的入口
]
NGWS runtime 即时编译器(JITters)根据一有的PE文件生成我们所要的native code.
MSIL和JITER让我们联想起了Java的byte code, jvm和jit。
他们是如此的相像，但实际上有天壤之别：
1。
MSIL可以理解为.net上的汇编语言。这是因MSIL 不是一种
可执行码仍然是一种某种形式的语言不过是编译的时候加上了
metadata包装成了二进制流的格式，我们可以通过ms的ildasm
反编译器查看到这种类似于汇编语言的中间码。而java的
bytecode，从某种意义下它已经是一种可执行码了（不过不是cpu执行而是jvm执行）.
2。C# 的JITER和 java的 jvm jit工作方式不同。
.net的运行库和java的代码库的不同。在java中所有的系统库都以
bytecode形式存放，然后由jvm解释程序中所有的需要用到的库代码
然后调用本地系统的接口完成相应的操作。
而.net的通用运行库(CLR)是100%本地代码。.net系统是一个
充满了CLR的dll的大容器。当jit载入MISL时，MISL并不指
挥.net系统去调用本地的系统接口。而是指定.net系统去编译连接
那些需要的clr的dll。编译出来的是100%native code。从技术上
说，全部的处理过程如下：当一个类型被装载时，装载器创建一个存
根(stub)，并使它连接每一个类型的方法。当一个方法第一次被调用
时，存根把控制交给JIT。JIT把IL编译为原始代码，且把存根指针
指向缓冲了的原始代码。接着的调用将执行原始码。在某些位置上，
所有的IL都被转换成为原始代码，而JITter处于空闲状态。可以看出
中间有一个代码缓冲器。
总结：
可以说c#是结合了c/c++编译和java的中间代码的自的优点，
又屏蔽了各自的缺点：:c/c++不独立平台，java的低效率
Java自己也有JIT，但是它的jit是不彻底的，仍然不是100%的
native code,仍然需要jvm的解释执行。因此java的性能一直没有办法
提高。
C#的方法是编译但是又不同于c的编译，他将编译分为几个阶段来进行。
汇编代码的编译肯定比源代码来的快，jit的局部代码编译肯定比全部程
序编译来的快，因此使用c#编程性能上的损失比java少的多，当然和c
比起来还是有一点延迟特别是代码启动的时候，但是比java好得多了。