JVM 优点与缺点的深入分析

长平狐 发布于 2013/01/06 11:17
阅读 68
收藏 0

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

Java本来是一个简单独一的语言,但是Sun在长期运营Java的过程中出现了很多错误,比如将语言与runtime合用一个名字,从而使得用户在识别JVM语言项目如JythonJRuby时难以从思想上隔离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,从中可以得到回收事件发生的时间、数量以及花费的时间,这可以让我们获悉垃圾回收器处理工作负载的好坏状况:

[GC 16000K->3727K(82496K), 0.0396636 secs]
[Full GC 13021K->5802K(82496K), 0.1468975 secs]
[GC 21802K->9769K(82496K), 0.0292348 secs]
[GC 25769K->12535K(82496K), 0.0243674 secs]
[GC 28535K->13136K(82496K), 0.0169928 secs]
[GC 29136K->15498K(82496K), 0.0213308 secs]
[GC 31498K->16911K(82496K), 0.0213301 secs]
[GC 32911K->19413K(82496K), 0.0186457 secs]
[GC 35413K->20207K(82496K), 0.0146396 secs]

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

第二个是通过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的发展做太大的贡献。




英文原文: J is for JVM: Why the ‘J’ in JRuby?



原文链接:http://blog.csdn.net/sunboy_2050/article/details/7536773
加载中
返回顶部
顶部