我正在尝试理解Java源代码是如何执行的，而我对JVM内部的JIT编译器实际上是什么感到困惑。首先，让我告诉您我是如何理解从Java源代码到在计算机上执行机器代码的过程。也许，我误解了导致混乱的过程中的某些事情。
步骤：
现在，根据Wikipedia article on JVM，更具体地说是“字节码解释器和即时编译器”部分，为了执行Java字节码，您需要一个解释器（但是我们有一个JIT 编译器）。
现在这里有点困惑我。我把它分成了引号：
“当解释器执行Java字节码时，执行总是比编译为本机机器语言的同一程序的执行慢。”
由于计算机只能执行机器代码，并且解释器在将字节码转换为机器代码方面比编译器慢，为什么JVM使用解释器而不是编译器？
为什么我们没有为JIT编译器为CPU生成另一个中间可执行文件，以便它可以快速执行指令？
“JIT编译器可以在执行程序时将Java字节码转换为本机机器语言。然后，程序的翻译部分可以比它们解释的更快地执行。这种技术适用于那些部分。经常执行的程序。“
JIT编译器真的是一个能够编译频繁执行的代码的解释器吗？编译器和解释器这两个术语是否可以互换使用？
提前致谢。
答案 0 :(得分：4)
由于计算机只能执行机器代码，并且解释器在将字节码转换为机器代码方面比编译器慢，为什么JVM使用解释器而不是编译器？
因为编译到机器代码也需要时间，特别是当它必须分析代码以优化它时，所以解释很快就足以执行大部分时间，并且实际上比编译+运行更快，如果只运行一次/一次。
此外，解释器不会“将字节码转换为机器代码”。它评估字节码并执行字节码所请求的操作。解释器本身是机器代码，但它不转换字节码，它解释/评估字节码。
为什么我们没有为JIT编译器为CPU生成另一个中间可执行文件，以便它可以快速执行指令？
这将违反Write Once，Run Anywhere范式的Java。
JIT编译器真的是一个能够编译经常执行的代码的解释器吗？
不，JIT编译器（或更准确地说，HotSpot编译器，如mentioned by EJP）是JVM根据需要执行的编译器。
编译器和解释器这两个术语是否可以互换使用？
正确。它们不能互换使用，因为它们不会做同样的事情。解释器执行字节码。 JIT / HotSpot编译器将字节码转换为机器码，但不运行它。
答案 1 :(得分：2)
由于计算机只能执行机器代码和解释器 将字节码转换为机器码比编译器慢 是，为什么JVM使用解释器而不是编译器？
优化编译是一个非常持久的过程。如果程序运行时间较长，这笔费用是合理的。
在错误的地方进行优化是不必要的。一段遍历一次的代码将比解释时间消耗更多的编译时间，因此解释是可以的。
如果频繁处理代码的某些部分，编译器会更好地处理这两个主题。
为什么我们没有生成另一个中间可执行文件 CPU的JIT编译器，因此它可以快速执行 指令？
此“文件”（已编译的片段）确实存在于内存中。它未被序列化为文件，因为：
JIT编译器真的是一个能够编译＆gt;的解释器吗？经常执行的代码？是编译器和解释器这两个术语 错误地互换使用？
虽然JVM Hotspot编译器编译频繁执行的代码，但其他JIT编译器可能会根据其他启发式方法决定编译。术语“JIT编译器”和“解释器”不能清楚地区分。大多数解释器都会优化（及时编译），几乎每个JIT编译器都会解释。