Java 加速jvm预热时间

可能重复：

---

我知道JVM需要一段时间来“预热”，这取决于代码大小。我的问题是：程序员是否有办法通过指定代码中可能要查看的部分来帮助加速“预热”过程？

您可以通过多次调用代码来间接实现。默认值

-xx:CompileThreshold=

为10000。因此，您可以多次调用关键代码，例如12000次

您可以降低编译阈值，但仍然存在相同的问题，只是循环可以是1000而不是10000

您希望对代码进行预热的一个原因是对其进行优化，但如果缩短迭代次数，则可能无法执行某些优化，并且您可能会得到次优调用（但并非总是如此）

---

然后，如果你预热代码是一种不具有代表性的方式，它可以以次优的方式优化它，JVM可以决定以后再优化它。

< P>你可能想考虑一个超前编译器，例如GCJ，它允许你在构建应用程序时编译一组类到本机代码，并且只在虚拟机中运行运行时加载的类。编译完成后的性能没有那么好（特别是如果您在运行时花费大量时间加载代码），但对于运行时间较短的程序，预编译带来的好处远远抵消了这一点。

在developerWorks上，Java的微性能测量确实很好。它还包括“热身”和其他相关内容。作者在Java中实现了一个非常好的微基准测试框架。这个框架还处理JVM的预热阶段，并试图加快它的速度，并在实际测试开始之前完成它。该框架的源代码也可用，因此您可以看看它是如何实现的。

请检查我的建议-可能它也适用于您。为什么不将选项更改为较低的数字？@assylias好问题，添加到我的答案中。Peter，我会非常小心地给出此建议。我认为调整CompileThreshold是个好主意的案例数量非常少。也有交互作用——例如，如果代码缓存被填满，那么用户可能会错过编译重要方法的机会（例如，思考Spring应用程序可能的行为）。我们应该做一些实验。@kittylyst如果我的答案不清楚，我认为调整编译阈值永远都没有帮助，充其量也不会让事情变得更糟。我在使用大量代码库优化JVM方面没有太多经验，而且我从未遇到过关键代码（我建议预热）太大而无法完全优化的问题。如果这是一个问题，我建议减少代码库的一部分，或者我怀疑确保优化关键代码可能是一件好事。内联调优的另一个选项：-XX:MaxInlineSize=，其中n-是允许内联的方法（字节码）的最大长度。但是，正如上面Peter所指出的，最好不要触及此类选项，而是将代码的关键路径仔细分解为小方法。