静态编译和动态编译分别是什么？
动态编译（dynamic compilation），指的是“在运行时进行编译”；
与之相对的是事前编译（ahead-of-time compilation，简称AOT），也叫静态编译（static compilation），程序运行前就把代码全部翻译成机器码
参考：
JIT编译是什么？
JIT编译（just-in-time compilation）狭义来说是当某段代码即将第一次被执行时进行编译，因而叫“即时编译”。JIT编译是动态编译的一种特例。
JIT编译一词后来被泛化，时常与动态编译等价；但要注意宽泛与狭义的JIT编译所指的区别。
JIT编译，全称 just-in-time compilation，按照其原始的、严格的定义，是每当一部分代码准备要第一次执行的时候，将这部分代码编译，然后跳进编译好的代码里执行。这样，所有执行过的代码都必然会被编译过。早期的JIT编译系统对同一个块代码只会编译一次。JIT编译的单元也可以选择是方法/函数级别，或者别的，例如trace。
参考：
解释执行是什么意思？
解释器：只在执行程序时，才一条一条把字节码解释成机器语言给计算机来执行
Java需要将字节码逐条翻译成对应的机器指令并且执行，这就是传统的JVM的解释器的功能，正是由于解释器逐条翻译并执行这个过程的效率低，引入了JIT即时编译技术。
为什么要遇到热点代码才要编译字节码为机器码？为什么不把所有的字节码都编译为机器码？
因为有些代码在将来只执行一次也有可能不执行，全部编译占用空间也浪费时间。
JIT编译器有什么好处？
在运行时编译，可以实时的获取运行时的信息，更好的做编译优化；静态编译是无法做这种优化的。
A JIT compiler runs after the program has started and compiles the code (usually bytecode or some kind of VM instructions) on the fly (or just-in-time, as it’s called) into a form that’s usually faster, typically the host CPU’s native instruction set. A JIT has access to dynamic runtime information whereas a standard compiler doesn’t and can make better optimizations like inlining functions that are used frequently.
为何 HotSpot 虚拟机要使用解释器与编译器并存的架构？
解释器与编译器两者各有优势。
解释器：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。
编译器：在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。
两者的协作：在程序运行环境中内存资源限制较大时，可以使用解释执行节约内存，反之可以使用编译执行来提升效率。当通过编译器优化时，发现并没有起到优化作用，，可以通过逆优化退回到解释状态继续执行。
尽管并不是所有的Java虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机（如HotSpot），都同时包含解释器和编译器。解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释器执行节约内存，反之可以使用编译执行来提升效率。此外，如果编译后出现“罕见陷阱”，可以通过逆优化退回到解释执行。
解释器的执行，抽象的看是这样的：输入的代码 -> [ 解释器 解释执行 ] -> 执行结果
而要JIT编译然后再执行的话，抽象的看则是：输入的代码 -> [ 编译器 编译 ] -> 编译后的代码 -> [ 执行 ] -> 执行结果
说JIT比解释快，其实说的是“执行编译后的代码”比“解释器解释执行”要快，并不是说“编译”这个动作比“解释”这个动作快。JIT编译再怎么快，至少也比解释执行一次略慢一些，而要得到最后的执行结果还得再经过一个“执行编译后的代码”的过程。所以，对“只执行一次”的代码而言，解释执行其实总是比JIT编译执行要快。怎么算是“只执行一次的代码”呢？粗略说，下面两个条件同时满足时就是严格的“只执行一次”
1、只被调用一次，例如类的构造器（class initializer，
2、没有循环
对只执行一次的代码做JIT编译再执行，可以说是得不偿失。对只执行少量次数的代码，JIT编译带来的执行速度的提升也未必能抵消掉最初编译带来的开销。只有对频繁执行的代码，JIT编译才能保证有正面的收益。
对一般的Java方法而言，编译后代码的大小相对于字节码的大小，膨胀比达到10x是很正常的。同上面说的时间开销一样，这里的空间开销也是，只有对执行频繁的代码才值得编译，如果把所有代码都编译则会显著增加代码所占空间，导致“代码爆炸”。这也就解释了为什么有些JVM会选择不总是做JIT编译，而是选择用解释器+JIT编译器的混合执行引擎。
参考：
HotSpot虚拟机为什么叫Hotspot？
通常，我们不必把所有的Java方法都编译成机器码，只需要把调用最频繁，占据CPU时间最长的方法找出来将其编译成机器码。这种调用最频繁的Java方法就是我们常说的热点方法（Hotspot，说不定这个虚拟机的名字就是从这里来的）。
HotSpot VM得名于它得混合模式执行引擎：这个执行引擎包括解释器和自适应编译器（adaptive compiler）。默认配置下，一开始所有Java方法都由解释器执行。解释器记录着每个方法得调用次数和循环次数，并以这两个数值为指标去判断一个方法的“热度”。显然，HotSpot VM是以“方法”为单位来寻找热点代码。等到一个方法足够“热”的时候，HotSpot VM就会启动对该方法的编译。这种在所有执行过的代码里只寻找一部分来编译的做法，就叫做自适应编译（adaptive compilation）。
参考：
JIT编译与HotSpot虚拟机有什么关系？
首先，如果一段代码本身在将来只会被执行一次，那么从本质上看，编译就是在浪费精力。因为将代码翻译成 java 字节码相对于编译这段代码并执行代码来说，要快很多。
当然，如果一段代码频繁的调用方法，或是一个循环，也就是这段代码被多次执行，那么编译就非常值得了。因此，编译器具有的这种权衡能力会首先执行解释后的代码，然后再去分辨哪些方法会被频繁调用来保证其本身的编译。
在部分的商用虚拟机（Sun HotSpot、IBM J9）中，Java程序最初是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”（Hot Spot Code）。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，本文中简称JIT编译器）。
参考：