JVM系列第2講：Java 虛擬機器的歷史
說起 Java 虛擬機器，許多人就會將其與 HotSpot 虛擬機器等同看待。但實際上 Java 虛擬機器除了 HotSpot 之外，還有 Sun Classic VM、Exact VM、BEA JRocketit、IBM J9 等等。今天我們就來簡單回顧下 Java 虛擬機器的發展歷史。
虛擬機器始祖：Sun Classic
在 1996 年 1 月 23 日，Sun 釋出 JDK 1.0，其中自帶的虛擬機器就是 Classic VM。但這款虛擬機器有個特點，即只能使用純直譯器的方式來執行 Java 程式碼，如果要使用 JIT 編譯器那就必須使用外掛。
tips: 執行程式碼可以分為編譯執行和解釋執行。解釋執行指的是邊解釋邊執行程式碼。編譯執行指的是先編譯，後執行。
但如果外掛了 JIT 編譯器，那麼 JIT 編譯器就完全替代了虛擬機器的執行系統，直譯器便不再工作了。簡單地說，在 Sun Classic 虛擬機器中，直譯器與編譯器無法共同存在。
而且即使使用了外掛 JIT 編譯器，Sun Classic 虛擬機器的執行速度也快不起來。因為直譯器無法和編譯器配合工作，虛擬機器無法判斷哪個方法是使用頻率高，所以它只能對每個方法都進行編譯。這就導致了虛擬機器只能採取相對簡單的優化技術，無法進行耗時稍微較高的優化技術。因為如果對所有程式碼都採用耗時高的優化技術，那麼編譯時間會慢得無法接受。
雖然 Sun Classic 虛擬機器有這樣那樣的問題，但其生命力還是非常旺盛的。在 JDK 1.3 之前，其一直是 JDK 的預設虛擬機器。而在 JDK 1.3 時，HotSpot 成為預設虛擬機器，其作為備用虛擬機器存在。到了 JDK 1.4 時，其正式退出歷史舞臺。可以說 Sun Classic 還是存在了將近四年的時間，但另外一個虛擬機器可就沒有那麼好的運氣了。
無疾而終：Sun Exact VM
在 Sun Classic 釋出後，Sun 的虛擬機器團隊在 JDK 1.2 時 釋出了一款名為 Exact VM 的虛擬機器，嘗試解決 Classic VM 遇到的所有問題。它的執行系統解決了 Classic VM 存在的直譯器和編譯器無法同時工作的問題，還具備了一些現代高效能處理器的特性，如：兩級即時編譯等。
除此之外，Exact VM 還改進了虛擬機器的物件查詢方式。在 Classic VM 中，如果要查詢一個物件，那麼需要通過控制代碼（類似指標）來查詢。如果需要查詢一個物件，那麼需要通過其構建成的控制代碼樹一層層尋找。但在 Exact VM 中使用了準確式記憶體管理（Exact Memory Management），即虛擬機器可以知道記憶體中某個位置的資料具體是什麼型別，這樣就減少了查詢的的開銷，提升執行效能。
但可惜的是，雖然 ExactVM 釋出了，但一直到它退出時，其都沒有真正被大規模使用過。在 JDK 1.2 其釋出時，Exact VM 推出，但Sun Classic VM 依然作為預設的 Java 虛擬機器。在 JDK 1.3 釋出時，推出虛擬機器 HotSpot VM 作為預設虛擬機器，而 Sun Classic VM 作為備用虛擬機器。
武林盟主：Sun HotSpot VM
HotSpot VM 可以說是使用最為廣泛的 Java 虛擬機器，幾乎所有的 Java 虛擬機器都知道它。但實際上，這個虛擬機器並不是由 Sun 公司原生開發的，而是由一個叫 Longview Technologies 公司開發的。而 Sun 公司注意到了這款虛擬機器在 JIT 編譯上的許多優秀成果，於 1997 年收購了 Longview Technologies 公司，從而獲得了 HotSpot VM。
要說 HotSpot 不僅僅有前面說到兩款虛擬機器的優點（如：準確式記憶體管理），也有許多自己的新技術，例如：熱點探測技術。熱點探測技術指的是通過執行計數器找出最具優化價值的程式碼，然後通知 JIT 編譯器以方法為單位進行深度優化編譯。但其實 Exact VM 中也有類似的技術，Sun 公司內部還因此大吵了一架，但最終還是選擇了 HotSpot 作為預設的虛擬機器，其中的緣由不得而知。
總的來說，從 2000 年 JDK 1.3 釋出，HotSpot VM 作為預設的虛擬機器開始登上歷史舞臺。到現在 2018 年，18 年時間過去了，其依然是我們最常用的虛擬機器，可見 Sun HotSpot VM 的生命力之頑強。
百家爭鳴：BEA JRockit / IBM J9 VM
前面說的都是 Sun 公司推出的虛擬機器，但除了 Sun 公司之外，其他組織、公司也研發過不少的虛擬機器實現，其中最著名的要算 BEA 公司的 BEA JRockit 和 IBM 公司的 J9 VM 了。
BEA 公司的 JRockit 是一款專注於伺服器硬體和服務端應用場景的虛擬機器，其針對服務端場景做了大量的優化，因此其不太關注程式啟動速度。JRockit 虛擬機器內部不包含直譯器實現，全部程式碼都靠即時編譯器編譯後執行。此外，其提供的 MissionControl 服務套件也十分強大。
IBM 公司的 J9 VM 則是一款比較通用的虛擬機器，其定位應用於從服務端到桌面應用再到嵌入式的多用途虛擬機器。IBM 公司開發 J9 VM 的目的是將其作為 IBM 公司各種 Java 產品的執行平臺。
武林外傳：那些無名虛擬機器
從 Sun Classic、Sun Exact VM、Sun HotSpot VM，再到 BEA JRockit、IBM J9 VM，這幾個虛擬機器可以說是虛擬機器的正史了，是每個 Java 程式設計師應該瞭解的。但在這之外，其實還有各種各樣的虛擬機器存在。
例如效能最強悍的並不是上面所說的虛擬機器，而是名為 Azul VM 和 BEA Liquid VM 的專用商業及虛擬機器。這些虛擬機器只執行在特定硬體平臺，因此要求比較高。但其效能也是非常強悍的。其可以管理至少數十個 CPU 和數百 GB 的記憶體資源，還提供在巨大記憶體範圍內實現可控 GC 時間的垃圾收集器等等。
此外還有許許多多其他的虛擬機器存在，例如：Apache Harmony、Google Android Dalvik VM、Mircosoft JVM 等等。
最後的贏家：Oracle
看了這麼些歷史，似乎都是在說 Sun公司釋出的虛擬機器，與 Oracle 似乎沒有什麼關係。但在 2010 年，Oracle 公司收購了 Sun 公司，這樣 Oracle 就擁有了 HotSpot VM。再加上其在 2008 年收購 BEA 公司獲得的 JRocket VM，Oracle 公司就擁有了地球上最優秀的兩款虛擬機器。
對於虛擬機器未來的規劃，Oracle 宣佈會將 JRockit 的優秀特性整合到 HotSpot VM 中，例如移植 JRockit 的垃圾回收器和 MissionControl 服務。
附錄：Java 虛擬機器歷史
JDK 版本升級不僅僅體現在語言和功能特性上，還包括了其編譯和執行的 Java 虛擬機器的升級。
- 1996 年，JDK 1.0 釋出時，提供了純解釋執行的 Java 虛擬機器實現：Sun Classic VM。
- 1997 年，JDK 1.1 釋出時，虛擬機器沒有做變更，依然使用 Sun Classic VM 作為預設的虛擬機器。
- 1998 年，JDK 1.2 釋出時，提供了執行在 Solaris 平臺的 Exact VM 虛擬機器，但此時還是用 Sun Classic VM 作為預設的 Java 虛擬機器。
- 2000 年，JDK1.3 釋出，預設的 Java 虛擬機器由 Sun Classic VM 改為 Sun HotSopt VM，而 Sun Classic VM 則作為備用虛擬機器。
- 2002 年，JDK 1.4 釋出，Sun Classic VM 退出商用虛擬機器舞臺，直接使用 Sun HotSpot VM 作為預設虛擬機器一直到現在。
參考資料
JVM系列文章目錄
如果只是看，其實無法真正學會知識的。為了幫助大家更好地學習，我建了一個虛擬機器群，專門討論學習 Java 虛擬機器方面的內容，每週針對我所發文章進行討論答疑。如果你有興趣，關注「Java技術精選」公眾號，通過右下角選單「入群交流」加我好友，小助手會拉你入群。