我理解为什么会发生冷启动(字节码需要通过JIT编译转化为机器码(。然而，现在所有生成的元数据都可以用于二进制文件，我不明白为什么没有一个简单的工具可以自动获取字节码，并将代码中的所有路径(自动发现(转换为特定于该目标平台的机器代码。这意味着通过任何路径的第一个请求(假设有一个rest api(都会很快，不需要任何进一步的实时编译。
在允许机器进入负载均衡器旋转之前，我们可以创建一个自动化测试套件或负载测试来JIT所有路径(无论如何都是好的最佳实践(。我们还可以翻转"；"始终打开"；在云托管提供程序中设置，以防止预热的应用程序从内存中被逐出(需要重新启动整个过程(。然而，在2020年，这似乎是一个过时的过程。
为什么没有这样的工具？是什么限制阻止我们使用元数据、调试符号和/或其他手段来理解如何生成从一开始就为用户准备好的机器代码？
因此，我一直在询问我的专业网络中的一些敏锐的头脑，似乎没有人能够准确指出是什么限制使这项工作如此困难。然而，我确实在雷达上找到了一些工具，可以在一定程度上做我想要做的事情。
Crossgen似乎是最有前途的，但在我采访过的许多同行中，它还远没有被广泛使用。我们必须仔细观察。
还有一些执行某种启动任务，运行一些类初始化，并将它们注册为singleton。我认为这些与在应用程序上运行集成或负载测试没有太大区别。
大多数编程语言都有某种形式的本地图像编译器工具。这取决于你使用它们，如果这是你想要做的。
提供商应该为您的应用程序提供一个平台，您应该从提供商那里获得一定程度的隔离和隐私。他们不应该去挖掘你的应用程序，以找出它的所有"；路径"；。这将是非常具有侵入性的。
加上"；"预热"；对于提供者来说，所有路径都是一个资源密集型的过程，必须为其托管的每个应用程序执行。