两种技术都需要谨慎选择编译的方法以实现最高的性能。对动态编译器而言，编译器自身作出决策，而对于静态编译器，由开发人员作出选择。让 JIT 编译器选择编译的方法是不是优点很难说，取决于编译器在给定情形中推断能力的好坏。在大多数情况下，我们认为这是一种优点。
因为它们可以最好地优化运行中的程序，所以 JIT 编译器在提供稳定状态性能方面更胜一筹，而这一点在大量的生产 Java 系统中最为重要。静态编译可以产生最佳的交互式性能，因为没有运行时编译行为来影响用户预期的响应时间。通过调整动态编译器可以在某种程度上解决启动和确定性性能问题，但是静态编译在需要时可提供最快的启动速度和最高级别的确定性。表 2 在四种不同的执行环境中对这两种编译技术进行了比较：
表 2. 使用这些技术的最佳环境
图 3 展示了启动性能和稳定状态性能的总体趋势：
图 3. AOT 和 JIT 的性能对比
使用 JIT 编译器的初始阶段性能很低，因为要首先解释方法。随着编译方法的增多及 JIT 执行编译所需时间的缩短，性能曲线逐渐升高最后达到性能峰值。另一方面，AOT 编译代码启动时的性能比解释的性能高很多，但是无法达到 JIT 编译器所能达到的最高性能。将静态代码绑定到 JVM 实例中会产生一些开销，因此开始时的性能比稳定状态的性能值低，但是能够比使用 JIT 编译器更快地达到稳定状态的性能水平。
没有一种本地代码编译技术能够适合所有的 Java 执行环境。某种技术所擅长的通常正是其他技术的弱项。出于这个原因，需要同时使用这两种编译技术以满足 Java 应用程序开发人员的要求。事实上，可以结合使用静态和动态编译以便提供最大可能的性能提升 —— 但是必须具备平台无关性，它是 Java 语言的主要卖点，因此不成问题。
结束语
本文探讨了 Java 语言本地代码编译的问题，主要介绍了 JIT 编译器形式的动态编译和静态 AOT 编译，比较了二者的优缺点。
虽然动态编译器在过去的十年里实现了极大的成熟，使大量的各种 Java 应用程序可以赶上或超过静态编译语言(如 C++ 或 Fortran)所能够达到的性能。但是动态编译在某些类型的应用程序和执行环境中仍然不太合适。虽然 AOT 编译号称动态编译缺点的万能解决方案，但是由于 Java 语言本身的动态特性，它也面临着提供本地编译全部潜能的挑战。
这两种技术都不能解决 Java 执行环境中本地代码编译的所有需求，但是反过来又可以在最有效的地方作为工具使用。这两种技术可以相互补充。能够恰当地使用这两种编译模型的运行时系统可以使很大范围内的应用程序开发环境中的开发人员和用户受益。
55/5<12345
