Java虛擬機的起源與構造

　　當我們說到“Java”這個詞的時候，指的是四個相互關聯(lián)的概念：Java語言、Java API、Java Class文件格式、Java虛擬機。整個Java體系是基于Java 虛擬機構造的，正因為如此，才能實現(xiàn)Java的安全性和網(wǎng)絡移動性。Java并非是第一個采用“虛擬機”概念的體系，但卻是第一個得到廣泛運用的虛擬機平臺。 “虛擬”，是一種隔離物理資源與邏輯資源的手段。Java虛擬機的“虛擬”，則是用來隔離物理機器、底層操作系統(tǒng)與Java語言規(guī)范實現(xiàn)的手段。

　　雖然Java是一種面向對象的語言，我們平時大量使用的，是對象間的多態(tài)、組合(Composition)、委派（Delegation）,但當我們討論虛擬機的時候，我們看見的基本概念卻是“棧(Stack)”和“堆(Heap)”。根據(jù)馮諾依曼的“存儲計算”模型，所有的代碼都保存在代碼空間中，隨著程序計數(shù)器指針的變化進行程序的執(zhí)行、跳轉。Java虛擬機中沒有寄存器的概念，方法調用是采用“?！边M行的，這是一種安全、簡潔的方法。

　　Java虛擬機通過類裝載器支持對類的隔離，這也是Java實現(xiàn)安全性的基礎。每個類都具有自己的命名空間，在具有不同安全級別的沙箱中運行，因此不會產生低安全級別的代碼來越權訪問高級別代碼的機會。類裝載器的出現(xiàn)是Java虛擬機與大部分用C實現(xiàn)的虛擬機的顯著不同之處。

