JIT 与口译员

JIT 编译器将字节码转换为机器码，然后执行机器码。

解释器读取您的高级语言(解释它)并执行程序要求的内容。解释器通常不通过字节码和 jit 编译。

Jit 是解释器和编译器的中介。在运行时，它将字节码转换为机器码(JVM 还是实际机器?)下一次，它会从缓存里拿出来，然后跑掉，对吧？

你就是。

解释器将直接执行字节码而不将其转换为机器码。是这样吗？

是的，没错。

我们电脑中的实际处理器将如何理解指令。 ? ？

对于解释器，虚拟机执行与字节码中的每条指令对应的本机 JVM 过程，以产生预期的行为。但是您的代码实际上并不像 Jit 编译器那样被编译成本机代码。JVM 模拟每条指令的预期行为。

我非常确定，JIT 可以根据需要将字节码转换为机器代码，用于正在运行的任何机器。另一种方法是在 Java 虚拟机中运行字节代码。我不确定这是否与解释代码相同，因为我更熟悉用来描述脚本(未编译)语言(如 Ruby 或 perl)执行的术语。

• 解释器: 读取您的源代码或它的一些中间表示(字节码) ，并执行它 直接。

• JIT 编译器: 读取您的源代码，或者更典型的是它的一些中间表示(字节码) ，动态地编译它并执行 本地代码。

在 JVM 中第一次引用类时，JIT 执行引擎将重新编译。Java 编译器生成的类文件(主二进制文件) ，包含 JVM 指令集到包含 HOST 系统指令集的二进制文件。JIT 通过减少解释时间和本机代码执行带来的好处来存储和重用那些重新编译后的内存二进制文件。

还有另外一种方式，即通过识别应用程序中大多数重用的部分并仅在其上应用 JIT 来实现自适应优化，这种方式通过优化内存使用来实现。

另一方面，一个普通的旧 Java 解释器一次从类文件中解释一条 JVM 指令，并针对它调用一个过程。

查找详细比较 给你

第一件事:
对于 JVM，解释器和编译器 (JVM 编译器，而不是 javac 这样的源代码编译器) 产生本地代码(也就是底层物理 CPU 的机器语言代码，比如 x86)来自 字节码。

那有什么区别呢:
区别在于它们如何生成本机代码，如何优化以及优化的成本有多高。非正式地，解释器通过查找预定义的 JVM 指令到指令映射(见下图) ，将每个字节码指令转换为相应的本机指令。有趣的是，如果我们将一段字节码转换成机器码，执行速度可以进一步提高——因为考虑整个逻辑部分通常会提供优化空间，而不是单独转换(翻译)每一行(指令)。这种将一段字节码转换成(可能是优化的)指令的行为被称为编译(在当前上下文中)。当编译在运行时完成时，编译器称为 JIT 编译器。

相互关系和协调:
由于 Java 设计师追求(硬件及操作系统)的可移植性，他们选择了解释器架构(而不是 c 风格的编译、汇编和链接)。然而，为了实现更高的速度，编译器还可以选择性地添加到 JVM 中。尽管如此，当程序继续被解释(并在物理 CPU 中执行)时，JVM 会检测到“热点”并生成统计信息。因此，使用来自解释器的统计信息，这些节成为编译(优化的本机代码)的候选节。它实际上是动态执行的(因此 JIT 编译器) ，随后使用编译后的机器指令(而不是进行解释)。以一种自然的方式，JVM 也缓存这样编译的代码片段。

警告:
这些基本概念。如果 JVM 的实际实现者有一点不同的方式，不要感到惊讶。虚拟机在其他语言中也可能是这种情况。

警告:
诸如“解释器在虚拟处理器中执行字节码”、“解释器直接执行字节码”等语句都是正确的，只要你理解到最终有一组机器指令必须在物理硬件中运行。

一些好的参考文献: [我还没有做过广泛的搜索]

• 基于硬件翻译的 Java 虚拟环境中的指令折叠 机器作者: 仁爱
• [书]计算机组织与设计，第四版，帕特森检察官。(见图2.23)
• [ web-article ] JVM 性能优化，第2部分: 编译器，作者 Eva Andreasson (JavaWorld)

PS: 我曾经互换使用过以下术语——“本地代码”、“机器语言代码”、“机器指令”等等。

解释器: 如果每次需要新的解释时都要多次调用某个方法，则解释字节码。

JIT: 当一个代码被多次调用时，JIT 转换本机代码中的字节码并执行它