[[325305]]

這篇文章解釋了Java 虛擬機(JVM)的內部架構。下圖顯示了遵守 Java SE 7 規范的典型的 JVM 核心內部組件。

 

 

上圖顯示的組件分兩個章節解釋。第一章討論針對每個線程創建的組件，第二章節討論了線程無關組件。

• 線程
• JVM 系統線程
• 每個線程相關的
• 程序計數器
• 棧
• 本地棧
• 棧限制
• 棧幀
• 局部變量數組
• 操作數棧
• 動態鏈接
• 線程共享
• 堆
• 內存管理
• 非堆內存
• 即時編譯
• 方法區
• 類文件結構
• 類加載器
• 更快的類加載
• 方法區在哪里
• 類加載器參考
• 運行時常量池
• 異常表
• 符號表
• Interned 字符串

線程

這里所說的線程指程序執行過程中的一個線程實體。JVM 允許一個應用并發執行多個線程。Hotspot JVM 中的 Java 線程與原生操作系統線程有直接的映射關系。當線程本地存儲、緩沖區分配、同步對象、棧、程序計數器等準備好以后，就會創建一個操作系統原生線程。Java 線程結束，原生線程隨之被回收。操作系統負責調度所有線程，并把它們分配到任何可用的 CPU 上。當原生線程初始化完畢，就會調用 Java 線程的 run() 方法。run() 返回時，被處理未捕獲異常，原生線程將確認由于它的結束是否要終止 JVM 進程(比如這個線程是最后一個非守護線程)。當線程結束時，會釋放原生線程和 Java 線程的所有資源。

JVM 系統線程

如果使用 jconsole 或者其它調試器，你會看到很多線程在后臺運行。這些后臺線程與觸發 public static void main(String[]) 函數的主線程以及主線程創建的其他線程一起運行。Hotspot JVM 后臺運行的系統線程主要有下面幾個：

 

 

線程相關組件

每個運行的線程都包含下面這些組件：

程序計數器(PC)

PC 指當前指令(或操作碼)的地址，本地指令除外。如果當前方法是 native 方法，那么PC 的值為 undefined。所有的 CPU 都有一個 PC，典型狀態下，每執行一條指令 PC 都會自增，因此 PC 存儲了指向下一條要被執行的指令地址。JVM 用 PC 來跟蹤指令執行的位置，PC 將實際上是指向方法區(Method Area)的一個內存地址。

棧(Stack)

每個線程擁有自己的棧，棧包含每個方法執行的棧幀。棧是一個后進先出(LIFO)的數據結構，因此當前執行的方法在棧的頂部。每次方法調用時，一個新的棧幀創建并壓棧到棧頂。當方法正常返回或拋出未捕獲的異常時，棧幀就會出棧。除了棧幀的壓棧和出棧，棧不能被直接操作。所以可以在堆上分配棧幀，并且不需要連續內存。

Native棧

并非所有的 JVM 實現都支持本地(native)方法，那些提供支持的 JVM 一般都會為每個線程創建本地方法棧。如果 JVM 用 C-linkage 模型實現 JNI(Java Native Invocation)，那么本地棧就是一個 C 的棧。在這種情況下，本地方法棧的參數順序、返回值和典型的 C 程序相同。本地方法一般來說可以(依賴 JVM 的實現)反過來調用 JVM 中的 Java 方法。這種 native 方法調用 Java 會發生在棧(一般是 Java 棧)上;線程將離開本地方法棧，并在 Java 棧上開辟一個新的棧幀。

棧的限制

棧可以是動態分配也可以固定大小。如果線程請求一個超過允許范圍的空間，就會拋出一個StackOverflowError。如果線程需要一個新的棧幀，但是沒有足夠的內存可以分配，就會拋出一個 OutOfMemoryError。

棧幀(Frame)

每次方法調用都會新建一個新的棧幀并把它壓棧到棧頂。當方法正常返回或者調用過程中拋出未捕獲的異常時，棧幀將出棧。更多關于異常處理的細節，可以參考下面的異常信息表章節。

每個棧幀包含：

• 局部變量數組
• 返回值
• 操作數棧
• 類當前方法的運行時常量池引用

局部變量數組

局部變量數組包含了方法執行過程中的所有變量，包括 this 引用、所有方法參數、其他局部變量。對于類方法(也就是靜態方法)，方法參數從下標 0 開始，對于對象方法，位置0保留為 this。

有下面這些局部變量：

• boolean
• byte
• char
• long
• short
• int
• float
• double
• reference
• returnAddress

除了 long 和 double 類型以外，所有的變量類型都占用局部變量數組的一個位置。long 和 double 需要占用局部變量數組兩個連續的位置，因為它們是 64 位雙精度，其它類型都是 32 位單精度。

操作數棧

