清蒸 JVM （一）

OtiliaMccra 7年前發布 | 15K 次閱讀 JVM Java開發

前言

JVM（Java Virtual Machine）Java 虛擬機是整個 java 平臺的基石，是 java 系統實現硬件無關與操作系統無關的關鍵部分，是保障用戶機器免于惡意代碼損害的屏障。Java開發人員不需要了解JVM是如何工作的，但是，了解 JVM 有助于我們更好的開（通）發（過） java（公司）程（面）序（試）。

寫這篇文章的目的：

總結所學的 JVM 知識
幫助想了解 JVM 的朋友，知無不言，言無不盡

本篇文章將會介紹一下內容：

什么是 JVM
JVM 用來做什么事情
JVM 生命周期
JVM 的整體架構
JVM 內存管理
總結

什么是 JVM

要想說明白什么 JVM 就不得不提另外兩個概念，JRE 和 JDK，初學者總是把這幾個概念搞混

java-tutorial.png

Jvm，Jre，Jdk 都是 java 語言的支柱，他們分工協作。但不同的是 Jdk 和 Jre 是真實存在的，而 Jvm 是一個抽象的概念，并不真實存在。

JDK

JDK(Java Development Kit) 是 Java 語言的軟件開發工具包（SDK）。JDK 物理存在，是 programming tools、JRE 和 JVM 的一個集合

jdk.png

JRE

JRE（Java Runtime Environment）Java 運行時環境，JRE 物理存在，主要由Java API 和 JVM 組成，提供了用于執行 java 應用程序最低要求的環境。

jre.png

JVM

JVM(Java Virtual Machine) 是一種軟件實現，執行像物理機程序的機器（即電腦）。

本來，Java被設計基于從物理機器分離實現WORA（寫一次，隨處運行）的虛擬機上運行，雖然這個目標已經幾乎被遺忘。

JVM 并不是專為 Java 所實現的運行時，實際上只要有其他編程語言的編譯器能生成正確 Java bytecode 文件，則這個語言也能實現在JVM上運行。

因此，JVM 通過執行 Java bytecode 可以使 java 代碼在不改變的情況下運行在各種硬件之上。

jVM 有如下特點：

基于堆棧的虛擬機：最流行的計算機體系結構，如英特爾X86架構和ARM架構上運行基于寄存器。但是，JVM是基于棧的。
符號引用：除了基本類型以外的數據（類和接口）都是通過符號來引用，而不是通過顯式地使用內存地址來引用。
垃圾收集：一個類的實例是由用戶明確創建的代碼和垃圾回收自動銷毀。
通過明確界定的基本數據類型的保證平臺的獨立性：傳統的語言，如C / C ++根據平臺有不同的int型的大小。 JVM中明確規定了基本數據類型，以保持它的兼容性和保證平臺的獨立性。
網絡字節順序：Java class文件用網絡字節碼順序來進行存儲：為了保證和小端的Intel x86架構以及大端的RISC系列的架構保持無關性，JVM使用用于網絡傳輸的網絡字節順序，也就是大端。

Java bytecode

為了實現WORA，JVM使用Java字節碼，java（用戶語言）和機器語言之間的中間語言。

該Java字節碼是部署Java代碼的最小單位。

JVM 用來做什么

基于安全方面考慮，JVM 要求在 class 文件中使用許多強制性的語法和機構化約束，但任意一門功能性語言都可以表示為一個能被 JVM 接受的有效的 class 文件。作為一個通用的、機器無關的執行平臺，任何其他語言的實現者都可將 JVM 當作他的語言產品交付媒介。

JVM 中執行以下操作：

加載代碼
驗證代碼
執行代碼
提供運行環境

JVM 提供定義了：

存儲區
類文件格式
寄存器組
垃圾回收堆
致命錯誤報告等

JVM 生命周期

啟動：任何一個擁有main函數的class都可以作為JVM實例運行的起點
運行：main函數為起點，程序中的其他線程均有它啟動，包括daemon守護線程和non-daemon普通線程。daemon是JVM自己使用的線程比如GC線程，main方法的初始線程是non-daemon。
消亡：所有線程終止時，JVM實例結束生命。

JVM 的整體架構

先看一下 java 代碼執行過程

jvm.png

疑問：

Class Loader
Excution Engine
Runtime Data Areas

Class Loader

類加載器負責加載程序中的類型（類和接口），并賦予唯一的名字。

JDK 默認提供了三種 ClassLoader

classloader.png

