本篇文章是EngineYard公司官方博客在11月底更新的一篇文章，原文標(biāo)題叫做《J is for JVM: Why the ‘J’ in JRuby?》（J是JVM，為什么JRuby要用J？）。EngineYard是一家以Ruby技術(shù)為核心的云計(jì)算服務(wù)供應(yīng)商，而今年在吸納了從Sun脫離的兩位JRuby核心開(kāi)發(fā)者之后，似乎開(kāi)始計(jì)劃將重心轉(zhuǎn)移到JVM平臺(tái)的JRuby上。本文由王玉磊編譯，原譯文標(biāo)題為《深入分析：JVM的優(yōu)點(diǎn)與缺點(diǎn)》。讓我們看看JVM有什么好，吸引了這么多語(yǔ)言去投奔它。

當(dāng)Java最初誕生的時(shí)候，它可以說(shuō)是其他語(yǔ)言的進(jìn)化版。不僅因?yàn)镴ava很簡(jiǎn)單，而且這一進(jìn)化的語(yǔ)言還是一個(gè)可以運(yùn)行第三方硬件字節(jié)碼的虛擬機(jī)。它還是垃圾收集站，從而令存儲(chǔ)管理和內(nèi)核轉(zhuǎn)儲(chǔ)（core dump）不再是麻煩。當(dāng)然還有它相當(dāng)全面的類庫(kù)。雖然它沒(méi)有什么驚世的新性能，但它把許多語(yǔ)言的優(yōu)點(diǎn)基于一身。

本來(lái)Java是一個(gè)簡(jiǎn)單獨(dú)一的語(yǔ)言，但是Sun在長(zhǎng)期運(yùn)營(yíng)Java的過(guò)程中出現(xiàn)了很多錯(cuò)誤，比如將語(yǔ)言與runtime合用一個(gè)名字，從而使得用戶在識(shí)別JVM語(yǔ)言項(xiàng)目如Jython、JRuby時(shí)難以從思想上隔離Java。最主要的是這樣對(duì)runtime很不公，因?yàn)镴ava Virtual Machine (JVM)有很多自己的獨(dú)特之處。

缺點(diǎn)

沒(méi)有一種技術(shù)是完美的，JVM也不例外。如果你工作在一個(gè)沒(méi)有Java語(yǔ)言配置的設(shè)備上，JVM便無(wú)用武之地。JVM為其他語(yǔ)言提供了基礎(chǔ)，但JVM最初不是為這個(gè)理念設(shè)計(jì)的。比如我們作為分配對(duì)象來(lái)維護(hù)我們的堆棧時(shí)，通常我們會(huì)直接操作實(shí)時(shí)堆棧并添加我們維護(hù)所需的其他字段，除此之外再?zèng)]有控制堆棧的更好的方法。

還有，當(dāng)我們創(chuàng)建一個(gè)Ruby Fixnum時(shí)也很麻煩，我們把這些值用一個(gè)Java對(duì)象包裝。Ruby的C implementation不過(guò)只是傳遞tagged ints，因?yàn)闆](méi)有包裝他們就不會(huì)符合各種列表，所以Java 基元（Java primitives）也不會(huì)切割它。

順便說(shuō)一下：JVM的啟動(dòng)時(shí)間也挺長(zhǎng)。

那些為JVM編寫(xiě)高性能代碼的開(kāi)發(fā)者會(huì)覺(jué)得經(jīng)常被JVM的black box特性所折磨，一旦你加載你的字節(jié)碼，你就覺(jué)得像是搖動(dòng)老虎機(jī)的游戲手柄一樣忐忑，不知道結(jié)果如何，black box就是意味著不可知。

優(yōu)點(diǎn)：

Hotspot

對(duì)于初學(xué)者來(lái)說(shuō)，盡管Hotspot有些神秘，但是性能方面它確實(shí)很棒，因?yàn)閯?dòng)態(tài)建模（dynamic profiling）是優(yōu)良性能的捷徑。HotSpot從運(yùn)行應(yīng)用中采樣數(shù)據(jù)，從而可以優(yōu)化代碼，進(jìn)而得到良好性能。它相當(dāng)于以模仿人工的方法進(jìn)行優(yōu)化。在程序運(yùn)行的開(kāi)始，Java代碼仍然解釋執(zhí)行，但HotSpot引擎開(kāi)始進(jìn)行采樣(Profiling)。HotSpot引擎可以集中精力來(lái)對(duì)HotSpot代碼進(jìn)行深度優(yōu)化，從而使這部分代碼的執(zhí)行更加迅捷。因此當(dāng)Hotspot優(yōu)化時(shí)，它為優(yōu)化設(shè)立了一層保護(hù)來(lái)確保優(yōu)化的基本原理有效；但當(dāng)這層保護(hù)失效時(shí)，優(yōu)化就會(huì)很慢。

這里是Hotspot在使用中的一個(gè)演示：

在圖表中我們運(yùn)行了一個(gè)Mandelbrot Generator很多次，然后測(cè)繪它每次生成的時(shí)間。你會(huì)看到JRuby 1.4.0明顯比Ruby 1.8.7以及1.9.2preview2表現(xiàn)更好。如果只看JRuby的起點(diǎn)，會(huì)發(fā)現(xiàn)比1.8.7慢，但當(dāng)Hotspot運(yùn)行后時(shí)間曲線迅速下降。

這里有個(gè)有趣的始建波動(dòng)發(fā)生在循環(huán)6那里：實(shí)際上那是因?yàn)镠otspot的動(dòng)態(tài)反優(yōu)化啟動(dòng)。然后時(shí)間波動(dòng)回到原來(lái)狀態(tài)，優(yōu)化結(jié)束。

