为什么JVM在使用即时编译器时使用解释器？
我们知道，JVM同时使用解释器和JIT编译器。JIT编译器将重复的字节码转换为机器码并存储在内存中。现在，当解释器逐行翻译字节码并运行它时，它将跳过已转换并存储在内存中的重复代码的翻译部分，但将直接运行它。从而减少了并发冗余翻译。
那么为什么Java在JVM中使用解释器呢？像JIT这样的编译器可以一次性完成将字节码转换为机器码的整个任务吗？
共有3个答案
JRockit JVM没有解释器。它编译所有字节码，即使在调试时也是如此，所以没有必要。
解释器的一个好处是启动速度更快。例如，静态初始值设定项只执行一次，因此通常不需要编译它。
事实上，像GraalVM这样的现代Java实现确实提供了将整个Java字节码类——甚至整个应用程序——编译为本机代码的选项，但这是提前的，而不是在运行时。即时编译器当然可以实现在运行时处理整个类，从而完全避免解释的需要。
但是，当你在GraalVM的原生代码编译器执行它的工作时，有时间吃了一顿三道菜的饭之后，你就很容易理解为什么批量预编译不是JVM中的默认编译机制。编译到本机代码的速度可能很慢，而且Java本身不是一种可编译的语言。
大多数JVM提供某种形式的自适应解释/编译平衡，在运行时实现。对于大量重复的代码部分，解释是“缓慢的”，因为解释工作重复了很多次。对于只执行一次的代码，编译是“缓慢的”，因为编译工作必须在任何程序指令实际执行之前完成。
因此，现代Java实现提供了这两种策略，并试图平衡它们以在运行时获得最佳的总体性能。一般来说，我们想做的是（JIT）只编译应用程序中编译时间成本被其带来的好处抵消最多的部分。如何做到这一点一直是大量研究的主题，新方法也在不断发展。
这个答案中有一个很好的比较，让我明白了为什么Java同时使用AOT和JIT。
这里提到的JIT的“微调”是在JVM的编译器中完成的，它针对其运行的每个系统进行了优化。而且你没有考虑链接中列出的缺点。
-
在Google的Python类中 Python是一种动态的解释（字节码编译）语言 我知道什么是解释器，也知道什么是字节码，但两者加在一起似乎不合适。在阅读了一些之后，我变得更清楚了，基本上Python源代码在被解释之前是自动编译的；但是出现了一些新的问题。 使用Python解释器时，不会发生编译吗？如果有，什么时候？例如，如果您只是在命令行中键入代码，并且每次按enter键时它都会运行，那么编译器
-
UE4 的底层虽然是用 C++ 实现的，但它又不仅仅是一个 C++ 库，它还实现了自己的编译机制。换句话说，UE4 对现有的 C++ 语法进行了改进，以适应游戏开发的场景。 当然，UE4 也不会疯狂到自己去开发一个 C++ 编译器，它还是需要依赖传统的 C++ 编译器以及相关的编程套件。 熟悉 Qt 的读者应该知道，Qt 虽然也使用 C++，但是它还提供了信号和槽的机制，这是原生 C++ 里面没有
-
请注意，我的问题是关于JVM解释器，而不是JIT编译器。JIT编译器将java字节码转换为本机代码。因此，这必须意味着JVM中的解释器不会将字节码转换为机器码。因此，问题是：从本质上讲，口译员做什么？如果有人能帮我用一个简单的字节码示例来回答这个问题，相当于1 1=2，即解释器在执行这个加法操作时做了什么？（我的隐含问题是，如果解释器不翻译为机器代码，那么哪个CPU执行添加操作，那么该操作是如何执
-
问题内容： 我对JVM有一个非常基本的问题：它是编译器还是解释器？ 如果它是解释器，那么JVM内部存在的JIT编译器怎么办？ 如果两者都不是，那么JVM到底是什么？（我不希望将字节码转换为机器特定的代码等jVM的基本定义。） 问题答案： 首先，让我们对以下术语有一个清晰的认识 是Java编译器-将Java代码编译为 Bytecode 是Java虚拟机-运行/解释/将字节码转换为本 机代码 是即时编
-
所有编程语言都被翻译成机器代码，然后由硬件解释器执行。但是什么翻译译码器的代码，例如编译器代码和解释器代码？编译器翻译源代码，但编译器也用某种语言编写，那么什么翻译编译器代码/代码呢？ 谢谢