操作數棧在執行字節碼指令過程中被用到，這種方式類似于原生 CPU 寄存器。大部分 JVM 字節碼把時間花費在操作數棧的操作上：入棧、出棧、復制、交換、產生消費變量的操作。因此，局部變量數組和操作數棧之間的交換變量指令操作通過字節碼頻繁執行。比如，一個簡單的變量初始化語句將產生兩條跟操作數棧交互的字節碼。

int i; 

被編譯成下面的字節碼：

0: iconst_0 // Push 0 to top of the operand stack 
1: istore_1 // Pop value from top of operand stack and store as local variable 1 

更多關于局部變量數組、操作數棧和運行時常量池之間交互的詳細信息，可以在類文件結構部分找到。

動態鏈接

每個棧幀都有一個運行時常量池的引用。這個引用指向棧幀當前運行方法所在類的常量池。通過這個引用支持動態鏈接(dynamic linking)。

C/C++ 代碼一般被編譯成對象文件，然后多個對象文件被鏈接到一起產生可執行文件或者 dll。在鏈接階段，每個對象文件的符號引用被替換成了最終執行文件的相對偏移內存地址。在 Java中，鏈接階段是運行時動態完成的。

當 Java 類文件編譯時，所有變量和方法的引用都被當做符號引用存儲在這個類的常量池中。符號引用是一個邏輯引用，實際上并不指向物理內存地址。JVM 可以選擇符號引用解析的時機，一種是當類文件加載并校驗通過后，這種解析方式被稱為饑餓方式。另外一種是符號引用在第一次使用的時候被解析，這種解析方式稱為惰性方式。無論如何 ，JVM 必須要在第一次使用符號引用時完成解析并拋出可能發生的解析錯誤。綁定是將對象域、方法、類的符號引用替換為直接引用的過程。綁定只會發生一次。一旦綁定，符號引用會被完全替換。如果一個類的符號引用還沒有被解析，那么就會載入這個類。每個直接引用都被存儲為相對于存儲結構(與運行時變量或方法的位置相關聯的)偏移量。

線程間共享

堆

堆被用來在運行時分配類實例、數組。不能在棧上存儲數組和對象。因為棧幀被設計為創建以后無法調整大小。棧幀只存儲指向堆中對象或數組的引用。與局部變量數組(每個棧幀中的)中的原始類型和引用類型不同，對象總是存儲在堆上以便在方法結束時不會被移除。對象只能由垃圾回收器移除。

為了支持垃圾回收機制，堆被分為了下面三個區域：

• 新生代
• 經常被分為 Eden 和 Survivor
• 老年代
• 永久代

內存管理

對象和數組永遠不會顯式回收，而是由垃圾回收器自動回收。通常，過程是這樣的：

• 新的對象和數組被創建并放入老年代。
• Minor垃圾回收將發生在新生代。依舊存活的對象將從 eden 區移到 survivor 區。
• Major垃圾回收一般會導致應用進程暫停，它將在三個區內移動對象。仍然存活的對象將被從新生代移動到老年代。
• 每次進行老年代回收時也會進行永久代回收。它們之中任何一個變滿時，都會進行回收。

非堆內存

非堆內存指的是那些邏輯上屬于 JVM 一部分對象，但實際上不在堆上創建。

• 非堆內存包括：
• 永久代，包括：
• 方法區
• 駐留字符串(interned strings)

代碼緩存(Code Cache)：用于編譯和存儲那些被 JIT 編譯器編譯成原生代碼的方法。

即時編譯(JIT)

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

方法區

方法區存儲了每個類的信息，比如：

• Classloader 引用
• 運行時常量池
• 數值型常量
• 字段引用
• 方法引用
• 屬性
• 字段數據
• 字段名
• 類型
• 修飾符
• 屬性(Attribute)
• 針對每個字段的信息
• 方法數據
• 方法名
• 返回值類型
• 參數類型(按順序)
• 修飾符
• 屬性
• 每個方法
• 方法代碼
• 字節碼
• 操作數棧大小
• 局部變量大小
• 局部變量表
• 異常表
• 每個異常處理器
• 開始點
• 結束點
• 異常處理代碼的程序計數器(PC)偏移量
• 被捕獲的異常類對應的常量池下標
• 每個方法

所有線程共享同一個方法區，因此訪問方法區數據的和動態鏈接的進程必須線程安全。如果兩個線程試圖訪問一個還未加載的類的字段或方法，必須只加載一次，而且兩個線程必須等它加載完畢才能繼續執行。

類文件結構

一個編譯后的類文件包含下面的結構：

 

 

 

 

可以用 javap 查看編譯后的 java class 文件字節碼。

如果你編譯下面這個簡單的類：

package org.jvminternals; 
public class SimpleClass { 
 public void sayHello() { 
 System.out.println("Hello"); 
 } 
} 

