为什么Java 8的升温速度较慢？

Question

在我们从Java6 (u39)过渡到Java8 (u51)的过程中，我们面临的问题是，与6相比，Java8的热身时间更长。

我们注意到这一点，无论是作为Java程序运行性能测试，还是使用Java 8启动Tomcat 7 (u35)时的初始请求。

我们正在Linux Redhat 64位系统上运行。

很抱歉，我没有任何孤立的测试用例。

关于性能测试程序，我发现Java 6在10次迭代中接近于大约215毫秒的稳态性能，而Java 8在10次迭代后花费了800毫秒，并进行了70+迭代以达到215 ms。

当我们在tomcat上以10的并发性运行JMeter测试时(使用Spring2.5、jackson、xerces XML解析器、jedis等)。在重新启动Java 6之后，立即需要不到一分钟的时间来提供稳定的状态性能，而Java 8则需要5-6分钟左右的时间，并且在此之前要慢几个数量级。

在Java8中，使用-XX:-TieredCompilation选项关闭分层编译，用性能测试程序解决了热身问题，而稳态性能没有变化。这是令人惊讶的，因为分层编译实际上应该提供更快的热身。

然而，关闭分层编译并没有给Tomcat服务器的预热时间带来类似的改善。

我欢迎任何解决这个问题的建议，因为在一个活动环境中部署一个新的构建会成为一个麻烦，需要很长的热身时间。

谢谢你，苏雷什

Answer 1

这是令人惊讶的，因为分层编译实际上应该提供更快的热身。

您混淆了时间到峰值的性能和时间到初始化/响应的应用程序。

+分层

• 翻译(0级) -> C1 (1-3级) -> C2 (4级)
• 繁重的C2工作会被延迟到稍后的时间点
• 在c1编译代码上花费更多的时间意味着应用程序启动后的类型配置文件可能更干净，从而可以在C2中进行更好的优化和减少反编译。
• 应用程序可以在更早/到达用户交互性/短暂的java执行完成之前提供它的第一个请求。

-Tiered

• 解释器-> C2
• 热码可能会更快地达到峰值性能。
• 初始化和仅仅是温暖的代码可能需要更长的时间。
• 在某些情况下，花费较少的分析时间可能会导致代码稍微不太理想。

另一件要处理的事情是编译器线程的数量(CICompilerCount)。性能权衡是复杂的，因此简单地对各种设置进行基准测试是有帮助的。