【JVM之記憶體與垃圾回收篇】JVM與Java體系結構
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的優秀特性。
高斯林:目前就職於Google,研究人工智慧和水下機器人
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
Google開發的,應用於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為默認虛擬機。