为什么 JIT 是 JVM 执行引擎的一部分？答案

【问题标题】：Why is JIT part of Execution engine of JVM?为什么 JIT 是 JVM 执行引擎的一部分？
【发布时间】：2019-09-16 12:21:36
【问题描述】：

下面是一个java程序的执行流程：

字节码 (Javac) -> 类加载器 -> 执行引擎 (JIT)。

当源代码被编译并且类加载器将字节码提供给执行引擎以解释和运行程序时，为什么当没有任何东西要编译时，即时 (JIT) 编译器会出现在执行引擎中？

【问题讨论】：

有字节码要编译。
此信息已过时约 20 年。 JIT 是早期 JVM 的一个特性，而且在提供它们的外部供应商中确实存在一个短暂的市场：例如赛门铁克。 JIT 很久以前就被 HotSpot JVM 取代了，它的工作原理完全不同。
@user207421 Hotspot 如何使用“完全不同的原则”？它将字节码“及时”编译为本机代码。 JIT 是当前所有 JVM 的基本特性。
@user207421 建议您阅读Wikipedia page on HotSpot的第一段，了解确实涉及JIT。
@Thilo 不，它编译已经执行了 10,000 次的字节码，或者任何启发式方法。 JIts 的问题在于他们编译了所有内容，正如您所说，“及时”，因此在收集任何统计数据之前； , '到处喷码';使用大量内存；并浪费了大量时间编译对执行时间没有显着影响的东西。

【解决方案1】：

字节码包含Java virtual machine 的抽象指令。这些指令不能由传统机器直接执行。 JIT 步骤将这个抽象的字节码编译成可以被机器的 CPU 执行的具体机器码。

【讨论】：

理论上也可以在执行引擎之外对本机代码进行这种编译（例如作为部署/安装过程的一部分），但它不再是 JIT（那将是 AOT -提前）。
或者可以完全不编译到本机代码，并使用纯粹的模拟/解释执行引擎，但这非常慢。（在出现 Hotspot 之前，JDK 的初始版本就是这样工作的）。
JIT 是一种性能优化，并不是执行“抽象指令”所必需的。解释器通过即时翻译机器特定指令来执行字节码；通常这已经足够了，但是当 JVM 运行时决定（基于分析）某个方法或循环“足够热”时，它会将其编译为机器代码以避免解释器步骤减慢它的速度。