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 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 作爲備用虛擬機。

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 的生命力之頑強。

前面說的都是 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 等等。

看了這麼些歷史，似乎都是在說 Sun公司發佈的虛擬機，與 Oracle 似乎沒有什麼關係。但在 2010 年，Oracle 公司收購了
Sun 公司，這樣 Oracle 就擁有了 HotSpot VM。再加上其在 2008 年收購 BEA 公司獲得的 JRocket
VM，Oracle 公司就擁有了地球上最優秀的兩款虛擬機。
對於虛擬機未來的規劃，Oracle 宣佈會將 JRockit 的優秀特性整合到 HotSpot VM 中，例如移植 JRockit
的垃圾回收器和 MissionControl 服務。

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
作爲默認虛擬機一直到現在。