## Sun Classic VM - 世界上第一款商用 `Java` 虛擬機器，`JDK1.4` 已經淘汰。 - 內部只有直譯器，可以自己外掛`JIT`編譯器，但是二者只能使用其一，不能配合工作。 - `hotspot` 內建了該虛擬機器。 直譯器，需要逐行解釋執行，效率低下。譬如：如果迴圈兩千次，迴圈體很大，每次執行都需要解釋執行。 `JIT` 編譯器，除了可以直接全部即時編譯，還可以統計出那些程式碼執行頻率比較高，這部分程式碼就是熱點程式碼，`JIT` 編譯器會將熱點程式碼，提前編譯成為機器指令，放在方法區快取起來，下次執行到的時候，不需要解釋執行，而是直接執行機器指令。（**此時的 Classic VM 還不具備熱點程式碼探測的功能，只會全部提前編譯**）  **即時編譯器的執行效率很高，為什麼不將它全部提前編譯好快取起來呢？** - 全部提前編譯，首次啟動響應速度慢，會有卡頓的感覺，因為編譯需要大量時間。（主要原因） - 快取程式碼，需要放在方法區，佔用記憶體空間，容易溢位。 - 翻譯成為機器指令，則這部分快取的 `CodeCache` 是不能夠直接跨平臺，因為不同環境的機器指令是不大一樣的，只能每次執行前就全部編譯。 ## Exact VM 為解決上一個虛擬機器 `Classic VM` 的問題(直譯器和即時編譯器只能二選一)，`JDK 1.2` 的時候，提出來的虛擬機器。 準確記憶體管理：`Exact Memory Management`，虛擬機器可以知道記憶體中的某一個位置的資料具體是什麼型別。 該虛擬機器已經初步具備了現在高效能虛擬機器的雛形： - 熱點程式碼探測 - 編譯器和直譯器混合工作 遺憾的是，`Exact VM` 只在`Solaris`短暫使用，後面就被 `Hotspot` 代替了。 ## HotSpot VM 三大商用虛擬機器之一。 由小公司 `“Longview Technologies”` 設計，該公司 1997 年被 `Sun` 收購，`Sun` 2009 年被甲骨文收購。 `JDK 1.3 HotSpot` 成為預設虛擬機器，目前仍是，（`JRockit`和`J9`都沒有方法區），`Hotspot`在伺服器，桌面，移動端，嵌入式等都有應用。 `HotSpot` 名稱來源主要是**熱點程式碼探測技術**： - 通過計數器找到最具有編譯價值的程式碼，觸發即時編譯和棧上替換。 - 編譯器和直譯器協同工作，可以在響應時間和最佳執行效能中取得平衡。直譯器負責是啟動時間，而編譯器主要是針對執行效率。 ## JRockit 三大商用虛擬機器之一。 `BEA` 公司研發的，2008年，`BEA` 公司被 `Oracle` 收購，`Oracle` 在`JDK8` 中，在 Hotspot 的基礎上，整合了 `JRockit` 的優秀特性。 - 專注於服務端應用，不太關注啟動速度，**內部不包含直譯器實現**，全部靠即時編譯器編譯後執行。 - 號稱世界上最快的虛擬機器，執行效能強勁。 - 針對延遲敏感的應用也有解決方案 `“JRockit Real Time”`。 ## J9 `J9`是三大商用虛擬機器之一,全稱`IBM Technology for Java Virtual Machine`，簡稱 `IT4J`，內部稱`“J9”`。 定位和 `HotSpot` 差不多，號稱世界上最快（在自己`IBM`的機器上最快）。 `2007` 年，`IBM` 釋出了 `J9 VM`，命名`OpenJ9`，交給 `Eclipse` 基金會管理。 ## KVM和CDC/CLDC Hotspot - `Oracle` 在 `Java ME` 產品線上的兩款虛擬機器：`CDC/CLDC Hotspot Implementation VM` - `KVM` 是 `CLDC-HI` 早期產品 - 主要是低端的移動端，簡單，輕量，高度可移植 - 智慧控制器，感測器 - 老人手機，功能機 ## Azul VM 是與特定的硬體平臺繫結，軟硬體結合的專用的虛擬機器，高效能`Java`虛擬機器中的戰鬥機。 `Azul VM` 是 `Azul System` 公司在 `Hotspot` 基礎上進行大量改進，執行在自家專用硬體 `Vega` 系統上的 Java 虛擬機器。 每一個 `Azul VM` 可以管理至少數十個 `CPU` 和數百 `GB` 的記憶體，而且可以在**巨大記憶體範圍內實現可控的GC時間**的垃圾收集器。 2010 年後，`Azul System` 釋出了通用平臺的 `Zing` 虛擬機器。 ## BEA Liquid VM 高效能 `Java` 虛擬機器中的戰鬥機，`BEA`公司開發，執行在自己的`Hypervisor`系統上。 `Liquid VM` 不需要作業系統的支援，可以說本身已經實現了一個專用的作業系統的必要功能，比如執行緒排程，檔案系統，網路支援等。`JRockit`停止開發，`Liquid VM` 研發也停止了。 ## Apache Harmony `Apache` 曾經推出過 `JDK 1.5`, `1.6` 相容的 `Java` 執行平臺 `Apache Harmony`。 由 `IBM` 和 `Intel` 聯合開發，但是 `OpenJDK` 壓制，並且 `Sun` 拒絕給予 `JCP` 認證，2011 年退役，其中 `Java` 類庫程式碼吸納進入 `Android SDK`中。 ## Microsoft VM 微軟推出的，在 `IE3` 中支援 `Java Applets`，但是 `Sun`公司 `1997`年指控微軟侵權，後續微軟抹去了 `Microsoft VM`。 ## Taobao JVM 由阿里推出，基於`OpenJDK Hotspot Vm`，改造，深度定製一款高效能虛擬機器。 - 創新的 `GCIH（GC invisible heap）`技術，實現了 `off-heap`，將生命週期較長的 `Java`物件從`heap`中移動到 `heap` 之外，並且`GC`不能管理 `GCIH` 內部的 `Java` 物件，降低了 `GC` 的回收頻率和提高`GC`的回收效率。 - `GCIH` 中的物件可以多個`Java`虛擬機器程序之間共享。 - 使用`crc32`指令實現`JVM intrinsic` 降低`JNI`的呼叫開銷。 - `PMU hardware` 的`Java profiling tool` 和診斷協助功能 - 針對大資料場景的`ZenGC` 缺點：硬體嚴重依賴`Intel`的`cpu`，損失相容性。 ## Dalvik VM - 谷歌開發，應用於`Android`系統，並且在`Android 2.2`中提供了`JIT`。只能稱虛擬機器，而不是`“Java虛擬機器”`，沒有遵循`Java`虛擬機器規範。 - 不能直接執行`Java`的`class`檔案。 - 基於暫存器架構，而不是棧的架構。 - 執行的是編譯以後的`dex（dalvik Executale）`檔案，執行效率比較高。`dex`檔案可以通過`Class`檔案轉化而來，使用`Java`語法編寫應用程式，可以直接使用大部分`Java API`。 - `Android 5.0` 使用提前編譯（`Ahead of Time Compilation`,`AOT`）的`ART VM` 替換`Dalvik VM`。 PS：`Android`檔案`.apk`修改檔案字尾為`.zip`,解壓之後就是很多檔案,當然也包括`.dex`檔案。 ## Graal VM 理念：`“Run Program Faster Anywhere”`。 - 在`Hotspot VM`基礎上增強，跨語言全棧虛擬機器，可以作為任何語言的執行平臺。 - 支援不同語言混用介面和物件 - 原理是將這些語言的原始碼或者中間格式，通過直譯器轉化成為一種`Graal VM`接受的中間格式。 - 在執行時能夠進行即時編譯優化，獲得更優秀的執行效率。 最後：具體`JVM`的記憶體結構，取決於其實現，不同產商或者同一個產商的不同版本，都可能存在一定的差異。一般我們說的，是指`Hotspot`虛擬機器。 **【作者簡介】**： 秦懷，公眾號【**秦懷雜貨店**】作者，技術之路不在一時，山高水長，縱使緩慢，馳而不息。個人寫作方向：Java原始碼解析，JDBC，Mybatis，Spring，redis，分散式，劍指Offer，LeetCode等，認真寫好每一篇文章，不喜歡標題黨，不喜歡花裡胡哨，大多寫系列文章，不能保證我寫的都完全正確，但是我保證所寫的均經過實踐或者查詢資料。遺漏或者錯誤之處，還望指正。 [2020年我寫了什麼？](http://aphysia.cn/archives/2020) [開源程式設計筆記](https://damaer.github.io/Coding/#/) 平日時間寶貴，只能使用晚上以及週末時間學習寫作，關注我，我們一起成