部署前的Java热点分析？

众所周知，HotSpot分析运行时使用模式和性能特征，然后在Java应用程序运行时基于该分析优化JIT流程。因此，在尝试对Java应用程序进行基准测试时，通常建议谨慎，以便允许在进行实际性能测量之前进行此分析和优化阶段

我确信这一点以前就已经考虑过了，但我经常想知道为什么这个分析阶段（例如典型的使用模式）不能作为构建过程的一部分，然后将分析数据与应用程序一起部署，以便在应用程序启动时立即实现全速JIT

---

有没有人知道这是否真的做到了，这是否是不可行的原因，或者这是否计划作为对热点和Java应用程序部署的增强？

应用程序没有“典型使用模式”，特别是在讨论Java应用程序时。它可以在Windows、Linux、MacOS、Solaris等环境下运行。运行时环境不仅会完全改变代码的行为，还会决定哪些类在运行时会存在

例如，具有图形用户界面的应用程序将在Windows、Linux或MacOS下加载不同的AWT实现类。但即使显示器像素格式的简单特性（RGB与BGR，16位与24位）也会导致应用程序采用不同的代码路径。而且发布了新的JRE版本，不断改进JFC类的代码，从而改变运行时行为，使任何预先计算的评测数据都变得无用

如果认为在开发人员的计算机上进行测试和基准测试就足以说明真实的生产环境，这是一个典型的错误。在运行数十亿个并发事务时，或者在另一方面，在一台只有一半RAM的客户PC上，看起来足够的东西可能完全无法使用

---

Java的优势之一是能够根据软件的实际行为和使用模式进行分析和优化，并使用运行时发现的准确版本跨不同供应商的库进行优化。

好吧，凭直觉说，为了便于It分析，它必须或多或少地运行代码，或者用某种逻辑逐步完成它。它也不能真正预测用户输入，最终会有一个模式。当您运行程序时，它会得到一个很好的数据样本集是的，但是总会有一些非常典型的使用模式，在部署之前可以很容易地分析它们。为什么不能部署这些模式的分析信息？通常会有不太常见的使用模式，但可以像HotSpot现在在实际运行时那样对它们进行分析和优化。什么是“非常典型的使用模式”？如果在程序中间选择一个随机的<代码> int <代码>变量，您能通过查看代码来确定它是否可能低于50吗？我确信对于一些简单的应用程序，执行路径非常有限，因此几乎所有典型的使用模式都可以在任何最终用户获得应用程序之前预测和分析。每次启动应用程序时，HotSpot重新分析这些模式似乎有点多余。@FelixBrack的整个逻辑是：在这种情况下，它可能很容易，在这种情况下，它可能很容易，这正是它的困难所在。作为一个人，你经常可以很容易地发现这些东西。然而，计算机通常必须正常工作。您不能只编写巨型if语句来检查不同的情况，并分析这是否是这些情况中的一种。不过，它在编译时确实尽了最大努力，至少尽可能提高字节码的效率。