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

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 虛擬機），是較新的Java虛擬機技術，用來代替JIT（just-in-time compilation，及時編譯）技術，可以大大提高Java運行的性能。Java原先是把源代碼編譯為字節碼在虛擬機執行，這樣執行速度較慢。而該技術將常用的部分代碼編譯為本地（原生，native）代碼，這樣顯著提高了性能。

對于初學者來說，盡管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?

from:?http://blog.csdn.net/ithomer/article/details/7536773

總結

以上是生活随笔為你收集整理的JVM 优点与缺点的深入分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。