01-JVM与Java体系结构
JVM與Java體系結構
前言
作為Java工程師的你曾被傷害過嗎?你是否也遇到過這些問題?
運行著的線上系統突然卡死,系統無法訪問,甚至直接OOMM!
- 想解決線上JVM GC問題,但卻無從下手。
- 新項目上線,對各種JVM參數設置一臉茫然,直接默認吧然后就JJ了
- 每次面試之前都要重新背一遍JVM的一些原理概念性的東西,然而面試官卻經常問你在實際項目中如何調優VM參數,如何解決GC、OOM等問題,一臉懵逼。
大部分Java開發人員,除會在項目中使用到與Java平臺相關的各種高精尖技術,對于Java技術的核心Java虛擬機了解甚少。
一些有一定工作經驗的開發人員,打心眼兒里覺得SSM、微服務等上層技術才是重點,基礎技術并不重要,這其實是一種本末倒置的“病態”。如果我們把核心類庫的API比做數學公式的話,那么Java虛擬機的知識就好比公式的推導過程。
計算機系統體系對我們來說越來越遠,在不了解底層實現方式的前提下,通過高級語言很容易編寫程序代碼。但事實上計算機并不認識高級語言
架構師每天都在思考什么?
- 應該如何讓我的系統更快?
- 如何避免系統出現瓶頸?
知乎上有條帖子:應該如何看招聘信息,直通年薪50萬+?
- 參與現有系統的性能優化,重構,保證平臺性能和穩定性
- 根據業務場景和需求,決定技術方向,做技術選型
- 能夠獨立架構和設計海量數據下高并發分布式解決方案,滿足功能和非功能需求
- 解決各類潛在系統風險,核心功能的架構與代碼編寫
- 分析系統瓶頸,解決各種疑難雜癥,性能調優等
JDK、JRE和JVM三者之間的關系
首先是JDK
JDK(Java Development Kit) 是 Java 語言的軟件開發工具包(SDK)。 在JDK的安裝目錄下有一個jre目錄,里面有兩個文件夾bin和lib,在這里可以認為bin里的就是jvm,lib中則是jvm工作所需要的類庫,而jvm和 lib合起來就稱為jre。
然后我們來看JRE
JRE(Java Runtime Environment,Java運行環境),包含JVM標準實現及Java核心類庫。JRE是Java運行環境,并不是一個開發環境,所以沒有包含任何開發工具(如編譯器和調試器)
最后JVM也一目了然了
JVM是Java Virtual Machine(Java虛擬機)的縮寫,JVM是一種用于計算設備的規范,它是一個虛構出來的計算機,是通過在實際的計算機上仿真模擬各種計算機功能來實現的。
由上圖一目了然:
JDK是整個Java的核心,包括了Java運行環境JRE、Java工具和Java基礎類庫。JRE是運行JAVA程序所必須的環境的集合,包含JVM標準實現及Java核心類庫。JVM是整個java實現跨平臺的最核心的部分,能夠運行以Java語言寫的程序。
為什么要學習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文件編譯成.class文件稱為編譯前端,從運行時數據區到執行引擎稱為編譯后端。
執行引擎包含三部分:解釋器,JIT及時編譯器,垃圾回收器
解釋器和JIT及時編譯器負責的是兩種將字節碼編譯成機器碼的方式。目的都是將字節碼轉換為機器碼來使程序能夠在本地運行,只是觸發的時機和執行過程會有所不同;解釋器是在程序運行時的默認選擇的方式,而編譯器是指需要執行的字節碼屬于熱點代碼時才會觸發,并會將其編譯結果放入緩存,以供后續使用,提高編譯效率。
Java代碼執行流程
只是能生成被Java虛擬機所能解釋的字節碼文件,那么理論上就可以自己設計一套代碼了
JVM的架構模型
Java編譯器輸入的指令流基本上是一種基于棧的指令集架構(Hotspot即為此結構),另外一種指令集架構則是基于寄存器的指令集架構。具體來說:這兩種架構之間的區別:
基于棧式架構的特點
- 設計和實現更簡單,適用于資源受限的系統;
- 避開了寄存器的分配難題:使用零地址指令方式分配。
- 指令流中的指令大部分是零地址指令,其執行過程依賴于操作棧。指令集更小,編譯器容易實現。
- 不需要硬件支持,可移植性更好,更好實現跨平臺
基于寄存器架構的特點
- 典型的應用是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: 陌溪* @create: 2020-07-04-21:17*/ 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;)Vflags: ACC_PUBLIC, ACC_STATICCode:stack=2, locals=4, args_size=10: iconst_21: istore_12: iconst_33: istore_24: iload_15: iload_26: iadd7: istore_38: returnLineNumberTable:line 9: 0line 10: 2line 11: 4line 12: 8LocalVariableTable:Start Length Slot Name Signature0 9 0 args [Ljava/lang/String;2 7 1 i I4 5 2 j I8 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為默認虛擬機。
總結
以上是生活随笔為你收集整理的01-JVM与Java体系结构的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Services overview
- 下一篇: Java运行过程