　　Java虛擬機的另外一個顯著特點就是實現(xiàn)了自動的垃圾收集。在往常，寫程序的時候要牢記對象之間的關聯(lián)，在每個程序塊中假若申請了對象空間，就必須在出口釋放掉，方法調用往往同時也就是對象的邊界。而自動垃圾收集帶給開發(fā)者的最大好處，就是可以非常方便地從整體上把系統(tǒng)的對象組織成一張對象圖，只需往這張圖中添加對象，維護對象之間的關聯(lián)，卻不需要自己做復雜的清掃工作。正是有了這種思維單純的對象圖的支持，OR Mapping(關系數(shù)據(jù)庫與對象映射）技術在最近得以大行其道，設計模式也更容易被Java群體所接受。
　　虛擬機的優(yōu)化

　　1995年第一代的Java出臺之時，其虛擬機執(zhí)行是依靠“字節(jié)碼解釋器（Byte Code Interceptor）”的，也就是說每條指令都由虛擬機來當場解釋執(zhí)行，這造成速度令人抓狂地緩慢。更有甚者有人開始總結許多的“速度優(yōu)化經(jīng)驗”，比如說：“盡量把所有的代碼都放在較大的方法中執(zhí)行”與“少用接口”等等，這完全與Java語言的設計目的背道而馳，現(xiàn)在看起來是多么可笑的奇談怪論，當時卻是很多程序員津津樂道的經(jīng)驗之談。無他，Java本身執(zhí)行太慢了。Java生命的前十分之三就是如此緩慢地渡過的。

　　于是，Sun的工程師開始拼命想著提高執(zhí)行速度。JIT靜態(tài)編譯器的出現(xiàn)是在1996年十月，Sun放出了第一個編譯器。JIT編譯器在每段代碼執(zhí)行前進行編譯，編譯的結果為本地靜態(tài)機器碼，執(zhí)行速度有了質的提高。Symantec公司當時憑借其傲人的JIT編譯器，在整個Java界受到熱烈的追捧。在其后的1998年，Java 1.2發(fā)布的時候，附帶了JIT編譯器，從此Java的使用者終于可以拋開上面說的那些奇怪的“速度優(yōu)化經(jīng)驗”了。

　　JIT靜態(tài)編譯器雖然可以解決一些問題，但是性能仍然和C/C++有很大的差距。對一段程序而言，一名優(yōu)秀的程序員是如何來改進運行速度的呢？首先，他不會傻到把所有的代碼都來優(yōu)化，他會觀察、思考到底哪段代碼對整體性能影響最大？然后集中精力來優(yōu)化這一段代碼。按照經(jīng)驗，整個程序 10%-20%的代碼，會占據(jù) 80%-90%的運行時間。用這種方法，在同樣的時間、付出同樣程度的努力后，這名優(yōu)秀的程序員使整個程序的性能得到了很大程度的優(yōu)化。HotSpot引擎，就是模仿人工的這種方法進行優(yōu)化的。在程序運行的開始，Java代碼仍然解釋執(zhí)行，但HotSpot引擎開始進行采樣(Profiling)。

　　根據(jù)采樣的結果，決定某段程序是占用較多運行時間的，就認為它是“HotSpot”，它也就是目前程序的瓶頸， 引擎開始啟動一個單獨的線程進行優(yōu)化。因為不象原始的 JIT編譯器那樣無差別的編譯所有代碼，HotSpot引擎可以集中精力來對HotSpot代碼進行深度優(yōu)化，這樣這部分代碼執(zhí)行起來更加迅捷。之前的靜態(tài)編譯器只能按照預定的策略進行編譯優(yōu)化，而HotSpot引擎的優(yōu)化是基于采樣的結果的，因此這種方法對所有的應用程序都有效。1999年3月27日，Sun放出了第一個HotSpot引擎。在隨后的2000年5月的JDK 1.3中，包含了HotSopt引擎，這也使1.3成了一個具有里程碑意義的發(fā)行版本。到這里，Java的十年生命，已經(jīng)過去了一半。

　　HotSpot代表的是一種動態(tài)編譯的技術。對Java這種大量使用委派、組合等面向對象特性的程序來說，動態(tài)編譯比起靜態(tài)編譯來有顯著的優(yōu)勢。比如Method Inlining。方法的調用是一個很耗時的操作，假若可以把方法調用直接內嵌到調用者的代碼中，就可以節(jié)省大量的時間， 這被稱為“Method Inlining”。因為涉及到類的重載，靜態(tài)優(yōu)化很難確切知道哪些屬性、方法被重載，因此很難對method進行合并，只好在方法內部進行靜態(tài)編譯，假若每個方法都很小，靜態(tài)優(yōu)化能起到的作用也就比較小。而動態(tài)編譯因為可以完全隨時掌握類的重載情況，就可以把相關的方法合并進行深度優(yōu)化?，F(xiàn)代的Java程序，特別是在設計模式教育得到普及之后，大量使用類的繼承、委派，形成了很多短小的方法，動態(tài)編譯的優(yōu)勢就更加明顯。

　　自從出現(xiàn)了HotSpot之后，整個Java界為之一振。

　　最近的五年，就是繼續(xù)優(yōu)化的五年。繼續(xù)進行優(yōu)化的方法有幾條路，一是研究新的采樣算法。因為采樣關系到不同的優(yōu)化策略，會對整體性能有比較大的影響。二是研究深度優(yōu)化的方法。三是研究垃圾收集的算法。垃圾收集會帶來程序短暫的停頓，這會帶來負面的用戶體驗。于是，如何提高垃圾收集的效率，減少延遲，出現(xiàn)了五花八門的算法，比如漸進式收集、火車算法等。在多處理器的時候，如何利用多處理器進行并行收集也是研究的一個熱點。這方面，BEA的JRocket走在了前面。

　　現(xiàn)實生活中的虛擬機

　　最后，讓我們來盤點一下目前市面上可見的各個虛擬機。

　　首先要提到的，毫無疑問是Sun的虛擬機。作為大眾心目中的“官方實現(xiàn)”，Sun擁有最大的用戶群，并且擁有“兼容基準”的地位，其他虛擬機都必須要考慮和Sun虛擬機的兼容性問題。比如 JRocket就會在某些特殊情況下表現(xiàn)出和Sun不同的特性，可能對程序運行有影響。不過Sun也的確沒有讓廣大用戶失望，雖然在早期性能比不上Symantec,后來在1.2 的時候性能又被IBM超越，但Sun一直在努力革新，特別是 1.4.2之后，性能有了長足的進步。雖然JDK 1.5的虛擬機在性能上沒有什么提高，但是增強了穩(wěn)定性，據(jù)說修改了8000處bug，真是讓人汗流不止。原來我們在1.4.2下面一直在享受這么多bug啊。

　　其次是老牌勁旅IBM。IBM的JDK在1.3的時代創(chuàng)下了最好的性能記錄，從此樹立了高端形象。特別是在其WebSphere產品中得到了很好的評價。其JDK也是最早支持64bit的JDK之一。到了現(xiàn)在，IBM JDK在高端仍然是和BEA可以一拼的。

　　然后是后起之秀，BEA的JRocket。說到BEA突然在JVM領域一夜之間異軍突起，多少讓人有些瞠目，不過它采取的戰(zhàn)略特別簡單：自己沒有，索性花錢買了在此領域深有研究的JRocket，在前面加上BEA的標志就可以了。JRocket瞄準高端服務器市場，在多處理器環(huán)境下有不俗的表現(xiàn)。

　　除此之外，還有幾個開放源代碼的JVM值得一提。首先就是大名鼎鼎的JikesRVM。說起其大名，大多數(shù)人都知道Jikes編譯器是 IBM開發(fā)的，效率比同等的javac編譯器高得多，很多開發(fā)者都使用Jikes編譯器來取代javac。而JikesRVM則是IBM開源出來的一整套虛擬機技術，包含了JIT，GC的完整實現(xiàn)，在其網(wǎng)站上也有眾多的論文，實在是想要深入研究JVM者的絕佳資源(http://jikesrvm.sourceforge.net)。

　　Kaffe是一個老牌的JVM,不過現(xiàn)在已經(jīng)很少聽到了。作者撰寫此文時，www.kaffe.org網(wǎng)站已經(jīng)沒有響應，也不知道現(xiàn)在的情況如何了。

　　GNU則有兩個計劃：GCJ和GNU classpath。GNU classpath是一個底層實現(xiàn)，而GCJ是支持java的預編譯器。

　　結束語

　　時光流轉，轟轟烈烈的Java虛擬機性能爭論仿佛還在耳邊回響，現(xiàn)在新的爭論卻已經(jīng)是“Java的性能是否已經(jīng)超越C/C++”。

　　Joakim Dahlstedt 是 JRockit 的主要架構設計師之一，他堅持認為，Java絕不是一種速度慢，效率低的語言，JVM 是一個關鍵的組件，確保了系統(tǒng)的部署與運行和開發(fā)一樣快速、輕松。特別是在目前開發(fā)趨勢是采用大量預制的框架時，動態(tài)編譯有可能比C/C++這樣的靜態(tài)優(yōu)化獲得更好的性能。