運行下面的命令，就可以得到下面的結果輸出： javap -v -p -s -sysinfo -constants classes/org/jvminternals/SimpleClass.class。

 

 

 

 

這個 class 文件展示了三個主要部分：常量池、構造器方法和 sayHello 方法。

• 常量池：提供了通常由符號表提供的相同信息，詳細描述見下文。
• 方法：每一個方法包含四個區域，
• 簽名和訪問標簽
• 字節碼
• LineNumberTable：為調試器提供源碼中的每一行對應的字節碼信息。上面的例子中，Java 源碼里的第 6 行與 sayHello 函數字節碼序號 0 相關，第 7 行與字節碼序號 8 相關。
• LocalVariableTable：列出了所有棧幀中的局部變量。上面兩個例子中，唯一的局部變量就是 this。

這個 class 文件用到下面這些字節碼操作符：

 

 

跟任何典型的字節碼一樣，操作數與局部變量、操作數棧、運行時常量池的主要交互如下所示。

構造器函數包含兩個指令。首先，this 變量被壓棧到操作數棧，然后父類的構造器函數被調用，而這個構造器會消費 this，之后 this 被彈出操作數棧。

 

 

sayHello() 方法更加復雜，正如之前解釋的那樣，因為它需要用運行時常量池中的指向符號引用的真實引用。第一個操作碼 getstatic 從System類中將out靜態變量壓到操作數棧。下一個操作碼 ldc 把字符串 “Hello” 壓棧到操作數棧。最后 invokevirtual 操作符會調用 System.out 變量的 println 方法，從操作數棧作彈出”Hello” 變量作為 println 的一個參數，并在當前線程開辟一個新棧幀。

 

 

類加載器

JVM 啟動時會用 bootstrap 類加載器加載一個初始化類，然后這個類會在public static void main(String[])調用之前完成鏈接和初始化。執行這個方法會執行加載、鏈接、初始化需要的額外類和接口。

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

鏈接(Linking)是校驗類或接口并準備類型和父類父接口的過程。鏈接過程包含三步：校驗(verifying)、準備(preparing)、部分解析(optionally resolving)。

校驗會確認類或者接口表示是否結構正確，以及是否遵循 Java 語言和 JVM 的語義要求，比如會進行下面的檢查：

• 格式一致且格式化正確的符號表
• final 方法和類沒有被重載
• 方法遵循訪問控制關鍵詞
• 方法參數的數量、類型正確
• 字節碼沒有不當的操作棧數據
• 變量在讀取之前被初始化過
• 變量值的類型正確

在驗證階段做這些檢查意味著不需要在運行階段做這些檢查。鏈接階段的檢查減慢了類加載的速度，但是它避免了執行這些字節碼時的多次檢查。

準備過程包括為靜態存儲和 JVM 使用的數據結構(比如方法表)分配內存空間。靜態變量創建并初始化為默認值，但是初始化代碼不在這個階段執行，因為這是初始化過程的一部分。

解析是可選的階段。它包括通過加載引用的類和接口來檢查這些符號引用是否正確。如果不是發生在這個階段，符號引用的解析要等到字節碼指令使用這個引用的時候才會進行。

類或者接口初始化由類或接口初始化方法的執行組成。

 

 

JVM 中有多個類加載器，分飾不同的角色。每個類加載器由它的父加載器加載。bootstrap 加載器除外，它是所有最頂層的類加載器。

• Bootstrap 加載器一般由本地代碼實現，因為它在 JVM 加載以后的早期階段就被初始化了。bootstrap 加載器負責載入基礎的 Java API，比如包含 rt.jar。它只加載擁有較高信任級別的啟動路徑下找到的類，因此跳過了很多普通類需要做的校驗工作。
• Extension 加載器加載了標準 Java 擴展 API 中的類，比如 security 的擴展函數。
• System 加載器是應用的默認類加載器，比如從 classpath 中加載應用類。
• 用戶自定義類加載器也可以用來加載應用類。使用自定義的類加載器有很多特殊的原因：運行時重新加載類或者把加載的類分隔為不同的組，典型的用法比如 web 服務器 Tomcat。

 

 

加速類加載

共享類數據(CDS)是Hotspot JVM 5.0 的時候引入的新特性。在 JVM 安裝過程中，安裝進程會加載一系列核心 JVM 類(比如 rt.jar)到一個共享的內存映射區域。CDS 減少了加載這些類需要的時間，提高了 JVM 啟動的速度，允許這些類被不同的 JVM 實例共享，同時也減少了內存消耗。

方法區在哪里

