JVM——对编译器，JIT，解释器的存在和解决问题的理解

初次学习JVM，有不少理解不到位的地方，希望看客们谅解

 

问题：为什么jvm现在的结构是两级即时编译器、 编译器与解释器混合工作模式。

 

分解1：在理解为什么处理的关键，我们需要了解c和c++这种编译性质的语言与java在运行方面的区别

参考：https://blog.csdn.net/touzani/article/details/1625760

c与c++是编译性质的语言，语言需要编译成为机器码才能够和cpu打交道，经过编译过后的代码执行非常快。

java是解释性质的语言，我们撇开java之后版本做的预编译不谈，java1.0版本所用的虚拟机是Classic VM。 这款虚拟机只能使用纯解释器方式来执行Java代码，这是最早的Java建置方案是由一套转译程式（interpreter），将每个Java指令都转译成对等的微处理器指令，并根据转译后的指令先后次序依序执行，由于一个Java指令可能被转译成十几或数十几个对等的微处理器指令，这种模式执行的速度相当缓慢。

针对这个问题，业界首先开发出JIT（just in time）编译器。当Java执行runtime环境时，每遇到一个新的类别（class：类别是Java程式中的功能群组），JIT编译器在此时就会针对这个类别进行编译（compile）作业。经过编译后的程式，被优化成相当精简的原生型指令码（native code），这种程式的执行速度相当快。花费少许的编译时间来节省稍后相当长的执行时间，JIT这种设计的确增加不少效率，但是它并未达到最顶尖的效能，因为某些极少执行到的Java指令在编译时所额外花费的时间可能比转译器在执行时的时间还长，针对这些指令而言，整体花费的时间并没有减少。

而且对于java1.0的Classic VM虚拟机，其不能和JIT一起运作，如果要使用JIT编译器，就必须进行外挂。 但是假如外挂了JIT编译器，JIT编译器就完全接管了虚拟机的执行系统，解释器便不再工作了。

由于解释器和编译器不能配合工作，这就意味着如果要使用编译器执行，编译器就不得不对每一个方法、 每一行代码都进行编译，而无论它们执行的频率是否具有编译的价值。 基于程序响应时间的压力，这些编译器根本不敢应用编译耗时稍高的优化技术，因此这个阶段的虚拟机即使用了JIT编译器输出本地代码，执行效率也和传统的C/C++程序有很大差距，“Java语言很慢”的形象就是在这时候开始在用户心中树立起来的。

基于对JIT的经验，业界发展出动态编译器（dynamiccompiler），动态编译器仅针对较常被执行的程式码进行编译，其余部分仍使用转译程式来执行。也就是说，动态编译器会研判是否要编译每个类别。动态编译器拥有两项利器：一是转译器，另一则是JIT，它透过智慧机制针对每个类别进行分析，然后决定使用这两种利器的哪一种来达到最佳化的效果。动态编译器针对程式的特性或者是让程式执行几个循环，再根据结果决定是否编译这段程式码。这个决定不见得绝对正确，但从统计数字来看，这个判断的机制正确的机会相当高。事实上，动态编译器会根据「历史资料」做决策，所以程式执行的时间愈长，判断正确的机率就愈高。以整个结果来看，动态编译器产生的程式码执行的速度超越以前的JIT技术，平均速度可提高至50%。​​​​​​​

 

​​​​​​​to be continued