JIT vs口译员
我找不到JIT和口译员之间的区别。
Jit是口译员和编译器的中介。 在运行时，它将字节代码转换为机器代码（JVM或实际机器？）下次，它从缓存中运行并运行Am i对吗？
解释器将直接执行字节码而不将其转换为机器代码。 是对的吗？
我们电脑中真正的处理器如何理解指令。
请清除我的疑虑。
第一件事：
使用JVM，解释器和编译器 （JVM编译器而不是像javac这样的源代码编译器）从字节代码 生成本机代码 （也就是x86等底层物理CPU的机器语言代码）。
那么有什么不同：
不同之处在于它们如何生成本机代码，如何优化以及优化的成本。 非正式地，解释器通过查找预定义的JVM指令到机器指令映射，几乎将每个字节码指令转换为相应的本机指令（见下图）。 有趣的是，如果我们采用一段字节代码并将其转换为机器代码，可以实现进一步的执行加速 – 因为考虑整个逻辑部分通常提供优化空间而不是单独转换（ 解释 ）每一行（ 机器指令 ）。 将一段字节码转换为（可能是优化的）机器指令的这种行为称为编译（在当前上下文中）。 在运行时完成编译时，编译器称为JIT编译器。
相互关系和协调：
由于Java设计师追求（ 硬件和操作系统 ）可移植性，他们选择了解释器架构（ 而不是c风格编译，组装和链接 ）。 但是，为了实现更高的速度，还可以选择将编译器添加到JVM。 尽管如此，当程序继续被解释（并在物理CPU中执行）时，JVM会检测到“热点”并生成统计信息。 因此，使用解释器的统计信息，这些部分成为编译的候选者（优化的本机代码）。 它实际上是在运行中（因此JIT编译器）完成的，并且随后使用编译的机器指令（而不是被解释）。 以自然的方式，JVM还缓存这些编译的代码片段。
注意事项：
这几乎是基本概念。 如果是JVM的实际实现者，有点不同的方式，不要感到惊讶。 VM可能就是其他语言的情况。
注意事项：
“解释器在虚拟处理器中执行字节代码”，“解释器直接执行字节代码”等语句都是正确的，只要您了解最终有一组机器指令必须在物理硬件中运行。
一些好的参考文献： [虽然我没有做过广泛的搜索]
- [纸张] Hitoshi Oi在基于硬件翻译的Java虚拟机中的指令折叠
- [书]计算机组织与设计，第4版，DA Patterson。 （ 见图2.23 ）
- [web-article] JVM性能优化，第2部分：编译器，作者：Eva Andreasson（JavaWorld）
PS：我可以互换地使用以下术语 – “本机代码”，“机器语言代码”，“机器指令”等。
-
解释器：读取源代码或其中间表示（字节码），并直接执行。
-
JIT编译器：读取您的源代码，或者更典型的是它的一些中间表示（字节码），即时编译并执行本机代码 。
Jit是口译员和编译器的中介。 在运行时，它将字节代码转换为机器代码（JVM或实际机器？）下次，它从缓存中运行并运行Am i对吗？
是的，你是。
解释器将直接执行字节码而不将其转换为机器代码。 是对的吗？
是的。
我们电脑中真正的处理器如何理解指令。
在解释器的情况下，虚拟机执行与字节代码中的每个指令相对应的本机JVM过程以产生预期的行为。 但是，与Jit编译器一样，您的代码实际上并未编译为本机代码。 JVM模拟每条指令的预期行为。
JIT编译器将字节代码转换为机器代码，然后执行机器代码。
口译员阅读您的高级语言（解释它）并执行您的程序所要求的内容。 解释器通常不通过字节码和jit编译。
但是这两个世界已经融化，因为许多解释器已经采用内部字节编译和jit编译的路径，以提高执行速度。
我很确定JIT会将字节代码转换为机器代码，因为您正在运行的任何机器都需要它。 替代方法是在java虚拟机中运行字节代码。 我不确定这是否与解释代码相同，因为我更熟悉该术语用于描述脚本（非编译）语言（如ruby或perl）的执行。
第一次在JVM中引用类时，JIT执行引擎将包含JVM指令集的Java Compiler生成的.class文件（主二进制文件）重新编译为包含HOST系统指令集的二进制文件。 JIT存储并重用来自Memory的那些重新编译的二进制文件，通过减少解释时间和Native代码执行的好处。
还有另一种风格可以通过识别应用程序的大部分重用部分并仅在其上应用JIT来实现Adaptive Optimization，通过优化内存使用来实现。
另一方面，普通的旧java解释器一次解释来自类文件的一个JVM指令并调用针对它的过程。
在这里找到详细比较