Java中的JIT机制对运行速度的优化

JIT的起源

在先前的博客，Javac编译过程，简略讲述了Java compiler(javac),可以看出javac和C的compiler不一样， 并不是直接将 Java 的源代码 编译成成处理器的指令。 相反地，它产生的是统一规格、与机器 binary 格式无关的 bytecode。 在执行期，JVM 会逐条解释执行 bytecode， 这是为甚么 Java 在跨平台上会这么成功的主要原因， 你可以在某个平台上写完、build 一份，然后在其他的平台上头执行。

但是这也导致了严重的问题， interpret 通常比直接 compile 成 平台限定的原生 binary 码来得慢。 Sun 在 90 年代后期就已经了解这个严重度， 当时他们请了 Cliff Click 博士来提供解决方案。

Hot Spot

他们在虚拟机中引入了JIT编译器（即时编译器），当虚拟机发现某个方法或代码块运行特别频繁时，就会把这些代码认定为“Hot Spot Code”（热点代码），为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各层次的优化，完成这项任务的正是JIT编译器。 在某些情况下，调整好的最佳化 JVM 效能可能超过手工的 C++ 或 C。

现在主流的商用虚拟机（如Sun HotSpot、IBM J9）中几乎都同时包含解释器和编译器。当程序需要迅速启动和执行时，解释器可以首先发挥作用，省去编译的时间，立即执行；当程序运行后，随着时间的推移，编译器逐渐会返回作用，把越来越多的代码编译成本地代码后，可以获取更高的执行效率。解释执行可以节约内存，而编译执行可以提升效率。

运行过程中会被即时编译器编译的“Hot Spot Code”有两类：

•   被多次调用的方法。
•   被多次调用的循环体。

两种情况，编译器都是以整个方法作为编译对象，这种编译也是虚拟机中标准的编译方式。要知道一段代码或方法是不是热点代码，是不是需要触发即时编译，需要进行Hot Spot Detection（热点探测）。目前主要的热点 判定方式有以下两种：

• 基于采样的热点探测：采用这种方法的虚拟机会周期性地检查各个线程的栈顶，如果发现某些方法经常出现在栈顶&#x