Hotspot已經(jīng)被全世界的開(kāi)發(fā)者和擁躉支持了近十年，Java 4, 5, 6之間的提升讓人印象深刻。每一次它的升級(jí)，性能都會(huì)有很多提升，它真是的是JVM的一大利器。

垃圾回收Garbage Collection (GC)

Java開(kāi)發(fā)者花費(fèi)大量時(shí)間來(lái)調(diào)試、測(cè)試、提高他們的VM，單是Garbage Collection的開(kāi)發(fā)和維護(hù)就持續(xù)了15個(gè)年頭，由此可見(jiàn)它的性能！而且JVM發(fā)布了多個(gè)垃圾回收器，所以這樣一來(lái)即使加載的負(fù)荷超過(guò)了JVM中一個(gè)Garbage Collection，JVM也還可以允許你使用其他的Garbage Collection。因此，你可以自己調(diào)整任何你所使用的Garbage Collection，使之符合你的應(yīng)用。

各種各樣的回收站發(fā)揮著不同的作用。它們?nèi)渴菈嚎s過(guò)的，所以不必?fù)?dān)心存儲(chǔ)的問(wèn)題。它們都是增量型的（incremental）以縮短GC停滯的時(shí)間；它們還是分代的（generational），所以短時(shí)對(duì)象（short-lived object）回收得更快。有些是并行的，從而回收工作可以在多個(gè)核上分開(kāi)運(yùn)行；甚至還有同時(shí)發(fā)生的Garbage Collection，這樣就沒(méi)有了停滯時(shí)間。JRuby可以免費(fèi)得到這些，現(xiàn)在的Java 7以及Java 6的u12，甚至還有一個(gè)新的G1回收站。

關(guān)于GC和JVM還有兩個(gè)很巧妙的地方，從中可以獲悉GC運(yùn)行虛擬化和信息的情況。第一個(gè)是-J-verbose:gc flag，從中可以得到回收事件發(fā)生的時(shí)間、數(shù)量以及花費(fèi)的時(shí)間，這可以讓我們獲悉垃圾回收器處理工作負(fù)載的好壞狀況：

你可以記錄這些事件并且計(jì)算出清理垃圾所需的總時(shí)間，還可以計(jì)算出你加載的工作負(fù)荷是否超過(guò)了回收器的能力，這可以幫助改變你的設(shè)計(jì)并通過(guò)調(diào)節(jié)堆棧大小來(lái)適配回收器。

第二個(gè)是通過(guò)jconsole查詢JVM狀況。Jconsole可以從許多角度查看系統(tǒng)，而且有一個(gè)很棒的memory tab來(lái)展示GC的運(yùn)行狀況，如下：

在右下角你可以看到綠色的框格，從中可以看到不同的生成占存儲(chǔ)的多少。比如說(shuō)你看到一個(gè)近乎滿的survivor 生成，那意味著慢的滿GC收集時(shí)刻，那么意思就是說(shuō)這個(gè)應(yīng)用可能不是很健全。

移植性

#T#無(wú)論是GC還是Hotspot都可以用在任何Java可用的地方。比方說(shuō)，JRuby可以運(yùn)行在其他平臺(tái)上，Rails應(yīng)用就可以運(yùn)行在IBM主機(jī)上的JRuby上，而且這臺(tái)IBM主機(jī)運(yùn)行的是CP/CMS。

實(shí)際上，由于Java和OpenJDK項(xiàng)目的開(kāi)源，我們正在看到越來(lái)越多的平臺(tái)的衍生，因此JVM的移植性也將越來(lái)越棒。

成熟

JVM已有超過(guò)15年的歷史，在過(guò)去的這些年里，許多開(kāi)發(fā)者為它做出了許多貢獻(xiàn)，使得它的性能一次又一次地提升，讓JVM變得更加穩(wěn)定、快速和廣泛。

覆蓋面

JRuby和JVM上的其他語(yǔ)言項(xiàng)目已經(jīng)被開(kāi)發(fā)者所承認(rèn)，一個(gè)典型的例子是invokedynamic specification (aka JSR292)。JSR越來(lái)越配合新的語(yǔ)言，JVM已不再是Java一個(gè)人定制規(guī)則。JVM正在構(gòu)建成為類如JRuby等項(xiàng)目的優(yōu)良平臺(tái)。

還有一個(gè)MLVM（multiple language VM）項(xiàng)目，好比是新特性的清算機(jī)構(gòu)，是一個(gè)許多企業(yè)應(yīng)用的開(kāi)發(fā)者試圖添加應(yīng)用的地方，而這些應(yīng)用正是他們想在JVM中看到的。而且JVM開(kāi)發(fā)者互相協(xié)作、彼此影響，無(wú)疑這有利于JVM新特性的誕生。

這些細(xì)節(jié)都可以看到JVM正在關(guān)注開(kāi)發(fā)者的需求，擴(kuò)大他的覆蓋面。

總之，JVM已經(jīng)成為技術(shù)界越來(lái)越穩(wěn)定的產(chǎn)品，Oracle/Sun的合并以及其他可能的商業(yè)鬧劇都不會(huì)影響這一點(diǎn)。許多技術(shù)大鱷級(jí)公司（如Oracle、IBM、HP、SAP）已經(jīng)為編寫(xiě)JVM的中間軟件花了如此多的錢以至于在下個(gè)十年里他們可能不會(huì)再為JVM的發(fā)展做太大的貢獻(xiàn)。