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

　　本來Java是一個簡單獨(dú)一的語言，但是Sun在長期運(yùn)營Java的過程中出現(xiàn)了很多錯誤,，比如將語言與runtime合用一個名字,，從而使得用戶在識別JVM語言項目如Jython、JRuby時難以從思想上隔離Java,。最主要的是這樣對runtime很不公,，因為Java Virtual Machine (JVM)有很多自己的獨(dú)特之處。

　　缺點(diǎn)

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

　　還有,，當(dāng)我們創(chuàng)建一個Ruby Fixnum時也很麻煩,，我們把這些值用一個Java對象包裝。Ruby的C implementation不過只是傳遞tagged ints,，因為沒有包裝他們就不會符合各種列表,，所以Java 基元（Java primitives）也不會切割它。

　　順便說一下：JVM的啟動時間也挺長,。

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

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

　　Hotspot

　　對于初學(xué)者來說,，盡管Hotspot有些神秘,，但是性能方面它確實(shí)很棒，因為動態(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)行的開始,，Java代碼仍然解釋執(zhí)行，但HotSpot引擎開始進(jìn)行采樣(Profiling),。HotSpot引擎可以集中精力來對HotSpot代碼進(jìn)行深度優(yōu)化,，從而使這部分代碼的執(zhí)行更加迅捷。因此當(dāng)Hotspot優(yōu)化時,，它為優(yōu)化設(shè)立了一層保護(hù)來確保優(yōu)化的基本原理有效；但當(dāng)這層保護(hù)失效時,，優(yōu)化就會很慢,。

　　這里是Hotspot在使用中的一個演示：

查看原圖

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

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

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

　　垃圾回收Garbage Collection (GC)

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

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

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

查看原圖

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

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

查看原圖

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

　　移植性

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

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

　　成熟

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

　　覆蓋面

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

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

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

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