JVM筆記 -- JVM經歷了什麼?
阿新 • • 發佈:2021-03-11
## Sun Classic VM
- 世界上第一款商用 `Java` 虛擬機器,`JDK1.4` 已經淘汰。
- 內部只有直譯器,可以自己外掛`JIT`編譯器,但是二者只能使用其一,不能配合工作。
- `hotspot` 內建了該虛擬機器。
直譯器,需要逐行解釋執行,效率低下。譬如:如果迴圈兩千次,迴圈體很大,每次執行都需要解釋執行。
`JIT` 編譯器,除了可以直接全部即時編譯,還可以統計出那些程式碼執行頻率比較高,這部分程式碼就是熱點程式碼,`JIT` 編譯器會將熱點程式碼,提前編譯成為機器指令,放在方法區快取起來,下次執行到的時候,不需要解釋執行,而是直接執行機器指令。(**此時的 Classic VM 還不具備熱點程式碼探測的功能,只會全部提前編譯**)
![](https://markdownpicture.oss-cn-qingdao.aliyuncs.com/20210216012906.png)
**即時編譯器的執行效率很高,為什麼不將它全部提前編譯好快取起來呢?**
- 全部提前編譯,首次啟動響應速度慢,會有卡頓的感覺,因為編譯需要大量時間。(主要原因)
- 快取程式碼,需要放在方法區,佔用記憶體空間,容易溢位。
- 翻譯成為機器指令,則這部分快取的 `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/#/)
平日時間寶貴,只能使用晚上以及週末時間學習寫作,關注我,我們一起成