Java 是动态编译,跟C++静态编译不同,这就是JIT编译器的原因(Just In Time)

HotSpot会把这些部门动态地编译成机器码,Native code, 并对机器码进行优化,

静态编译器通常很难准确 预知程序运行过程中究竟什么部分最需要优化。静态编译器虽然可以把Java 
全部编译成Native Code,但却做不到动态编译器那样的优化。 

没错,Java是解释语言,但并不意味着它一定被解释执行。早期 
的虚拟机确实一条一条指令解释执行,但人们发现这样效率太低, 
不满足各种要求,因此出现了许多其它虚拟机,如JIT的虚拟机。 
HotSpot也是类似一种虚拟机,自从SUN买下后,已经把它放入 
JRE 1.3以及后续版本中。 
 
采用HotSpot的Java虚拟机,已经很难说Java是被虚拟机解释执行了, 
原因是HotSpot实际上是把Java的bytecode编译成Native code, 
然后运行。 
 
实际上在HotSpot虚拟机中,有两个技术是至关重要的,即动态编译和 
Profiling。HotSpot对bytecode的编译,不是在程序运行前预先编译的, 
而是在程序运行过程中,动态编译(compile during run-time),英文称 
Dynamic compilation。其实Just In Time也就是这个意思。 
 
HotSpot是如何动态编译Javad的bytecode呢?它采用的是一种smart的办法。 
HotSpot里有一个运行监视器,即Profile Monitor(不知国内如何翻译Profile), 
专门监视程序运行中,哪一部分运用频度大, 哪些对性能影响至关重要。 
当然Profile Monitor有一些算法,这些算法未必十全十美,但大体是能较好 
获得相关信息的。对于那些对程序运行效率影响交大的代码,称为热点, 
即hot spot,HotSpot会把这些部门动态地编译成机器码,Native code, 
同时也对机器码进行优化(类似C编译器的一些优化),从而而提高运行效率。 
而那些较少运行的Code,HotSpot虚拟机就不再浪费时间把它们编译。 
 
总体来看,Java bytecode是以解释方式被load到虚拟机的。但虚拟机的 
分析器根据一段运行,获知对程序效率影响最大的部分,然后通过动态 
编译,同时进行优化,编译成机器码,然后为接下来的运行加速。总的 
来说,HotSpot对bytecode有三层处理:不编译,编译,编译并优化。 
至于程序哪部分不编译,哪部分编译,哪部分做何种优化,则由Profile 
Monitor决定。 
 
那么为什么Java采用动态编译器而不是象C++这样采用静态编译器呢? 
虚拟机提供的跨平台运行条件固然是一方面,动态编译器也在许多方面 
比静态编译器优越。Profiling就是一个例子。静态编译器通常很难准确 
预知程序运行过程中究竟什么部分最需要优化。静态编译器虽然可以把Java 
全部编译成Native Code,但却做不到动态编译器那样的优化。 
 
另一个典型的例子,叫做Method inlining。我们知道无论是在C还是在 
Java里,函数调用都是很浪费系统时间的,因为有许多进栈出栈操作。 
因此有一种优化办法,就是把原来的函数调用,通过编译器的编译,改成 
非函数调用,把函数代码直接嵌到调用出,变成顺序执行。 
 
但这一方法在Java/C++这样的面向对象的语言的编译器中,较难很好实现。 
那些静态编译器,通常可以把private,static等函数进行Method inlining, 
但由于这些面向对象的语言支持函数重载,支持动态联编(不知道是不是这样 
翻译,Overridden, dynamic binding),因此静态编译器并不知道究竟应该 
把函数的哪个实现给inline了。 
 
HotSpot的动态编译,由于有对函数调用的监视,因此可以准确地知道一些环境 
下,那些被重载和动态识别的函数可以如何被inline到调用者那里去,因此 
实际上对于一些Server应用来说,可以大幅度提高效率。 
 
HotSpot实际上有两个版本,一个是Server版,一个是Client版。但它们的结构 
和本质都是一样的,只是有些地方优化不一样。 
 
了解了这些,就知道,有时候Java的程序甚至能比C程序运行还快。

什么是HotSpot

05-29 00:10