關系

Bootstrp loader 是在Java虛擬機啟動后初始化的。
Bootstrp loader 負責加載 ExtClassLoader,并且將 ExtClassLoade r的父加載器設置為 Bootstrp loader。
Bootstrp loader 加載完 ExtClassLoader 后，就會加載 AppClassLoader,并且將 AppClassLoader 的父加載器指定為 ExtClassLoader。

Class Loader	實現	負責加載
Bootstrp loader	C++	%JAVA_HOME%/jre/lib,-Xbootclasspath參數指定的路徑以及%JAVA_HOME%/jre/classes中的類
ExtClassLoader	Java	%JAVA_HOME%/jre/lib/ext，此路徑下的所有classes目錄以及java.ext.dirs系統變量指定的路徑中類庫
AppClassLoader	Java	classpath所指定的位置的類或者是jar文檔，它也是Java程序默認的類加載器

雙親委托模型

Java中ClassLoader的加載采用了雙親委托機制，采用雙親委托機制加載類的時候采用如下的幾個步驟：

當前ClassLoader首先從自己已經加載的類中查詢是否此類已經加載，如果已經加載則直接返回原來已經加載的類。
當前classLoader的緩存中沒有找到被加載的類的時候，委托父類加載器去加載，父類加載器采用同樣的策略，首先查看自己的緩存，然后委托父類的父類去加載，一直到bootstrp ClassLoader.
當所有的父類加載器都沒有加載的時候，再由當前的類加載器加載，并將其放入它自己的緩存中，以便下次有加載請求的時候直接返回。

為什么使用雙親委托模型——ClassLoader 隔離問題

每個類裝載器都有一個自己的命名空間用來保存已裝載的類。當一個類裝載器裝載一個類時，它會通過保存在命名空間里的類全局限定名(Fully Qualified Class Name)進行搜索來檢測這個類是否已經被加載了。

大家覺得一個運行程序中有沒有可能同時存在兩個包名和類名完全一致的類？

JVM 及 Dalvik 對類唯一的識別是 ClassLoader id + PackageName + ClassName，所以一個運行程序中是有可能存在兩個包名和類名完全一致的類的。并且如果這兩個”類”不是由一個 ClassLoader 加載，是無法將一個類的示例強轉為另外一個類的，這就是 ClassLoader 隔離。

雙親委托是 ClassLoader 問題的一種解決方案，也是 Android 差價化開發和熱修復的基礎。

類裝載器特點

Java提供了動態加載特性；他會在運行時的第一次引用到一個class的時候對它進行裝載（Loading）、鏈接(Linking)和初始化(Initialization)，而不是在編譯時進行。不同的JVM的實現不同，本文所描述的內容均只限于Hotspot Jvm。JVM的類裝載器負責動態裝載，Java的類裝載器有如下幾個特點：

層級結構：Java里的類裝載器被組織成了有父子關系的層級結構。Bootstrap類裝載器是所有裝載器的父親。
代理模式：基于層級結構，類的代理可以在裝載器之間進行代理。當裝載器裝載一個類時，首先會檢查它在父裝載器中是否進行了裝載。如果上層裝載器已經裝載了這個類，這個類會被直接使用。反之，類裝載器會請求裝載這個類
可見性限制：一個子裝載器可以查找父裝載器中的類，但是一個父裝載器不能查找子裝載器里的類。
不允許卸載：類裝載器可以裝載一個類但是不可以卸載它，不過可以刪除當前的類裝載器，然后創建一個新的類裝載器裝載。

過程

加載（Loading）是這樣一個過程,找到代表這個類的class文件或根據特定的名字找到接口類型，然后讀取到一個字節數組中。接著，這些字節會被解析檢驗它們是否代表一個Class對象并包含正確的major、minor版本信息。直接父類的類和接口也會被加載進來。這些操作一旦完成，類或者接口對象就從二進制表示中創建出來了。

鏈接（Linking）是檢驗類或接口并準備類型和父類接口的過程。鏈接過程包含三步：校驗（Verifying）、準備（Preparing）、部分解析（Optionally resolving）。

loadclass.png

驗證：這是類裝載中最復雜的過程，并且花費的時間也是最長的。任務是確保導入類型的準確性，驗證階段做的檢查，運行時不需要再做，雖然減慢加了載速度，但是避免了多次檢查。
準備：分配一個結構用來存儲類信息，這個結構中包含了類中定義的成員變量，方法和接口的信息。
解析：可選階段，把這個類的常量池中的所有的符號引用改變成直接引用。如果不執行，符號解析要等到字節碼指令使用這個引用時才會進行

