JVM 优点与缺点的深入分析

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

　　1、缺点

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

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

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

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

　　2、优点：

　　HotSpot（Java 虚拟机）

　 　对于初学者来说，尽管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的一大利器。

　　3、垃圾回收Garbage Collection （GC）

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

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

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

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

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

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

　　4、JVM特性

　　1）移植性

　　无论是GC还是Hotspot都可以用在任何Java可用的地方。比方说，JRuby可以运行在其他平台 上，Rails应用就可以运行在IBM主机上的JRuby上，而且这台IBM主机运行的是CP/CMS。实际上，由于Java和OpenJDK项目的开 源，我们正在看到越来越多的平台的衍生，因此JVM的移植性也将越来越棒。

　　2）成熟

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

　　3）覆盖面

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

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

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

　　5、总结

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