由于JIT的固有优势（可以仅在运行时使用可用信息），我认为JIT编译器最终将在编译代码的性能方面击败AOT编译器。一个论点是AOT编译器可以花更多时间编译代码，但服务器VM也可能花费大量时间。
我确实理解JIT在某些情况下确实打败了AOT编译器，但在大多数情况下它们似乎仍然落后。
所以我的问题是，阻止JIT编译器击败AOT编译器的具体而棘手的问题是什么？
修改
一些常见的论点：
另一个编辑：
有关具体示例，请参阅此文章：Improving Swing Performance: JIT vs AOT Compilation。从我从本文中可以收集的内容来看，作者基本上说当没有热点时，运行时信息的优势会降低，因此没有JIT开销的AOT就会获胜。但是40％？这似乎没有多大意义。仅仅是因为这种情况没有调整被比较的JIT编译器吗？或者它是更基本的东西？
答案 0 :(得分：29)
在JIT和AOT（提前）编译之间存在明确权衡。
正如您所说，JIT可以访问有助于优化的运行时信息。这包括有关其正在执行的计算机的数据，从而实现特定于平台的本机优化。但是，JIT还有将字节码转换为本机指令的开销。
这种开销通常在需要快速启动或接近实时响应的应用中变得明显。如果机器没有足够的资源进行高级优化，或者如果代码的性质无法“积极优化”，那么JIT也不会那么有效。
例如，取自the article you linked：
......我们该怎么办？ 在没有明显的性能瓶颈的情况下改善？你可以 已经猜到，配置文件引导的JIT存在同样的问题 编译器。而不是积极优化的几个热点， 有很多“热点”保持不变。
AOT编译器也可以根据需要花费尽可能多的时间进行优化，而JIT编译受时间要求（维护响应性）和客户端计算机资源的约束。因此，AOT编译器可以执行在JIT期间成本过高的复杂优化。
答案 1 :(得分：-1)
编译和优化是代码，环境详细信息和时间的函数。
AOT 可以根据需要使用尽可能多的时间，具有深入的代码分析和执行平台的知识，并带有其他优化提示。缺点是构建速度较慢，代码较少可移植性，基于假设的优化遗漏或不正确，并且可能不支持高级功能，例如在运行时进行反射
JIT 具有更高的可移植性，可以在运行时支持高级代码更改，但是运行时间和资源有限，因此优化潜力有限。
这是原始问题，但是现代的JIT编译器要快得多，并且在快速启动时仍能产生良好的代码，接近AOT性能。一些工具链使用一种中间格式，这种格式可以加快编译速度，从而有助于启动期间的JIT延迟。
真正的创新来自于多次编译，这意味着JIT可以花费与AOT一样多的时间，但是可以在应用程序的生命周期内摊销。这些次要通道更加全面，可以在考虑运行中的硬件（cpu / ram）和其他在AOT期间不可用的因素的同时优化实际的热路径。
最先进的JIT编译器可以超过AOT性能，并可以在更多情况下维持它。 AOT仍然是实现快速启动和一致性能的最佳选择，但不再是获得最佳原始性能的默认选项。