初始化（Initialization）把類中的變量初始化成合適的值。執行靜態初始化程序，把靜態變量初始化成指定的值。

JVM規范定義了上面的幾個任務，不過它允許具體執行的時候能夠有些靈活的變動。

執行引擎（Execution Engine）

通過類裝載器裝載的，被分配到JVM的運行時數據區的字節碼會被執行引擎執行。執行引擎以指令為單位讀取 Java 字節碼。它就像一個 CPU 一樣，一條一條地執行機器指令。每個字節碼指令都由一個1字節的操作碼和附加的操作數組成。執行引擎取得一個操作碼，然后根據操作數來執行任務，完成后就繼續執行下一條操作碼。

不過 Java 字節碼是用一種人類可以讀懂的語言編寫的，而不是用機器可以直接執行的語言。因此，執行引擎必須把字節碼轉換成可以直接被 JVM 執行的語言。字節碼可以通過以下兩種方式轉換成合適的語言。

解釋器：一條一條地讀取，解釋并且執行字節碼指令。因為它一條一條地解釋和執行指令，所以它可以很快地解釋字節碼，但是執行起來會比較慢。這是解釋執行的語言的一個缺點。字節碼這種“語言”基本來說是解釋執行的。
即時（Just-In-Time)編譯器：即時編譯器被引入用來彌補解釋器的缺點。執行引擎首先按照解釋執行的方式來執行，然后在合適的時候，即時編譯器把整段字節碼編譯成本地代碼。然后，執行引擎就沒有必要再去解釋執行方法了，它可以直接通過本地代碼去執行它。執行本地代碼比一條一條進行解釋執行的速度快很多。編譯后的代碼可以執行的很快，因為本地代碼是保存在緩存里的。

Java 字節碼是解釋執行的，但是沒有直接在 JVM 宿主執行原生代碼快。為了提高性能，Oracle Hotspot 虛擬機會找到執行最頻繁的字節碼片段并把它們編譯成原生機器碼。編譯出的原生機器碼被存儲在非堆內存的代碼緩存中。通過這種方法（JIT），Hotspot 虛擬機將權衡下面兩種時間消耗：將字節碼編譯成本地代碼需要的額外時間和解釋執行字節碼消耗更多的時間。

java_compiler_and_jit_compiler.png

這里插入一下 Android 5.0 以后用的 ART 虛擬機使用的是 AOT 機制。

