众所周知，HotSpot 会分析运行时使用模式和性能特征，然后在 Java 应用程序运行时基于该分析优化 JIT 流程。因此，在尝试对 Java 应用程序进行基准测试时，通常建议谨慎行事，以便允许在进行实际性能测量之前进行此分析和优化阶段。
我确信这已经被考虑过，但我经常想知道为什么这个分析阶段（例如典型的使用模式）不能以某种方式作为构建过程的一部分，然后与应用程序一起部署的分析数据，以便全速 JIT应用程序启动时立即实现。
有谁知道这是否真的完成了，是否有原因导致这不可行，或者是否计划将其作为对 HotSpot 和 Java 应用程序部署的增强？
应用程序没有“典型使用模式”，尤其是在谈论 Java 应用程序时。它可以在 Windows、Linux、MacOS、Solaris 等环境下运行。运行时环境不仅完全改变了代码的行为，它还决定了哪些类甚至会在运行时存在。
例如，具有图形用户界面的应用程序将在 Windows、Linux 或 MacOS 下加载不同的 AWT 实现类。但即使是显示器像素格式（RGB 与 BGR，16 位与 24 位）的简单属性也会导致应用程序采用不同的代码路径。并且发布了新的 JRE 版本，不断改进 JFC 类的代码，从而改变运行时行为，使任何预先计算的分析数据变得无用。
认为在开发人员的计算机上进行测试和基准测试足以说明真实生产环境是一个典型的错误。当运行数十亿个并发事务时，或者另一方面，在只有一半 RAM 的客户 PC 上运行时，可能看起来足够的东西可能会变得完全不可用。
Java 的优势之一是能够针对软件的真实行为和使用模式进行分析和优化，并使用运行时找到的确切版本跨越来自不同供应商的库的边界进行优化。