为什么JAVA不在安装后立即将其IL编译成本机代码？

我只是看书

如前几篇文章所述，JIT可以在运行时将IL/字节码编译成本机代码。提到了这方面的成本，但没有得出结论：

JIT有一个巨大的问题是它不能编译所有东西：JIT编译需要时间，因此JIT只编译部分代码，而静态编译器将生成完整的本机二进制代码：对于某些类型的程序，静态编译器的性能很容易超过JIT

我很好奇为什么java在设备中安装时不编译所有东西

---

如果是这样的话，我们就不需要考虑编译时间带来的性能损失，也不需要考虑不同的设备。

实际上它依赖于JVM。新的谷歌JVM使用AOT：

ART使用提前（AOT）编译器，在安装应用程序时编译为机器代码

如果你问为什么以前的Sun，现在Oracle的JVM不使用AOT——这是Sun工程师当时的选择。对于桌面Java，没有（通常）安装应用程序的步骤允许进行AOT，而在加载时编译整个类路径太耗时

---

更多，当然是在站点上。

它没有这样做，因为它没有定义这样做。你的问题？这有正反两方面。JIT编译代码的一个优点是编译器知道在编译代码时如何使用代码。如果您提前编译它，这是不可能的（除非您从上一次运行中向它提供数据），Java确实可以控制整个设备，您可以在不使用JVM的情况下更改任何文件或任何JAR，因此它不知道如何使过程容易出错。对于Android，它知道你什么时候安装应用程序或给它加上日期，这样它就知道编译和更改什么了。此外，就设备的启动时间而言，动态编译的成本更高。对于服务器来说，这比它能够支持的用户数量和长期效率更重要。AOT缺点：可能就像你有一个应用程序，它可能有很多代码更改、新的更新、错误修复、补丁和连续部署性质。因此，您的代码必须更频繁地重新编译，并获得机器代码，这将成为开销。对于许多移动应用程序，您可能不会期望如此频繁的代码更改、修复等，因此必须一次性编译并使用相当稳定的代码。然而，考虑一个广泛使用的系统软件，包括分布式DEV团队、CI/CD等。您可以期望重复编译。因此，在这种情况下，JIT是更好的选择。