杀手设施或场景会使另一个JVM成为比Sun JVM更好的选择吗？
对于Java SE，有几个JVM可用于在x86上的生产中运行：
- IBM J9
- Oracle JRockit – http://www.oracle.com/technology/products/jrockit/index.html
- Apache Harmony – http://harmony.apache.org/
- OS X中的一个（如果是Mac）似乎是带有Aqua Swing的Sun.
- OpenJDK的
加上一些在服务器上运行的自定义产品：
- Azul – http://www.azulsystems.com/
- Google App Engine Java – http://code.google.com/intl/da/appengine/docs/java/overview.html
其他平台：
- Sun Solaris JVM – 比x86更好的可伸缩性？
- （编辑）用于Java的GNU编译器 – http://gcc.gnu.org/java/ – 可以在多个平台上编译为本机代码。
Sun JVM与jvisualvm程序具有明显的优势，该程序允许运行时检查运行代码。 是否有任何其他JVM的技术优势可能使其成为开发和/或生产的更好选择？
换句话说，是否有一个杀手级设施或场景可以在另一个JVM中进行任何时间/精力/金钱投入？
（如果它们是一个不错的选择，请另外建议其他JVM）。
JRockit附带JRockit Mission Control，它是一个工具套件，可用于监视JVM和您的应用程序。 你可以在这里下载它，它可以免费用于开发。
Mission Control具有许多缺少VisualVM的function，例如在线内存泄漏检测器，延迟分析器，Eclipse集成，JMX.logging to file。 如果您想将VisualVM与Mission Control进行比较，请参阅发行说明和最新版本的文档 。
IBM J9
这是您可以阅读或听到的关于J9的销售演讲：
IBM已发布了适用于Java 6的SDK。产品二进制文件可用于x86和64位AMD上的Linux，以及适用于32位和64位PPC的AIX。 除了支持Java SE 6平台规范外，新SDK还侧重于Java虚拟机之间的数据共享，增强的诊断信息，操作系统堆栈回溯，更新的jdmpview工具，平台稳定性和性能。
有些人会说IBM SDK除了速度之外还有一些优势，PermGenSpace的使用和扩展要比Sun SDK或GCJ好得多（对于客户端应用程序来说并不是什么大问题，但是繁重的J2EE服务器，尤其是门户服务器，可以确实引起了Sun JDK的胃灼热）。 但是，根据本文比较Sun与IBM JVM GC，结果表明内存性能主要取决于应用程序而不是VM。
因此，虽然IBM JVM以其故障排除function（比Sun的JVM更先进）而闻名，但我并不相信GC级别的差异。
Sun的JVM比IBM更具优势，至少在Solaris：DTrace提供商。 实际上，我一直主要在Solaris上使用Weblogic，因此Sun的JVM一直是自然的选择。
Oracle JRockit
几年前我做了BEA / Oracle JRockit的一些基准测试，它确实是一个快速的虚拟机，它当时支持比Sun的VM更大的堆。 但它有一些稳定性问题，对生产来说并不是很好。 从那以后，情况可能会有所改变。
Apache Harmony
我可能错了，但对我来说，Harmony是由IBM的代码捐赠组成的（好处：社区正在进行维护），我真的不明白为什么我应该考虑Harmony而不是IBM J9。
Apple的JDK
我从来没有使用Mac进行制作，所以我无法回答。 我只记得Apple需要一些时间来捆绑Java 6，我不知道为什么。 这可能不合理，但这让我很怀疑。
OpenJDK的
我知道有些供应商正在为OpenJDK提供生产支持（例如RedHat with RHEL 5.3+，请参阅此博客条目 ），因此它可能是Sun不支持的平台的选项。 但是，除非有人能告诉我是什么让OpenJDK比Sun更好，我想我会在支持的平台上安装Sun JVM。
所以对我来说，选择实际上是：Sun的JVM，除非我要运行一些Websphere的东西，在这种情况下我会选择IBM J9。 但说实话，我从来没有遇到过我无法在Sun的JVM上解决的情况，并且可能有理由（临时）交换到IBM的那个，所以我无法确定故障排除function是否那么好。 但我承认我可能会缺乏对IBM JVM的了解。
一些应用程序，如金融和计算科学，将从十进制浮点的硬件实现中受益匪浅。 IBM推出了一系列处理器（ POWER6 ， z9和z10大型机），这些处理器实现了IEEE 754-2008十进制浮点标准。 最新的IBM JDK可以为BigDecimal使用硬件加速。
允许开发人员轻松利用专用的DFP硬件IBM 适用于Java 6的Developer Kit通过以下内容支持64位DFP BigDecimal类库。 JVM在何时无缝使用DFP硬件 可用于消除对计算昂贵的基于软件的十进制的需求 算术，从而提高应用程序性能。
这是一个非常简单的情况，但是如果你有一个方便的z10大型机并希望在Java中使用它的十进制浮点单元，那么IBM JVM将是比Sun JVM更好的选择。
– Flaviu Cipcigan
您应该关注的典型function/场景是性能和速度。
无论白皮书说什么，最终你需要自己做基准测试。
我偏向于IBM ，因为几年前我在那里工作过。 我没有亲自处理jvm开发，但我记得jvm开发小组的重点是以下几点：
- 专有垃圾收集优化。 这不仅包括更快的GC，还包括更多配置选项，例如服务器和客户端的GC。 这是在Sun提供类似选择之前。
- 使用JNI接口可以更快（x10）本机性能。 当Eclipse / WSAD开始获得牵引力并且swt被大量使用时，这一点尤为重要。 如果您的应用程序使用了很多JNI，那么我认为值得您将IBM jdk与Sun jdk进行对比。
- 稳定性和可靠性。 我认为这只有在您购买IBM的商业支持时才有意义，例如服务层的SLA（WebSphere和db2，集群环境等）。 在这种情况下，只有在您使用jvm时，IBM才会保证其产品的稳定性。
关于OpenJDK ，我建议您查看OpenJDK的这段历史 。 我的理解是OpenJDK 7几乎与Sun的jdk 7完全相同，因此性能很可能是相同的。 主要区别在于许可以及webstart等小型组件。
如果要从数据库中运行java代码（通过存储过程）， Oracle的jvm非常有用。 它包括一些优化，可帮助数据库在此方案中更快地运行。
正如其他人所说，Sun一直在追赶他们的竞争对手。 我认为在1.4天内差异更明显，但今天没有那么多。 关于jvisualvm，其他供应商也提供类似的工具，所以我不认为这是一个问题。
最后，还有一个指标（尽管有点争议）表明这些供应商对其虚拟机的严重程度。 这是他们发布的相关专利数量。 如果您需要说服您的老板，或者您想阅读专利，那可能会有用:)
专利检索： ibm和java – 4559项专利。
专利检索： oracle和java – 323。
不是严格意义上的JVM，但仍然是Java实现： gcj 。 它具有支持许多处理器的优势，因此如果你瞄准其中一个嵌入式处理器，gcj可能是你唯一的选择。 另外，由于它是真正的编译器（不仅仅是JIT），因此可以节省嵌入式目标上JIT编译（内存和周期）的开销。
回到Java 1.4天，我的团队使用IBM JVM来运行在Linux上运行的大容量，基于消息的系统。 我们为什么这样做？ 因为我们对不同的JVM进行了基准测试！ JRockit实际上是最快的，但它偶尔会崩溃，所以生产并不是那么好。
与往常一样，测量它！
几年前（JDK1.4），不同的JVM有不同的优势：
-
IBM JVM能够执行堆转储（以编程方式，在信号上或在OOM上），并且堆根实用程序对于跟踪内存泄漏非常有用（比分析器更少侵入）。 没有其他JVM有这个。
-
JRockit有许多Sun JVM没有的有用选项，并行集合。 它也（更快）（比Sun VM更稳定）。
今天，太阳有这些function，但我相信还有其他function。 速度可以是一个。 另外垃圾收集策略。
如果您正在使用WebLogic，Sun JVM中的一些错误可能会导致WebLogic中的错误。 JRockit中更容易解决这些错误。
据我所知，与Sun的JVM和IBM的JVM的主要区别在于实际的垃圾收集器，IBM的垃圾收集器（s？）比Sun更易配置，并且只考虑商业世界。 此外，IBM的JVM在错误情况下可以说明“我刚崩溃，这是我的堆转储”，这在IBM JVM的主要生存空间中显然非常重要。
因此，假设我没有被骗，我会说在使用依赖于积极或高度可调的垃圾收集的商业软件中执行内存密集型操作时，应该使用IBM的JVM。
根据我自己的经验和面值，我看到了IBM GC设计的简单性。 Sun的各种和新的GC毫无疑问是优秀的，并且在分钟级别提供了大量的调优选项，但即使在一些最活跃的Web应用程序中，我知道处理繁重/积极的新对象并在堆中保留很多缓存我很少即使试图保持足迹低，GC也会超过1％。 当然，我们可以更好地调整它，但收益递减。
在运行IBM JDK的完全相同的应用程序中，我遇到了更多挑战。 尤其是固定群集问题并且必须调整-Xk。
现在我可以提一下IBM和Sun 应该为杀手级JVM实现的十几个项目，但不是我认为的问题范围:)
实时嵌入式系统的增量垃圾收集和非常小的运行时大小是唯一真正重要的事情，可以保证降低稳定性或平台支持。 有一些jvm考虑到这一点，但我现在忘记了它的名字。