Dalvik 是依靠一個 Just-In-Time (JIT)編譯器去解釋字節碼。開發者編譯后的應用代碼需要通過一個解釋器在用戶的設備上運行，這一機制并不高效，但讓應用能更容易在不同硬件和架構上運行。ART 則完全改變了這套做法，在應用安裝時就預編譯字節碼到機器語言，這一機制叫 Ahead-Of-Time (AOT）編譯。在移除解釋代碼這一過程后，應用程序執行將更有效率，啟動更快。

運行時數據區

JVM 運行時數據結構圖：

runtime-data-access-configuration.png

PC寄存器（PC Register）

也叫程序計數器（Program Counter Register）是一塊較小的內存空間，它的作用可以看做是當前線程所執行的字節碼的信號指示器。

每一條JVM線程都有自己的PC寄存器

在任意時刻，一條 JVM 線程只會執行一個方法的代碼。該方法稱為該線程的當前方法（Current Method）

如果該方法是 java 方法，那PC寄存器保存 JVM 正在執行的字節碼指令的地址

如果該方法是 native，那 PC 寄存器的值是 undefined。

此內存區域是唯一一個在 Java 虛擬機規范中沒有規定任何OutOfMemoryError情況的區域。

JVM 棧（Java Virtual Machine Stack）

與 PC 寄存器一樣，java 虛擬機棧（Java Virtual Machine Stack）也是線程私有的。每一個JVM線程都有自己的java虛擬機棧，這個棧與線程同時創建，它的生命周期與線程相同，用來保存棧幀。JVM 只會在 JVM 棧上進行 push 和 pop 的操作。

JVM stack 可以被實現成固定大小，也可以根據計算動態擴展。

如果采用固定大小的JVM stack設計，那么每一條線程的JVM Stack容量應該在線程創建時獨立地選定。JVM實現應該提供調節JVM Stack初始容量的手段。

如果采用動態擴展和收縮的JVM Stack方式，應該提供調節最大、最小容量的手段。

JVM 棧異常情況
- StackOverflowError：當線程請求分配的棧容量超過JVM允許的最大容量時拋出
- OutOfMemoryError：如果JVM Stack可以動態擴展，但是在嘗試擴展時無法申請到足夠的內存去完成擴展，或者在建立新的線程時沒有足夠的內存去創建對應的虛擬機棧時拋出。
</li>
棧幀（stack frame）
棧幀隨著方法調用而創建，隨著方法結束而銷毀——無論方法是正常完成還是異常完成（拋出了在方法內未被捕獲的異常）都算作方法結束。棧幀的存儲空間分配在 Java 虛擬機棧之中，每一個棧幀都有自己的局部變量表（Local Variables）、操作數棧（Operand Stack）和指向當前方法所屬的類的運行時常量池的引用。
- 局部變量數組(Local variable array)
  每個棧幀內部都包含一組稱為局部變量表（Local Variables）的變量列表。棧幀中局部變量表的長度由編譯期決定。
  局部變量使用索引來進行定位訪問，第一個局部變量的索引值為零，局部變量的索引值是從零至小于局部變量表最大容量的所有整數。
  Java 虛擬機使用局部變量表來完成方法調用時的參數傳遞，當一個方法被調用的時候，它的參數將會傳遞至從 0 開始的連續的局部變量表位置上。特別地，當一個實例方法被調用的時候，第 0 個局部變量一定是用來存儲被調用的實例方法所在的對象的引用（即 Java 語言中的“this”關鍵字）。后續的其他參數將會傳遞至從 1 開始的連續的局部變量表位置上。
- 操作數棧(Operand stack)
  每一個棧幀內部都包含一個稱為操作數棧（Operand Stack）的后進先出（Last-In-First-Out，LIFO）棧。棧幀中操作數棧的長度由編譯期決定。
  操作數棧所屬的棧幀在剛剛被創建的時候，操作數棧是空的。Java 虛擬機提供一些字節碼指令來從局部變量表或者對象實例的字段中復制常量或變量值到操作數棧中，也提供了一些指令用于從操作數棧取走數據、操作數據和把操作結果重新入棧。在方法調用的時候，操作數棧也用來準備調用方法的參數以及接收方法返回結果。
- 動態鏈接（Dynamic Linking）
  每個棧幀都有一個運行時常量池的引用。這個引用指向棧幀當前運行方法所在類的常量池。通過這個引用支持動態鏈接（dynamic linking）。
  C/C++ 代碼一般被編譯成對象文件，然后多個對象文件被鏈接到一起產生可執行文件或者 dll。在鏈接階段，每個對象文件的符號引用被替換成了最終執行文件的相對偏移內存地址。在 Java中，鏈接階段是運行時動態完成的。
  當 Java 類文件編譯時，所有變量和方法的引用都被當做符號引用存儲在這個類的常量池中。符號引用是一個邏輯引用，實際上并不指向物理內存地址。JVM 可以選擇符號引用解析的時機，一種是當類文件加載并校驗通過后，這種解析方式被稱為饑餓方式。另外一種是符號引用在第一次使用的時候被解析，這種解析方式稱為惰性方式。無論如何，JVM 必須要在第一次使用符號引用時完成解析并拋出可能發生的解析錯誤。綁定是將對象域、方法、類的符號引用替換為直接引用的過程。綁定只會發生一次。一旦綁定，符號引用會被完全替換。如果一個類的符號引用還沒有被解析，那么就會載入這個類。每個直接引用都被存儲為相對于存儲結構（與運行時變量或方法的位置相關聯的）偏移量。
- 方法正常調用完成
  在這種場景下，當前棧幀承擔著回復調用者狀態的責任，其狀態包括調用者的局部變量表、操作數棧和被正確增加過來表示執行了該方法調用指令的程序計數器等。使得調用者的代碼能在被調用的方法返回并且返回值被推入調用者棧幀的操作數棧后繼續正常地執行。
- 方法異常調用完成
  方法異常調用完成是指在方法的執行過程中，某些指令導致了 Java 虛擬機拋出異常，并且虛擬機拋出的異常在該方法中沒有辦法處理，或者在執行過程中遇到了 athrow 字節碼指令顯式地拋出異常，并且在該方法內部沒有把異常捕獲住。如果方法異常調用完成，那一定不會有方法返回值返回給它的調用者。

本文由用戶 OtiliaMccra 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1487922217984.html

JVM Java開發