我阅读了一些关于 JVM 和字节码的资料。我认为如果 JVM 可以在第一次运行时将字节码翻译成平台相关的机器码，而不是一直解释它们，效率会更高。
但是，我在我的项目文件夹中找不到此类文件。只有 bin 和 src 文件夹，其中包含 *.class 字节码和 *.java 源代码。
所以我的问题是：
如果Java一直都在解释字节码，为什么不在第一次运行后将字节码翻译成机器码呢？
如果他们生成机器码，文件在哪里？
【问题讨论】：
标签： java jvm bytecode machine-code
【讨论】：
如果Java一直在解释字节码，为什么不翻译字节码 第一次运行后转机器码？
提前 (AOT) 和及时 (JIT) 编译各有利弊。
AOT 的主要优点是编译器通常允许花费更长的时间，因此它可以执行更复杂的分析和优化。另一个优点是编译器不必在运行时出现在目标机器上。缺点就是其他。
JIT 的主要优点是编译器能够根据仅在运行时才知道的信息进行优化。事实上，当条件发生变化时，甚至可以取消优化和重新优化代码。此外，与 AOT 编译器不同，JIT 不必浪费时间优化从不运行或很少运行的代码。
某些语言旨在支持一种方法而不是另一种方法。例如，C/C++ 是为 AOT 设计的，而 Java 是为 JIT 设计的（尽管它可以编译为 AOT，但有一些限制）。例如，Java 非常强调虚拟 getter 和 setter，可能是针对直到运行时才加载的类。但是 JIT 可以在运行时查看和内联这些函数。相比之下，如果您对 C++ 中的每个字段访问都使用虚拟方法，则会付出巨大的性能损失。
【讨论】：
它不会一直解释代码。解释的代码在一段时间后被翻译成字节码。您可以使用 -XX:CompileThreshold=（默认为 10000）调整此“时间”，也可以完全关闭编译。
在内存中。内存中有一个特殊区域，称为“代码缓存”。您可以使用 -XX:+PrintCompilation 查看方法如何编译到缓存中以及如何将它们从缓存中逐出。缓存的大小也是可配置的，参见 -XX:ReservedCodeCacheSize=。
【讨论】：
嗯，JVM 已经对数据进行了预处理，但只针对它自己的类。鉴于 JRE 库的大小以及它通常不会更改的事实，这是一个巨大的胜利（您可能会查找名为 classes.jsa 的文件）。
但是，即使这些文件也不包含本机代码，而只包含更易于处理的字节码。
Hot Spot JVM 中代码生成的重点在于，它们不会像您想象的那样基于类或方法编译代码。当在自我分析期间发现交互时，这些 JVM 编译跨越多个交互方法的代码片段。这些代码块可能跨越 JRE、扩展库、类路径中的第 3 方库和应用程序类中的方法，因此仅对这种特定组合有效。
在编译期间，将使用收集到的有关程序行为的信息，例如可能会省略未采用的代码路径，并且可能会断言条件以评估某个结果，就像它们在以前的评估中所做的那样。这会产生高性能，但是当其中一个断言不再成立时，JVM 可能不得不删除代码即使在同一执行期间，例如程序可能采用以前没有的代码路径，或者新类已加载到 JVM 中，该类扩展了代码已优化的类，就好像没有子类一样，等等。
因此，如果优化和编译的代码即使在相同的环境中也可能会过时，那么在下一次执行时它就更有可能过时。最后，JVM 必须检查旧代码是否仍然合适，这可能比简单地收集新环境的数据和程序行为更昂贵。
【讨论】：