Java虛擬機的起源與構造
<!-- frame contents -->
<!-- /frame contents -->
當我們說到“Java”這個詞的時候，指的是四個相互關聯的概念：Java語言、Java API、Java Class文件格式、Java虛擬機。整個Java體系是基於Java 虛擬機構造的，正因為如此，才能實現Java的安全性和網絡移動性。Java並非是第一個采用“虛擬機”概念的體系，但卻是第一個得到廣泛運用的虛擬機平台。 “虛擬”，是一種隔離物理資源與邏輯資源的手段。Java虛擬機的“虛擬”，則是用來隔離物理機器、底層操作系統與Java語言規范實現的手段。
雖然Java是一種面向對象的語言，我們平時大量使用的，是對象間的多態、組合(Composition)、委派（Delegation）,但當我們討論虛擬機的時候，我們看見的基本概念卻是“棧(Stack)”和“堆(Heap)”。根據馮諾依曼的“存儲計算”模型，所有的代碼都保存在代碼空間中，隨著程序計數器指針的變化進行程序的執行、跳轉。Java虛擬機中沒有寄存器的概念，方法調用是采用“棧”進行的，這是一種安全、簡潔的方法。
Java虛擬機通過類裝載器支持對類的隔離，這也是Java實現安全性的基礎。每個類都具有自己的命名空間，在具有不同安全級別的沙箱中運行，因此不會產生低安全級別的代碼來越權訪問高級別代碼的機會。類裝載器的出現是Java虛擬機與大部分用C實現的虛擬機的顯著不同之處。
Java虛擬機的另外一個顯著特點就是實現了自動的垃圾收集。在往常，寫程序的時候要牢記對象之間的關聯，在每個程序塊中假若申請了對象空間，就必須在出口釋放掉，方法調用往往同時也就是對象的邊界。而自動垃圾收集帶給開發者的最大好處，就是可以非常方便地從整體上把系統的對象組織成一張對象圖，只需往這張圖中添加對象，維護對象之間的關聯，卻不需要自己做復雜的清掃工作。正是有了這種思維單純的對象圖的支持，OR Mapping(關系數據庫與對象映射）技術在最近得以大行其道，設計模式也更輕易被Java群體所接受。
虛擬機的優化
1995年第一代的Java出台之時，其虛擬機執行是依靠“字節碼解釋器（Byte Code Interceptor）”的，也就是說每條指令都由虛擬機來當場解釋執行，這造成速度令人抓狂地緩慢。更有甚者有人開始總結許多的“速度優化經驗”，比如說：“盡量把所有的代碼都放在較大的方法中執行”與“少用接口”等等，這完全與Java語言的設計目的背道而馳，現在看起來是多麼可笑的奇談怪論，當時卻是很多程序員津津樂道的經驗之談。無他，Java本身執行太慢了。Java生命的前十分之三就是如此緩慢地渡過的。
於是，Sun的工程師開始拼命想著提高執行速度。JIT靜態編譯器的出現是在1996年十月，Sun放出了第一個編譯器。JIT編譯器在每段代碼執行前進行編譯，編譯的結果為本地靜態機器碼，執行速度有了質的提高。Symantec公司當時憑借其傲人的JIT編譯器，在整個Java界受到熱烈的追捧。在其後的1998年，Java 1.2發布的時候，附帶了JIT編譯器，從此Java的使用者終於可以拋開上面說的那些希奇的“速度優化經驗”了。
JIT靜態編譯器雖然可以解決一些問題，但是性能仍然和C/C++有很大的差距。對一段程序而言，一名優秀的程序員是如何來改進運行速度的呢？首先，他不會傻到把所有的代碼都來優化，他會觀察、思考到底哪段代碼對整體性能影響最大？然後集中精力來優化這一段代碼。按照經驗，整個程序 10%-20%的代碼，會占據 80%-90%的運行時間。用這種方法，在同樣的時間、付出同樣程度的努力後，這名優秀的程序員使整個程序的性能得到了很大程度的優化。HotSpot引擎，就是模擬人工的這種方法進行優化的。在程序運行的開始，Java代碼仍然解釋執行，但HotSpot引擎開始進行采樣(Profiling)。
根據采樣的結果，決定某段程序是占用較多運行時間的，就認為它是“HotSpot”，它也就是目前程序的瓶頸， 引擎開始啟動一個單獨的線程進行優化。因為不象原始的 JIT編譯器那樣無差別的編譯所有代碼，HotSpot引擎可以集中精力來對HotSpot代碼進行深度優化，這樣這部分代碼執行起來更加迅捷。之前的靜態編譯器只能按照預定的策略進行編譯優化，而HotSpot引擎的優化是基於采樣的結果的，因此這種方法對所有的應用程序都有效。1999年3月27日，Sun放出了第一個HotSpot引擎。在隨後的2000年5月的JDK 1.3中，包含了HotSopt引擎，這也使1.3成了一個具有裡程碑意義的發行版本。到這裡，Java的十年生命，已經過去了一半。
HotSpot代表的是一種動態編譯的技術。對Java這種大量使用委派、組合等面向對象特性的程序來說，動態編譯比起靜態編譯來有顯著的優勢。比如Method Inlining。方法的調用是一個很耗時的操作，假若可以把方法調用直接內嵌到調用者的代碼中，就可以節省大量的時間， 這被稱為“Method Inlining”。因為涉及到類的重載，靜態優化很難確切知道哪些屬性、方法被重載，因此很難對method進行合並，只好在方法內部進行靜態編譯，假若每個方法都很小，靜態優化能起到的作用也就比較小。而動態編譯因為可以完全隨時把握類的重載情況，就可以把相關的方法合並進行深度優化。現代的Java程序，非凡是在設計模式教育得到普及之後，大量使用類的繼續、委派，形成了很多短小的方法，動態編譯的優勢就更加明顯。
