为什么在热点服务器JVM中运行此代码片段实际上需要花费更长的时间？

问题描述

| 这是代码段： https://gist.github.com/987751 对我来说，它的时间是这样的： java-客户端：   for循环：23   方法调用时间：19 java-服务器：   for循环：0＃，比预期的快   方法调用：48＃更慢-预期？ 因此，第一个问题将是“为什么它比客户端VM慢” 而且我猜下一个问题是“方法调用方式是否有可能获得超0ms的加速（几乎相同的代码）？” 我还假定尽管有这种怪异，但即使使用匿名类等，热点通常运行得也快得多？ 谢谢！ -罗杰-     

解决方法

有关如何调整Hotspot的两种口味的所有信息： 客户端已针对快速启动进行了调整。 JIT立即“几乎”编译方法。 在假定是长时间调整服务器实例的生命周期内，已针对服务器的较高吞吐量进行了调整。它允许解释器在JIT编译方法之前将方法运行更长的时间（收集使用情况统计信息）。然后（我相信）它会执行更具侵略性的优化……这需要更长的时间。 相关答案：“ java -server”和“ java -client”之间的真正区别？ 顺便说一下，它是同时运行客户端和服务器模式的Hotspot JVM。 AFAIK，差异是由于这两种模式选择了不同的默认JVM调整/配置参数。   因此，第一个问题将是“为什么它比客户端VM慢” 我不知道。 客户端模式可能会启用特定的优化，从而确实有助于（高度人工的）基准测试。也许服务器模式优化之一实际上是针对此（高度人为）基准的反优化。如果您真的想知道，请让JIT编译器转储本机代码并进行详细分析。 （但是我认为这是浪费时间。）   而且我猜下一个问题是“方法调用方式是否有可能获得超0ms的加速（几乎相同的代码）？” 这很容易。优化器已经发现方法调用不会影响其他任何东西，并且已经优化了该调用。然后也可以优化循环。   我还假定尽管有这种怪异，但即使使用匿名类等，热点通常运行得也快得多？ 我不认为你应该做任何事。 但是，我也不认为您的微基准测试对真实程序有任何有意义的意义。一般而言，微基准测试往往会产生误导，您的基准测试有缺陷（例如，已被优化的循环），并且似乎并未测试典型的（编写良好的）Java程序会做的事情。 如果您确实担心HotSpot两种模式的相对性能，则应在实际数据上运行并评估应用程序的性能。   ...以及为什么服务器JVM选择看似更差的东西？ 优化器旨在优化实际程序，而不是微基准测试，它们会花费时间来做奇怪的事情，这些事情与有用的计算没有任何相似之处。并非所有优化都在所有情况下都是有益的，并且您可能遇到了某种极端情况。 但这仅在您看到实际应用程序中发生相同事件时才有意义。 最后，您没有提供有关JVM版本，平台和硬件的任何详细信息。这些事情可能会对相对的绩效指标产生巨大的影响。