本篇文章是EngineYard公司官方博客在11月底更新的一篇文章，原文标题叫做《J is for JVM: Why the ‘J’in JRuby?》(J是JVM，为什么JRuby要用J？)。EngineYard是一家以Ruby技术为核心的云计算服务供应商，而今年在吸纳了从Sun脱离的两位JRuby核心开发者之后，似乎开始计划将重心转移到JVM平台的JRuby上。本文由王玉磊编译，原译文标题为《深入分析：JVM的优点与缺点》。让我们看看JVM有什么好，吸引了这么多语言去投奔它。

　　当Java最初诞生的时候，它可以说是其他语言的进化版。不仅因为Java很简单，而且这一进化的语言还是一个可以运行第三方硬件字节码的虚拟机。它还是垃圾收集站，从而令存储管理和内核转储(core dump)不再是麻烦。当然还有它相当全面的类库。虽然它没有什么惊世的新性能，但它把许多语言的优点基于一身。

　　本来Java是一个简单独一的语言，但是Sun在长期运营Java的过程中出现了很多错误，比如将语言与runtime合用一个名字，从而使得用户在识别JVM语言项目如Jython、JRuby时难以从思想上隔离Java。最主要的是这样对runtime很不公，因为Java Virtual Machine (JVM)有很多自己的独特之处。

　　缺点

　　没有一种技术是完美的，JVM也不例外。如果你工作在一个没有Java语言配置的设备上，JVM便无用武之地。JVM为其他语言提供了基础，但JVM最初不是为这个理念设计的。比如我们作为分配对象来维护我们的堆栈时，通常我们会直接操作实时堆栈并添加我们维护所需的其他字段，除此之外再没有控制堆栈的更好的方法。

　　还有，当我们创建一个Ruby Fixnum时也很麻烦，我们把这些值用一个Java对象包装。Ruby的C implementation不过只是传递tagged ints，因为没有包装他们就不会符合各种列表，所以Java 基元(Java primitives)也不会切割它。

　　顺便说一下：JVM的启动时间也挺长。

　　那些为JVM编写高性能代码的开发者会觉得经常被JVM的black box特性所折磨，一旦你加载你的字节码，你就觉得像是摇动老虎机的游戏手柄一样忐忑，不知道结果如何，black box就是意味着不可知。

　　优点：

　　Hotspot

　　对于初学者来说，尽管Hotspot有些神秘，但是性能方面它确实很棒，因为动态建模(dynamic profiling)是优良性能的捷径。HotSpot从运行应用中采样数据，从而可以优化代码，进而得到良好性能。它相当于以模仿人工的方法进行优化。在程序运行的开始，Java代码仍然解释执行，但HotSpot引擎开始进行采样(Profiling)。HotSpot引擎可以集中精力来对HotSpot代码进行深度优化，从而使这部分代码的执行更加迅捷。因此当Hotspot优化时，它为优化设立了一层保护来确保优化的基本原理有效;但当这层保护失效时，优化就会很慢。

　　这里是Hotspot在使用中的一个演示：

　　在图表中我们运行了一个Mandelbrot Generator很多次，然后测绘它每次生成的时间。你会看到JRuby 1.4.0明显比Ruby 1.8.7以及1.9.2preview2表现更好。如果只看JRuby的起点，会发现比1.8.7慢，但当Hotspot运行后时间曲线迅速下降。

　　这里有个有趣的始建波动发生在循环6那里：实际上那是因为Hotspot的动态反优化启动。然后时间波动回到原来状态，优化结束。

　　Hotspot已经被全世界的开发者和拥趸支持了近十年，Java 4, 5, 6之间的提升让人印象深刻。每一次它的升级，性能都会有很多提升，它真是的是JVM的一大利器。

　　垃圾回收Garbage Collection (GC)

　　Java开发者花费大量时间来调试、测试、提高他们的VM，单是Garbage Collection的开发和维护就持续了15个年头，由此可见它的性能！而且JVM发布了多个垃圾回收器，所以这样一来即使加载的负荷超过了JVM中一个Garbage Collection，JVM也还可以允许你使用其他的Garbage Collection。因此，你可以自己调整任何你所使用的Garbage Collection，使之符合你的应用。

　　各种各样的回收站发挥着不同的作用。它们全部是压缩过的，所以不必担心存储的问题。它们都是增量型的(incremental)以缩短GC停滞的时间;它们还是分代的(generational)，所以短时对象(short-lived object)回收得更快。有些是并行的，从而回收工作可以在多个核上分开运行;甚至还有同时发生的Garbage Collection，这样就没有了停滞时间。JRuby可以免费得到这些，现在的Java 7以及Java 6的u12，甚至还有一个新的G1回收站。

　　关于GC和JVM还有两个很巧妙的地方，从中可以获悉GC运行虚拟化和信息的情况。第一个是-J-verbose:gc flag，从中可以得到回收事件发生的时间、数量以及花费的时间，这可以让我们获悉垃圾回收器处理工作负载的好坏状况：

　　你可以记录这些事件并且计算出清理垃圾所需的总时间，还可以计算出你加载的工作负荷是否超过了回收器的能力，这可以帮助改变你的设计并通过调节堆栈大小来适配回收器。

　　第二个是通过jconsole查询JVM状况。Jconsole可以从许多角度查看系统，而且有一个很棒的memory tab来展示GC的运行状况，如下：

　　在右下角你可以看到绿色的框格，从中可以看到不同的生成占存储的多少。比如说你看到一个近乎满的survivor 生成，那意味着慢的满GC收集时刻，那么意思就是说这个应用可能不是很健全。

　　移植性

　　无论是GC还是Hotspot都可以用在任何Java可用的地方。比方说，JRuby可以运行在其他平台上，Rails应用就可以运行在IBM主机上的JRuby上，而且这台IBM主机运行的是CP/CMS。

　　实际上，由于Java和OpenJDK项目的开源，我们正在看到越来越多的平台的衍生，因此JVM的移植性也将越来越棒。

　　成熟

　　JVM已有超过15年的历史，在过去的这些年里，许多开发者为它做出了许多贡献，使得它的性能一次又一次地提升，让JVM变得更加稳定、快速和广泛。

　　覆盖面

　　JRuby和JVM上的其他语言项目已经被开发者所承认，一个典型的例子是invokedynamic specification (aka JSR292)。JSR越来越配合新的语言，JVM已不再是Java一个人定制规则。JVM正在构建成为类如JRuby等项目的优良平台。

　　还有一个MLVM(multiple language VM)项目，好比是新特性的清算机构，是一个许多企业应用的开发者试图添加应用的地方，而这些应用正是他们想在JVM中看到的。而且JVM开发者互相协作、彼此影响，无疑这有利于JVM新特性的诞生。

　　这些细节都可以看到JVM正在关注开发者的需求，扩大他的覆盖面。

　　总之，JVM已经成为技术界越来越稳定的产品，Oracle/Sun的合并以及其他可能的商业闹剧都不会影响这一点。许多技术大鳄级公司(如Oracle、IBM、HP、SAP)已经为编写JVM的中间软件花了如此多的钱以至于在下个十年里他们可能不会再为JVM的发展做太大的贡献。