The Java Virtual Machine Specification Java SE 7 Edition 中寫得很清楚：“盡管方法區邏輯上屬于堆的一部分，簡單的實現可以選擇不對它進行回收和壓縮。”。Oracle JVM 的 jconsle 顯示方法區和 code cache 區被當做為非堆內存，而 OpenJDK 則顯示 CodeCache 被當做 VM 中對象堆(ObjectHeap)的一個獨立的域。

Classloader 引用

所有的類加載之后都包含一個加載自身的加載器的引用，反過來每個類加載器都包含它們加載的所有類的引用。

運行時常量池

JVM 維護了一個按類型區分的常量池，一個類似于符號表的運行時數據結構。盡管它包含更多數據。Java 字節碼需要數據。這個數據經常因為太大不能直接存儲在字節碼中，取而代之的是存儲在常量池中，字節碼包含這個常量池的引用。運行時常量池被用來上面介紹過的動態鏈接。

常量池中可以存儲多種類型的數據：

• 數字型
• 字符串型
• 類引用型
• 域引用型
• 方法引用

示例代碼如下：

Object foo = new Object(); 

寫成字節碼將是下面這樣：

0: new #2 // Class java/lang/Object 
1: dup 
2: invokespecial #3 // Method java/ lang/Object "<init>"( ) V 

new 操作碼的后面緊跟著操作數 #2 。這個操作數是常量池的一個索引，表示它指向常量池的第二個實體。第二個實體是一個類的引用，這個實體反過來引用了另一個在常量池中包含 UTF8 編碼的字符串類名的實體(// Class java/lang/Object)。然后，這個符號引用被用來尋找 java.lang.Object 類。new 操作碼創建一個類實例并初始化變量。新類實例的引用則被添加到操作數棧。dup 操作碼創建一個操作數棧頂元素引用的額外拷貝。最后用 invokespecial 來調用第 2 行的實例初始化方法。操作碼也包含一個指向常量池的引用。初始化方法把操作數棧出棧的頂部引用當做此方法的一個參數。最后這個新對象只有一個引用，這個對象已經完成了創建及初始化。

如果你編譯下面的類：

package org.jvminternals; 
public class SimpleClass { 
  
 public void sayHello() { 
 System.out.println("Hello"); 
 } 
  
} 

生成的類文件常量池將是這個樣子：

 

 

這個常量池包含了下面的類型：

 

 

異常表

異常表像這樣存儲每個異常處理信息：

• 起始點(Start point)
• 結束點(End point)
• 異常處理代碼的 PC 偏移量
• 被捕獲異常的常量池索引

如果一個方法有定義 try-catch 或者 try-finally 異常處理器，那么就會創建一個異常表。它為每個異常處理器和 finally 代碼塊存儲必要的信息，包括處理器覆蓋的代碼塊區域和處理異常的類型。

當方法拋出異常時，JVM 會尋找匹配的異常處理器。如果沒有找到，那么方法會立即結束并彈出當前棧幀，這個異常會被重新拋到調用這個方法的方法中(在新的棧幀中)。如果所有的棧幀都被彈出還沒有找到匹配的異常處理器，那么這個線程就會終止。如果這個異常在最后一個非守護進程拋出(比如這個線程是主線程)，那么也有會導致 JVM 進程終止。

Finally 異常處理器匹配所有的異常類型，且不管什么異常拋出 finally 代碼塊都會執行。在這種情況下，當沒有異常拋出時，finally 代碼塊還是會在方法最后執行。這種靠在代碼 return 之前跳轉到 finally 代碼塊來實現。

符號表

除了按類型來分的運行時常量池，Hotspot JVM 在永久代還包含一個符號表。這個符號表是一個哈希表，保存了符號指針到符號的映射關系(也就是 Hashtable

引用計數被用來控制一個符號從符號表從移除的過程。比如當一個類被卸載時，它擁有的在常量池中所有符號的引用計數將減少。當符號表中的符號引用計數為 0 時，符號表會認為這個符號不再被引用，將從符號表中卸載。符號表和后面介紹的字符串表都被保存在一個規范化的結構中，以便提高效率并保證每個實例只出現一次。

字符串表

Java 語言規范要求相同的(即包含相同序列的 Unicode 指針序列)字符串字面量必須指向相同的 String 實例。除此之外，在一個字符串實例上調用 String.intern() 方法的返回引用必須與字符串是字面量時的一樣。因此，下面的代碼返回 true：

("j" + "v" + "m").intern() == "jvm" 

Hotspot JVM 中 interned 字符串保存在字符串表中。字符串表是一個哈希表，保存著對象指針到符號的映射關系(也就是Hashtable

當類加載時，字符串字面量被編譯器自動 intern 并加入到符號表。除此之外，String 類的實例可以調用 String.intern() 顯式地 intern。當調用 String.intern() 方法時，如果符號表已經包含了這個字符串，那么就會返回符號表里的這個引用，如果不是，那么這個字符串就被加入到字符串表中同時返回這個引用。