4

我对升级到 Java 7 非常感兴趣（出于我自己的编码原因）。但是，我们的用户对延迟非常敏感（一切都需要亚毫秒）。我在 3 个不同的 JVM 之间做了一个简单的性能比较测试，发现 Java 7 的速度要慢得多。测试通过我们的应用程序推送了一些简单的消息。此测试是低负载、负载量测试，每隔几秒推送一条消息。结果是（以微秒为单位）：

 - Hotspot 6 (build 24): msgs= 23 avg= 902 
 - JRockit 6 (R28 b 29): msgs= 23 avg= 481 
 - Hotspot 7 (build 04): msgs= 34 avg=1130

Oracle 的策略是从 Java 7 开始合并 JRockit 和 Hotspot（所以 JRockit 6 是最后一个可用的）。有谁知道为什么性能差这么多？（需要注意的一点是，代码是在 Java 1.6 下编译的。不确定这是否能解释它......）

更新：我投票结束我自己的问题，因为我可以从评论中看到，我真的无法传达足够的信息来使这个问题成为一个建设性的问题。感谢所有评论的人。

更新：经过更多反馈后，我想我会提供更多信息。测试总是在重新开始之后。每个测试的所有因素都相同。唯一改变的是 JVM。多次重复测试给出一致的结果。在任何测试迭代中都没有发生 GC。

下面是其中一个测试运行的图形值。对于 JRockit 和 Hotspot 7，第一个延迟值被丢弃了。JRockit 具有巨大的初始价值，但随后很快优化并趋于均值。Hotspot 7 需要更长的时间来优化，并且永远不会下降到像 JRockit 这样低的平均值。每个数据点代表从 TCP/IP 套接字读取消息、运行业务逻辑以及在另一个套接字上写入消息的微秒。每条消息都是相同的，并且没有为任何消息输入新的代码路径。

JRockit 6 与热点 7

4

2 回答 2

10

JRockit 是它自己的（纯 C）代码库，不同于 OpenJDK。它包含不同的垃圾收集器和完全不同的 JIT 编译器。BEA 拥有时的一大盈利点是低延迟 GC，它非常先进，即使在非商业变体中也是如此。JRockit 作为一个洁净室虚拟机实现已经花费了大量时间。正如评论中所说，合并不如在 HotSpot 代码库中重新实现内容那么重要。这远不是一个快速的过程，而且有些东西根本不会到达那里，至少在它们的 JRockit 形式中不会。可以这么说，如果没有在边缘放置一些文件，拼图就不容易安装。JDK7 Hotspot，将擅长其他事情，或类似系统的不同版本，但这可能会弥补您损失的一些性能。

如果您有兴趣了解有关 JRockit（或任何 JVM）内部的更多信息，强烈推荐阅读“Oracle JRockit 权威指南”一书。完全披露，我可能每本获得约 2 美元的税前版税，并将用它来购买浓缩咖啡。:)

于 2012-06-12T13:14:45.663 回答
5

这个问题的主旨是，在所有其他条件相同（包括 JVM 参数）的情况下，为什么相同的 Java 代码 JAR 使用 Hotspot 7 JVM 比使用 JRockit 6 和 Hotspot 6 运行得慢得多。

这引起了一些关注时间是否正确完成的回应（显然是由于人们怀疑JVM之间真的会产生如此不同的结果）。基于大量测试，我认为测量结果是正确的，这是毫无疑问的。

我认为可能的潜在答案是：

  • Java 7 JVM 运行在 Java 6 下编译的代码的速度不如在 Java 7 下编译的相同代码快
  • Java 7 需要新的 JVM 参数才能以最优化的模式运行
  • 其他人已经将 Java 7 与 JRockit 6 进行了基准测试，并看到了与我相同的结果

所以事实是，新的 Java 7 JVM 行为与我们的应用程序非常不同，所有其他条件都相同。唯一的解决办法是针对 Java 7 VM 分析代码，以发现代码中的慢点在哪里。（也许到那时，Java 6 JVM 和 Java 7 JVM 之间的实际区别是什么/现在就很清楚了）。

感谢大家的评论，并很抱歉我无法提供足够的细节来进行清晰的分析/解决。

于 2012-06-07T20:20:21.753 回答