JVM與Java體系結構
前言
作為Java工程師的你曾被傷害過嗎？你是否也遇到過這些問題？
執行著的線上系統突然卡死，系統無法訪問，甚至直接OOMM！
- 想解決線上JVM GC問題，但卻無從下手。
- 新專案上線，對各種JVM引數設定一臉茫然，直接預設吧然後就JJ了
- 每次面試之前都要重新背一遍JVM的一些原理概念性的東西，然而面試官卻經常問你在實際專案中如何調優VM引數，如何解決GC、OOM等問題，一臉懵逼。
大部分Java開發人員，除會在專案中使用到與Java平臺相關的各種高精尖技術，對於Java技術的核心Java虛擬機器瞭解甚少。
一些有一定工作經驗的開發人員，打心眼兒裡覺得SSM、微服務等上層技術才是重點，基礎技術並不重要，這其實是一種本末倒置的“病態”。如果我們把核心類庫的API比做數學公式的話，那麼Java虛擬機器的知識就好比公式的推導過程。
計算機系統體系對我們來說越來越遠，在不瞭解底層實現方式的前提下，通過高階語言很容易編寫程式程式碼。但事實上計算機並不認識高階語言
架構師每天都在思考什麼？
- 應該如何讓我的系統更快？
- 如何避免系統出現瓶頸？
知乎上有條帖子：應該如何看招聘資訊，直通年薪50萬+？
- 參與現有系統的效能優化，重構，保證平臺效能和穩定性
- 根據業務場景和需求，決定技術方向，做技術選型
- 能夠獨立架構和設計海量資料下高併發分散式解決方案，滿足功能和非功能需求
- 解決各類潛在系統風險，核心功能的架構與程式碼編寫
- 分析系統瓶頸，解決各種疑難雜症，效能調優等
為什麼要學習JVM
- 面試的需要（BATJ、TMD，PKQ等面試都愛問）
- 中高階程式設計師必備技能
- 專案管理、調優的需求
- 追求極客的精神
- 比如：垃圾回收演算法、JIT（及時編譯器）、底層原理
Java vs C++
垃圾收集機制為我們打理了很多繁瑣的工作，大大提高了開發的效率，但是，垃圾收集也不是萬能的，懂得JVM內部的記憶體結構、工作機制，是設計高擴充套件性應用和診斷執行時問題的基礎，也是Java工程師進階的必備能力。
C語言需要自己來分配記憶體和回收記憶體，Java全部交給JVM進行分配和回收。
推薦書籍
Java生態圈
Java是目前應用最為廣泛的軟體開發平臺之一。隨著Java以及Java社群的不斷壯大Java 也早已不再是簡簡單單的一門計算機語言了，它更是一個平臺、一種文化、一個社群。
- 作為一個平臺，Java虛擬機器扮演著舉足輕重的作用
- Groovy、Scala、JRuby、Kotlin等都是Java平臺的一部分
- 作為燈種文化，Java幾乎成為了“開源”的代名詞。
- 第三方開源軟體和框架。如Tomcat、Struts，MyBatis，Spring等。
- 就連JDK和JVM自身也有不少開源的實現，如openJDK、Harmony。
- 作為一個社群，Java擁有全世界最多的技術擁護者和開源社群支援，有數不清的論壇和資料。從桌面應用軟體、嵌入式開發到企業級應用、後臺伺服器、中介軟體，都可以看到Java的身影。其應用形式之複雜、參與人數之眾多也令人咋舌。
每個語言都需要轉換成位元組碼檔案，最後轉換的位元組碼檔案都能通過Java虛擬機器進行執行和處理
隨著Java7的正式釋出，Java虛擬機器的設計者們通過JSR-292規範基本實現在Java虛擬機器平臺上執行非Java語言編寫的程式。
Java虛擬機器根本不關心執行在其內部的程式到底是使用何種程式語言編寫的，它只關心“位元組碼”檔案。也就是說Java虛擬機器擁有語言無關性，並不會單純地與Java語言“終身繫結”，只要其他程式語言的編譯結果滿足幷包含Java虛擬機器的內部指令集、符號表以及其他的輔助資訊，它就是一個有效的位元組碼檔案，就能夠被虛擬機器所識別並裝載執行。
位元組碼
我們平時說的java位元組碼，指的是用java語言編譯成的位元組碼。準確的說任何能在jvm平臺上執行的位元組碼格式都是一樣的。所以應該統稱為：jvm位元組碼。
不同的編譯器，可以編譯出相同的位元組碼檔案，位元組碼檔案也可以在不同的JVM上執行。
Java虛擬機器與Java語言並沒有必然的聯絡，它只與特定的二進位制檔案格式—Class檔案格式所關聯，Class檔案中包含了Java虛擬機器指令集（或者稱為位元組碼、Bytecodes）和符號表，還有一些其他輔助資訊。
多語言混合程式設計
Java平臺上的多語言混合程式設計正成為主流，通過特定領域的語言去解決特定領域的問題是當前軟體開發應對日趨複雜的專案需求的一個方向。
試想一下，在一個專案之中，並行處理用clojure語言編寫，展示層使用JRuby/Rails，中間層則是Java，每個應用層都將使用不同的程式語言來完成，而且，介面對每一層的開發者都是透明的，各種語言之間的互動不存在任何困難，就像使用自己語言的原生API一樣方便，因為它們最終都執行在一個虛擬機器之上。
對這些執行於Java虛擬機器之上、Java之外的語言，來自系統級的、底層的支援正在迅速增強，以JSR-292為核心的一系列專案和功能改進（如Da Vinci Machine專案、Nashorn引擎、InvokeDynamic指令、java.lang.invoke包等），推動Java虛擬機器從“Java語言的虛擬機器”向 “多語言虛擬機器”的方向發展。
Java發展的重大事件
- 1990年，在Sun計算機公司中，由Patrick Naughton、MikeSheridan及James Gosling領導的小組Green Team，開發出的新的程式語言，命名為oak，後期命名為Java
- 1995年，Sun正式釋出Java和HotJava產品，Java首次公開亮相。
- 1996年1月23日sun Microsystems釋出了JDK 1.0。
- 1998年，JDK1.2版本釋出。同時，sun釋出了JSP/Servlet、EJB規範，以及將Java分成了J2EE、J2SE和J2ME。這表明了Java開始向企業、桌面應用和移動裝置應用3大領域挺進。
- 2000年，JDK1.3釋出，Java HotSpot Virtual Machine正式釋出，成為Java的預設虛擬機器。
- 2002年，JDK1.4釋出，古老的Classic虛擬機器退出歷史舞臺。
- 2003年年底，Java平臺的scala正式釋出，同年Groovy也加入了Java陣營。
- 2004年，JDK1.5釋出。同時JDK1.5改名為JavaSE5.0。
2006年，JDK6釋出。同年，Java開源並建立了openJDK。順理成章，Hotspot虛擬機器也成為了openJDK中的預設虛擬機器。
- 2007年，Java平臺迎來了新夥伴Clojure。
- 2008年，oracle收購了BEA，得到了JRockit虛擬機器。
- 2009年，Twitter宣佈把後臺大部分程式從Ruby遷移到scala，這是Java平臺的又一次大規模應用。
- 2010年，oracle收購了sun，獲得Java商標和最真價值的HotSpot虛擬機器。此時，oracle擁有市場佔用率最高的兩款虛擬機器HotSpot和JRockit，並計劃在未來對它們進行整合：HotRockit
- 2011年，JDK7釋出。在JDK1.7u4中，正式啟用了新的垃圾回收器G1。
- 2017年，JDK9釋出。將G1設定為預設Gc，替代CMS
- 同年，IBM的J9開源，形成了現在的open J9社群
- 2018年，Android的Java侵權案判決，Google賠償oracle計88億美元
- 同年，oracle宣告JavagE成為歷史名詞JDBC、JMS、Servlet贈予Eclipse基金會
- 同年，JDK11釋出，LTS版本的JDK，釋出革命性的zGc，調整JDK授權許可
2019年，JDK12釋出，加入RedHat領導開發的shenandoah GC
在JDK11之前，oracleJDK中還會存在一些openJDK中沒有的、閉源的功能。但在JDK11中，我們可以認為openJDK和oracleJDK程式碼實質上已經完全一致的程度。
虛擬機器與Java虛擬機器
虛擬機器
所謂虛擬機器（Virtual Machine），就是一臺虛擬的計算機。它是一款軟體，用來執行一系列虛擬計算機指令。大體上，虛擬機器可以分為系統虛擬機器和程式虛擬機器。
- 大名鼎鼎的Visual Box，Mware就屬於系統虛擬機器，它們完全是對物理計算機的模擬，提供了一個可執行完整作業系統的軟體平臺。
- 程式虛擬機器的典型代表就是Java虛擬機器，它專門為執行單個計算機程式而設計，在Java虛擬機器中執行的指令我們稱為Java位元組碼指令。
無論是系統虛擬機器還是程式虛擬機器，在上面執行的軟體都被限制於虛擬機器提供的資源中。
Java虛擬機器
Java虛擬機器是一臺執行Java位元組碼的虛擬計算機，它擁有獨立的執行機制，其執行的Java位元組碼也未必由Java語言編譯而成。
JVM平臺的各種語言可以共享Java虛擬機器帶來的跨平臺性、優秀的垃圾回器，以及可靠的即時編譯器。
Java技術的核心就是Java虛擬機器（JVM，Java Virtual Machine），因為所有的Java程式都執行在Java虛擬機器內部。
Java虛擬機器就是二進位制位元組碼的執行環境，負責裝載位元組碼到其內部，解釋/編譯為對應平臺上的機器指令執行。每一條Java指令，Java虛擬機器規範中都有詳細定義，如怎麼取運算元，怎麼處理運算元，處理結果放在哪裡。
特點：
- 一次編譯，到處執行
- 自動記憶體管理
- 自動垃圾回收功能
JVM的位置
JVM是執行在作業系統之上的，它與硬體沒有直接的互動
Java的體系結構
JVM整體結構
- HotSpot VM是目前市面上高效能虛擬機器的代表作之一。
- 它採用直譯器與即時編譯器並存的架構。
- 在今天，Java程式的執行效能早已脫胎換骨，已經達到了可以和C/C++程式一較高下的地步。
執行引擎包含三部分：直譯器，及時編譯器，垃圾回收器
Java程式碼執行流程
只是能生成被Java虛擬機器所能解釋的位元組碼檔案，那麼理論上就可以自己設計一套程式碼了
JVM的架構模型
Java編譯器輸入的指令流基本上是一種基於棧的指令集架構，另外一種指令集架構則是基於暫存器的指令集架構。具體來說：這兩種架構之間的區別：
基於棧式架構的特點
- 設計和實現更簡單，適用於資源受限的系統；
- 避開了暫存器的分配難題：使用零地址指令方式分配。
- 指令流中的指令大部分是零地址指令，其執行過程依賴於操作棧。指令集更小，編譯器容易實現。
- 不需要硬體支援，可移植性更好，更好實現跨平臺
基於暫存器架構的特點
- 典型的應用是x86的二進位制指令集：比如傳統的PC以及Android的Davlik虛擬機器。
- 指令集架構則完全依賴硬體，可移植性差
- 效能優秀和執行更高效
- 花費更少的指令去完成一項操作。
- 在大部分情況下，基於暫存器架構的指令集往往都以一地址指令、二地址指令和三地址指令為主，而基於棧式架構的指令集卻是以零地址指令為主方水洋
舉例
同樣執行2+3這種邏輯操作，其指令分別如下：
基於棧的計算流程（以Java虛擬機器為例）：
iconst_2 //常量2入棧
istore_1
iconst_3 // 常量3入棧
istore_2
iload_1
iload_2
iadd //常量2/3出棧，執行相加
istore_0 // 結果5入棧而基於暫存器的計算流程
mov eax,2 //將eax暫存器的值設為1
add eax,3 //使eax暫存器的值加3位元組碼反編譯
我們編寫一個簡單的程式碼，然後檢視一下位元組碼的反編譯後的結果
/**
* @author: Nemo
*/
public class StackStruTest {
public static void main(String[] args) {
int i = 2 + 3;
}
}然後我們找到編譯後的 class檔案，使用下列命令進行反編譯
javap -v StackStruTest.class得到的檔案為:
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=4, args_size=1
0: iconst_2
1: istore_1
2: iconst_3
3: istore_2
4: iload_1
5: iload_2
6: iadd
7: istore_3
8: return
LineNumberTable:
line 9: 0
line 10: 2
line 11: 4
line 12: 8
LocalVariableTable:
Start Length Slot Name Signature
0 9 0 args [Ljava/lang/String;
2 7 1 i I
4 5 2 j I
8 1 3 k I總結
由於跨平臺性的設計，Java的指令都是根據棧來設計的。不同平臺CPU架構不同，所以不能設計為基於暫存器的。優點是跨平臺，指令集小，編譯器容易實現，缺點是效能下降，實現同樣的功能需要更多的指令。
時至今日，儘管嵌入式平臺已經不是Java程式的主流執行平臺了（準確來說應該是HotSpotVM的宿主環境已經不侷限於嵌入式平臺了），那麼為什麼不將架構更換為基於暫存器的架構呢？
棧
- 跨平臺性
- 指令集小
- 指令多
- 執行效能比暫存器差
JVM生命週期
虛擬機器的啟動
Java虛擬機器的啟動是通過引導類載入器（bootstrap class loader）建立一個初始類（initial class）來完成的，這個類是由虛擬機器的具體實現指定的。
虛擬機器的執行
- 一個執行中的Java虛擬機器有著一個清晰的任務：執行Java程式。
- 程式開始執行時他才執行，程式結束時他就停止。
- 執行一個所謂的Java程式的時候，真真正正在執行的是一個叫做Java虛擬機器的程式。
虛擬機器的退出
有如下的幾種情況：
程式正常執行結束
- 程式在執行過程中遇到了異常或錯誤而異常終止
- 由於作業系統用現錯誤而導致Java虛擬機器程式終止
- 某執行緒呼叫Runtime類或system類的exit方法，或Runtime類的halt方法，並且Java安全管理器也允許這次exit或halt操作。
除此之外，JNI（Java Native Interface）規範描述了用JNI Invocation API來載入或解除安裝 Java虛擬機器時，Java虛擬機器的退出情況。
JVM發展歷程
Sun Classic VM
- 早在1996年Java1.0版本的時候，Sun公司釋出了一款名為sun classic VM的Java虛擬機器，它同時也是世界上第一款商用Java虛擬機器，JDK1.4時完全被淘汰。
- 這款虛擬機器內部只提供直譯器。現在還有及時編譯器，因此效率比較低，而及時編譯器會把熱點程式碼快取起來，那麼以後使用熱點程式碼的時候，效率就比較高。
- 如果使用JIT編譯器，就需要進行外掛。但是一旦使用了JIT編譯器，JIT就會接管虛擬機器的執行系統。直譯器就不再工作。直譯器和編譯器不能配合工作。
- 現在hotspot內建了此虛擬機器。
Exact VM
為了解決上一個虛擬機器問題，jdk1.2時，sun提供了此虛擬機器。
Exact Memory Management：準確式記憶體管理
- 也可以叫Non-Conservative/Accurate Memory Management
- 虛擬機器可以知道記憶體中某個位置的資料具體是什麼型別。|
具備現代高效能虛擬機器的維形
- 熱點探測（尋找出熱點程式碼進行快取）
- 編譯器與直譯器混合工作模式
只在solaris平臺短暫使用，其他平臺上還是classic vm，英雄氣短，終被Hotspot虛擬機器替換
HotSpot VM
HotSpot歷史
- 最初由一家名為“Longview Technologies”的小公司設計
- 1997年，此公司被sun收購；2009年，Sun公司被甲骨文收購。
- JDK1.3時，HotSpot VM成為預設虛擬機器
目前Hotspot佔有絕對的市場地位，稱霸武林。
- 不管是現在仍在廣泛使用的JDK6，還是使用比例較多的JDK8中，預設的虛擬機器都是HotSpot
- Sun/oracle JDK和openJDK的預設虛擬機器
- 因此本課程中預設介紹的虛擬機器都是HotSpot，相關機制也主要是指HotSpot的Gc機制。（比如其他兩個商用虛機都沒有方法區的概念）
從伺服器、桌面到移動端、嵌入式都有應用。
名稱中的HotSpot指的就是它的熱點程式碼探測技術。
- 通過計數器找到最具編譯價值程式碼，觸發即時編譯或棧上替換
- 通過編譯器與直譯器協同工作，在最優化的程式響應時間與最佳執行效能中取得平衡
JRockit
專注於伺服器端應用
- 它可以不太關注程式啟動速度，因此JRockit內部不包含解析器實現，全部程式碼都靠即時編譯器編譯後執行。
大量的行業基準測試顯示，JRockit JVM是世界上最快的JVM。
- 使用JRockit產品，客戶已經體驗到了顯著的效能提高（一些超過了70%）和硬體成本的減少（達50%）。
優勢：全面的Java執行時解決方案組合
- JRockit面向延遲敏感型應用的解決方案JRockit Real Time提供以毫秒或微秒級的JVM響應時間，適合財務、軍事指揮、電信網路的需要
- MissionControl服務套件，它是一組以極低的開銷來監控、管理和分析生產環境中的應用程式的工具。
2008年，JRockit被oracle收購。
oracle表達了整合兩大優秀虛擬機器的工作，大致在JDK8中完成。整合的方式是在HotSpot的基礎上，移植JRockit的優秀特性。
高斯林：目前就職於谷歌，研究人工智慧和水下機器人
IBM的J9
全稱：IBM Technology for Java Virtual Machine，簡稱IT4J，內部代號：J9
市場定位與HotSpot接近，伺服器端、桌面應用、嵌入式等多用途VM廣泛用於IBM的各種Java產品。
目前，有影響力的三大商用虛擬機器之一，也號稱是世界上最快的Java虛擬機器。
2017年左右，IBM釋出了開源J9VM，命名為openJ9，交給EClipse基金會管理，也稱為Eclipse OpenJ9
OpenJDK -> 是JDK開源了，包括了虛擬機器
KVM和CDC / CLDC Hotspot
oracle在Java ME產品線上的兩款虛擬機器為：CDC/CLDC HotSpot Implementation VM KVM（Kilobyte）是CLDC-HI早期產品目前移動領域地位尷尬，智慧機被Angroid和ioS二分天下。
KVM簡單、輕量、高度可移植，面向更低端的裝置上還維持自己的一片市場
- 智慧控制器、感測器
- 老人手機、經濟欠發達地區的功能手機
所有的虛擬機器的原則：一次編譯，到處執行。
Azul VM
前面三大“高效能Java虛擬機器”使用在通用硬體平臺上這裡Azu1VW和BEALiquid VM是與特定硬體平臺繫結、軟硬體配合的專有虛擬機器I
- 高效能Java虛擬機器中的戰鬥機。
Azul VM是Azu1Systems公司在HotSpot基礎上進行大量改進，執行於Azul Systems公司的專有硬體Vega系統上的ava虛擬機器。
每個Azu1VM例項都可以管理至少數十個CPU和數百GB記憶體的硬體資源，並提供在巨大記憶體範圍內實現可控的GC時間的垃圾收集器、專有硬體優化的執行緒排程等優秀特性。
2010年，AzulSystems公司開始從硬體轉向軟體，釋出了自己的zing JVM，可以在通用x86平臺上提供接近於Vega系統的特性。
Liquid VM
高效能Java虛擬機器中的戰鬥機。
BEA公司開發的，直接執行在自家Hypervisor系統上Liquid VM即是現在的JRockit VE（Virtual Edition），
Liquid VM不需要作業系統的支援，或者說它自己本身實現了一個專用作業系統的必要功能，如執行緒排程、檔案系統、網路支援等。
隨著JRockit虛擬機器終止開發，Liquid vM專案也停止了。
Apache Marmony
Apache也曾經推出過與JDK1.5和JDK1.6相容的Java執行平臺Apache Harmony。
它是IElf和Inte1聯合開發的開源JVM，受到同樣開源的openJDK的壓制，Sun堅決不讓Harmony獲得JCP認證，最終於2011年退役，IBM轉而參與OpenJDK
雖然目前並沒有Apache Harmony被大規模商用的案例，但是它的Java類庫程式碼吸納進了Android SDK。
Micorsoft JVM
微軟為了在IE3瀏覽器中支援Java Applets，開發了Microsoft JVM。
只能在window平臺下執行。但確是當時Windows下效能最好的Java VM。
1997年，sun以侵犯商標、不正當競爭罪名指控微軟成功，賠了sun很多錢。微軟windowsXPSP3中抹掉了其VM。現在windows上安裝的jdk都是HotSpot。
Taobao JVM
由AliJVM團隊釋出。阿里，國內使用Java最強大的公司，覆蓋雲端計算、金融、物流、電商等眾多領域，需要解決高併發、高可用、分散式的複合問題。有大量的開源產品。
基於openJDK開發了自己的定製版本AlibabaJDK，簡稱AJDK。是整個阿里Java體系的基石。
基於openJDK Hotspot VM釋出的國內第一個優化、深度定製且開源的高效能伺服器版Java虛擬機器。
- 創新的GCIH（GCinvisible heap）技術實現了off-heap，即將生命週期較長的Java物件從heap中移到heap之外，並且Gc不能管理GCIH內部的Java物件，以此達到降低GC的回收頻率和提升Gc的回收效率的目的。
- GCIH中的物件還能夠在多個Java虛擬機器程式中實現共享
- 使用crc32指令實現JvM intrinsic降低JNI的呼叫開銷
- PMU hardware的Java profiling tool和診斷協助功能
- 針對大資料場景的ZenGc
taobao vm應用在阿里產品上效能高，硬體嚴重依賴inte1的cpu，損失了相容性，但提高了效能
目前已經在淘寶、天貓上線，把oracle官方JvM版本全部替換了。
Dalvik VM
谷歌開發的，應用於Android系統，並在Android2.2中提供了JIT，發展迅猛。
Dalvik y只能稱作虛擬機器，而不能稱作“Java虛擬機器”，它沒有遵循 Java虛擬機器規範
不能直接執行Java的Class檔案
基於暫存器架構，不是jvm的棧架構。
執行的是編譯以後的dex（Dalvik Executable）檔案。執行效率比較高。
- 它執行的dex（Dalvik Executable）檔案可以通過class檔案轉化而來，使用Java語法編寫應用程式，可以直接使用大部分的Java API等。
Android 5.0使用支援提前編譯（Ahead of Time Compilation，AoT）的ART VM替換Dalvik VM。
Graal VM
2018年4月，oracle Labs公開了GraalvM，號稱 "Run Programs Faster Anywhere"，勃勃野心。與1995年java的”write once，run anywhere"遙相呼應。
GraalVM在HotSpot VM基礎上增強而成的跨語言全棧虛擬機器，可以作為“任何語言”
的執行平臺使用。語言包括：Java、Scala、Groovy、Kotlin；C、C++、Javascript、Ruby、Python、R等
支援不同語言中混用對方的介面和物件，支援這些語言使用已經編寫好的本地庫檔案
工作原理是將這些語言的原始碼或原始碼編譯後的中間格式，通過直譯器轉換為能被Graal VM接受的中間表示。Graal VM提供Truffle工具集快速構建面向一種新語言的直譯器。在執行時還能進行即時編譯優化，獲得比原生編譯器更優秀的執行效率。
如果說HotSpot有一天真的被取代，Graalvm希望最大。但是Java的軟體生態沒有絲毫變化。
總結
具體JVM的記憶體結構，其實取決於其實現，不同廠商的JVM，或者同一廠商釋出的不同版本，都有可能存在一定差異。主要以oracle HotSpot VM為預設虛擬機器。