JVM的即时编译器及优化，一篇文章就够了

学习JVM相关的知识，必然绕不开即时编译器，因为它太重要了。了解了它的基本原理及优化手段，在编程过程中可以让我们有种打开任督二脉的感觉。比如，很多朋友在面试当中还会遇到这样的问题：Java是基于编译执行还是基于解释执行？当你了解了Java的即时编译器，不仅能够轻松回答上述问题，还能如数家珍的讲出JVM在即时编译器上采用的优化技术，而且在实践过程中更深刻的理解代码背后的原理。本文便带大家全面的了解Java即时编译器。

即时编译器

在部分的商用虚拟机中，比如HotSpot中，Java程序先通过解释器（Interceptor）进行解释执行。这也是为什么称Java是基于解释执行的原因。但当虚拟机发现某块代码或方法运行的特别频繁，便会将其标记为“热点代码”（Hot Spot Code）。

针对热点代码，虚拟机会采用各种措施来提升其执行效率，因为执行比较频繁，如果能够提升其执行效率，性价比还是比较高的。为此，在运行时，虚拟机会把这些代码编译成与本地平台相关的机器码，并进行各层次的深度优化。而这些优化操作便是通过编译器来完成的，也称作即使编译器（Just In Time Compiler，简称 JIT 编译器）。

因此，准确的来说，像HotSpot等虚拟机，Java是基于解释执行和编译执行的。下面用一张图来解释该过程：

解释器与编译器的并存

首先，我们需要知道并不是所有的Java虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机（如HotSpot），都同时包含解释器和编译器。

既然即时编译器进行了各层次的优化，那么为什么Java还使用解释器来“拖累”程序的性能呢？这是因为，解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释器执行节约内存，反之可以使用编译执行来提升效率。此外，如果编译后出现“罕见陷阱”，可以通过逆优化退回到解释执行。

Java虚拟机运行时，解释器和即时编译器能够相互协作，取长补短。无论采用解释器进行解释执行，还是采用即使编译器进行编译执行，最终字节码都需要被转换为对应平台的本地机器码指令。某些服务并不看重启动时间，而某些服务却非常看重，这就需要采用解释器与即时编译器并存来换取一个平衡点。

我们可以从解释器和编译器的编译时间开销和编译空间开销两方面进行对比。首先，看编译的时间开销。

我们所说的JIT比解释器快，仅限于对“热点代码”编译之后的代码执行起来要比解释器解释执行的快。通过上图可以看出，如果是只是单次执行的代码，JIT编译比解释器要多出一步“执行编译”，因此，只执行一次时，JIT是要比解释器慢的。只执行一次的代码通常包括只被调用一次的代码（比如构造器）、没有循环的代码等，此时使用JIT显然得不偿失。

其次，再来看看编译空间方面的开销