目錄
- 前言
- Java 記憶體區域
- 程式計數器
- 虛擬機堆疊
- 本地方法堆疊
- 堆
- 方法區
- 字串常量池
- 運行時常量池
- 直接記憶體
- 小結
作者:小牛呼嚕嚕 | https://xiaoniuhululu.com
計算機內功、JAVA底層、面試相關資料等更多精彩文章在公眾號「小牛呼嚕嚕 」
大家好,我是呼嚕嚕,這次我們一起來看看Java記憶體區域,本文 基于HotSpot 虛擬機,JDK8, 干貨滿滿
前言
Java 記憶體區域, 也叫運行時資料區域、記憶體區域、JVM記憶體模型,和 Java 虛擬機(JVM)的運行時區域相關,是指 JVM運行時將資料磁區域存盤,強調對記憶體空間的劃分,
經常與Java記憶體模型(JMM)混淆,其定義了程式中各個變數的訪問規則,即在虛擬機中將變數存盤到記憶體和從記憶體中取出變數這樣的底層細節,
JVM并不是只有唯一版本的,在Java發展歷史中,有許多優秀的Java虛擬機,其中目前大家最熟悉的就是HotSpot虛擬機,什么你不知道?

我們去Oracle官網,下載JDK,其自帶的虛擬機,就是HotSpot,
HotSpot VM的最大特色:熱點代碼探測,其可以通過執行計數器,找出最具有編譯價值的代碼,然后通知JIT編譯器進行編譯,通過編譯器和解釋器的協同合作,在最優程式回應時間和最佳執行性能中取得平衡,

簡單介紹一下,上圖的主要組成部分:
- 類加載器系統:主要用于子系統將編譯好的.class檔案加載到JVM中,了解見:類加載器
- 執行引擎:包括即時編譯器和垃圾回收器,即時編譯器將Java位元組碼編譯成具體的機器碼,垃圾回收器用于回收在運行程序中不再使用的物件
- 本地庫介面:用于呼叫作業系統的本地方法庫,完成具體的指令操作
- 運行時資料區:用于儲存在JVM運行程序中產生的資料,不同的虛擬機在記憶體分配上也略有差異,但總體來說都遵循《Java虛擬機規范》,在《Java虛擬機規范》中規定了五種虛擬機運行時資料區,他們分別為:
程式計數器、Java虛擬機堆疊、本地方法堆疊、本地方法區、堆 以及方法區,下文我們以此圖為基準,詳細地分析各個部分,慢慢道來
Java 記憶體區域
程式計數器
程式計數器(Program Counter Register)是用于存放下一條指令所在單元地址的一塊記憶體,在虛擬機的規范里,位元組碼決議器的作業是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令,分支、回圈、跳轉、例外處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成,
我們來對Java中class檔案反編譯:

在JVM邏輯上規定,程式計數器是一塊較小的記憶體空間,可以看作是當前執行緒所執行位元組碼的行號指示器,PC暫存器,也叫"程式計數器",其是CPU中暫存器的一種,偏硬體概念
由于程式計數器保存了 下一條指令要執行地址,所以在JVM中,執行指令的一般程序:執行引擎會從 程式計數器中獲得下一條指令的地址,拿到其對應的操作指令,對其進行執行,當該指令結束,位元組碼解釋器會根據pc暫存器里的值選取下一條指令并修改pc暫存器里面的值,達到執行下一條指令的目的,周而復始直至程式結束,
位元組碼解釋器可以拿到所有的位元組碼指令執行順序,而程式計數器只是為了記錄當前執行的位元組碼指令地址,防止執行緒切換找不到下一條指令地址
我們知道作業系統中執行緒是由CPU調度來執行指令的,JVM的多執行緒是通過CPU時間片輪轉來實作的,某個執行緒在執行的程序中可能會因為時間片耗盡而掛起,當它再次獲取時間片時,需要從掛起的地方繼續執行,在JVM中,通程序式計數器來記錄程式的位元組碼執行位置,
執行程式在單執行緒情況下還好,但在多執行緒的情況下:執行緒在執行的指令時,CPU可能切換執行緒,去另一個更緊急的指令,執行完再繼續執行先前的指令,特別是單核CPU的情況下,CPU會頻繁的切換執行緒,"同時"執行多個任務,為了CPU切換執行緒后,依舊能恢復到先前指令執行的位置,這就需要每個執行緒有自己獨立的程式計數器,互不影響,我們可以發現程式計數器是執行緒私有的,每條執行緒都有一個程式計數器,
程式計數器是java虛擬機規范中唯一一個沒有規定任何OutofMemeryError(記憶體泄漏)的區域,它的生命周期隨著執行緒的創建而創建,隨著執行緒的結束而死亡,因為當前執行緒正在執行Java中的方法,程式計數器記錄的就是正在執行虛擬機位元組碼指令的地址,如果是Native方法,這個計數器就為空(undefined)
PC暫存器(程式計數器)與JVM中的程式計數器還是有所區別的:
- PC暫存器永遠指向下一條待執行指令的記憶體地址(永遠不會為undefined),并且在程式開始執行前,將程式指令序列的起始地址,即程式的第一條指令所在的記憶體單元地址送入PC, CPU按照PC的指示從記憶體讀取第一條指令(取指)
- 當執行指令時,CPU會自動地修改PC的內容,即每執行一條指令PC增加一個量,這個量等于指令所含的位元組數(指令位元組數),使PC總是指向下一條將要取指的指令地址,
- 由于大多數指令都是按順序來執行的,所以修改PC的程序通常只是簡單的對PC 加“指令位元組數”,當程式轉移時,轉移指令執行的最終結果就是要改變PC的值,此PC值就是轉去的目標地址,處理器總是按照PC指向,取指、譯碼、執行,以此實作了程式轉移,
虛擬機堆疊
虛擬機堆疊(JVM Stacks),和資料結構上的堆疊類似,先進后出,其與程式計數器一樣,也是執行緒私有的,其生命周期和執行緒相同,隨著執行緒的創建而創建,隨著執行緒的死亡而死亡,
虛擬機堆疊描述的是Java方法執行的記憶體模型:每個方法在執行的同時都會創建一個堆疊幀,用于存盤區域變數表、運算元堆疊、動態連接、方法出口等資訊,堆疊幀在虛擬機堆疊中入堆疊到出堆疊(順序: 先進后出)的程序,其實就對應Java中方法的呼叫至執行完成的程序
堆疊幀是用于支持虛擬機進行方法呼叫和方法執行的資料結構,它是虛擬機運行時資料區中的虛擬機堆疊的堆疊元素,每個堆疊幀存盤了方法的變數表、運算元堆疊、動態連接和方法回傳等資訊,

其中:
- 在當前活動執行緒中,只有位于堆疊頂的幀才是有效的,稱為當前堆疊幀,正在執行的方法稱為當前方法,堆疊幀是方法運行的基本結構,在執行引擎運行時,所有指令都只能針對當前堆疊幀進行操作,
- 方法呼叫的資料需要通過堆疊進行傳遞,每一次方法呼叫都會有一個對應的堆疊幀被壓入堆疊中,每一個方法呼叫結束后,都會有一個堆疊幀被彈出,
- 每個堆疊幀包含四個區域:區域變數表、運算元堆疊、動態連接、回傳地址
- 在《Java虛擬機規范》中,對這個記憶體區域規定了兩類例外狀況:
- 如果執行緒請求的堆疊深度大于虛擬機所允許的深度,將拋出
StackOverflowError例外; - 如果Java虛擬機堆疊容量可以動態擴展,當堆疊嘗試擴展時無法申請到足夠的記憶體,或為一個新執行緒初始化JVM堆疊時沒有足夠的記憶體時會拋出
OutOfMemoryError例外,《Java虛擬機規范》明確允許Java虛擬機實作自行選擇是否支持堆疊的動態擴展,HotSpot虛擬機是選擇不支持擴展,所以HotSpot虛擬機在執行緒運行時是不會因為擴展而導致OutOfMemoryError(記憶體溢位)的例外
我們下面主要介紹一下堆疊幀的結構:
- 區域變數表
區域變數表:是存放方法引數和區域變數的區域,主要存放了編譯期可知的各種資料型別(boolean、byte、char、short、int、float、long、double)、物件參考(reference 型別,它不同于物件本身,可能是一個指向物件起始地址的參考指標,也可能是指向一個代表物件的句柄或其他與此物件相關的位置)
我們知道區域變數沒有賦初始值是不能使用的,而全域變數是放在堆的,有兩次賦值的階段,一次在類加載的準備階段,賦予系統初始值;另外一次在類加載的初始化階段,賦予代碼定義的初始值,拓展見:類加載器
區域變數表的容量以 Variable Slot(變數槽)為最小單位,每個變數槽都可以存盤 32 位長度的記憶體空間.基本型別資料以及參考和 returnAddress(回傳地址)占用一個變數槽,long 和 double 需要兩個
在方法執行時,虛擬機使用區域變數表完成引數值到引數變數串列的傳遞程序的,如果執行的是實體方法,那區域變數表中第 0 位索引的 Slot 默認是用于傳遞方法所屬物件實體的參考(在方法中可以通過關鍵字 this 來訪問到這個隱含的引數)其余引數則按照引數表順序排列,占用從 1 開始的區域變數 Slot,關鍵字this詳解
我們可以寫個例子驗證一下
public class Test {
void fun(){
}
}
javac -g:vars Test.java生成Test.class檔案,一定要加引數-g:vars,不然反編譯時,無法顯示區域變數表LocalVariableTable
我們接著反編譯一下:
javap -v Test
Classfile /D:/GiteeProjects/study-java/study/src/com/company/test3/Test.class
Last modified 2022-11-20; size 261 bytes
MD5 checksum 72c7d1fcc5d83dd6fc82c43ae55f2b34
public class com.company.test3.Test
minor version: 0
major version: 52
flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
#1 = Methodref #3.#11 // java/lang/Object."<init>":()V
#2 = Class #12 // com/company/test3/Test
#3 = Class #13 // java/lang/Object
#4 = Utf8 <init>
#5 = Utf8 ()V
#6 = Utf8 Code
#7 = Utf8 LocalVariableTable
#8 = Utf8 this
#9 = Utf8 Lcom/company/test3/Test;
#10 = Utf8 fun
#11 = NameAndType #4:#5 // "<init>":()V
#12 = Utf8 com/company/test3/Test
#13 = Utf8 java/lang/Object
{
public com.company.test3.Test();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this Lcom/company/test3/Test;
void fun();
descriptor: ()V
flags:
Code:
stack=0, locals=1, args_size=1
0: return
LocalVariableTable:
Start Length Slot Name Signature
0 1 0 this Lcom/company/test3/Test; //!!!可以看出this在Slot的第0位!!!
}
- 運算元堆疊
運算元堆疊 主要用于存放方法執行程序中產生的中間計算結果或者臨時變數,通過變數的入堆疊、出堆疊等操作來執行計算,
在方法執行的程序中,會有各種位元組碼指令往運算元堆疊中寫入和提取內容,也就是出堆疊和入堆疊操作,我們前文說的JVM執行引擎,是基于堆疊的執行引擎, 其中的堆疊指的就是運算元堆疊
- 動態鏈接
每個堆疊幀都保存了 一個 可以指向當前方法所在類的 運行時常量池, 目的是: 當前方法中如果需要呼叫其他方法的時候, 能夠從運行時常量池中找到對應的符號參考, 然后將符號參考轉換為直接參考,然后就能直接呼叫對應方法, 這就是動態鏈接,本質就是,在方法運行時將符號參考轉為呼叫方法的直接參考,這種參考轉換的程序具備動態性
不是所有方法呼叫都需要動態鏈接的, 有一部分符號參考會在 類加載階段, 將符號參考轉換為直接參考, 這部分操作稱之為: 靜態決議. 就是編譯期間就能確定呼叫的版本, 包括: 呼叫靜態方法, 呼叫實體的私有構造器, 私有方法, 父類方法

- 回傳地址
Java 方法有兩種回傳方式:
- 正常退出,即正常執行到任何方法的回傳位元組碼指令,如 return等;
- 例外退出
無論何種退出情況,都將回傳至方法當前被呼叫的位置,方法退出的程序相當于彈出當前堆疊幀
我們可以發現:堆疊幀隨著方法呼叫而創建,隨著方法結束而銷毀,無論方法正常完成還是例外完成都算作方法結束.
本地方法堆疊
本地方法堆疊(Native Method Stack):是執行緒私有的,其與虛擬機堆疊的作用基本是一樣的,有點區別的是:虛擬機堆疊是服務Java方法的,而本地方法堆疊是為虛擬機呼叫Native方法服務的,通過 JNI (Java Native Interface) 直接呼叫本地 C/C++ 庫,不再受JVM控制,
JNI 類本地方法最著名的應該是 System.currentTimeMillis() ,JNI使 Java 深度使用作業系統的特性功能,復用非 Java 代碼, 當大量本地方法出現時,勢必會削弱 JVM 對系統的控制力
本地方法被執行的時候,在本地方法堆疊也會創建一個堆疊幀,用于存放該本地方法的區域變數表、運算元堆疊、動態鏈接、出口資訊,方法執行完畢后相應的堆疊幀也會出堆疊并釋放記憶體空間,與虛擬機堆疊一樣,本地方法堆疊區域也會拋出StackOverflowError和OutOfMemoryError
另外在Java虛擬機規范中對于本地方法堆疊沒有特殊的要求,虛擬機可以自由的實作它,因此在HotSpot虛擬機直接把本地方法堆疊和虛擬機堆疊合二為一了,因此對于HotSpot來說,-Xoss引數(設定 本地方法堆疊大小)雖然存在,但實際上是沒有任何效果的,堆疊容量只能由-Xss引數來設定,
堆
堆(Heap)是Java虛擬機所管理的最大的一塊記憶體區域,是被所有執行緒共享的,Java堆唯一的目的就是存放物件實體,幾乎所有的物件實體都在堆上分配記憶體,但是隨著JIT編譯器的發展和逃逸分析技術的逐漸成熟,堆疊上分配、執行緒本地分配快取(TLAB)也可以存放物件實體
Java虛擬機規范規定,Java堆可以處在物理上不連續的記憶體空間中,只要邏輯上連續即可,當前主流的虛擬機都是按照可擴展來實作的(通過 -Xmx 和 -Xms 控制),如果在堆中沒有記憶體完成實體分配,并且堆也無法再擴展時,將會拋出 OutOfMemoryError 例外,
方法區
方法區(Methed Area)用于存盤已被虛擬機加載的類資訊、常量、靜態變數、即時編譯后的代碼等資料,其是所有執行緒共享的記憶體區域,
在Java 虛擬機規范把方法區描述為堆的一個邏輯部分,但是它卻有一個別名叫做 Non-Heap(非堆),與 Java 堆區分開來,
方法區是JVM規范的一個概念定義,并不是一個具體的實作,由于Java虛擬機對于方法區的限制是非常寬松的,因此也就導致了不同的虛擬機上方法區有不同的表現,我們還是以HotSpot虛擬機為例:
- 在JDK8前,HotSpot 虛擬機對Java虛擬機規范中方法區的實作方式是永久代
- 在JDK8及其以后,HotSpot 虛擬機對Java虛擬機規范中方法區的實作方式變成了元空間
網上許多文章喜歡拿"永久代"或者"元空間" 來代替方法區,但本質上兩者并不等價,方法區是Java虛擬機規范的概念,"永久代"或者"元空間"是方法區的2中實作方式
方法區在JDK7之前是一塊單獨的區域,HotSpot虛擬機的設計團隊把GC分代收集擴展到了方法區,這樣HotSpot的垃圾收集器就可以向管理Java堆一樣管理這部分記憶體,但是對于其它虛擬機(如BEA JRockit、IBM J9等)來說其實是不存在永久代的概念的,
HotSpot的團隊顯然也意識到了,用永久代來實作方法區并不是一個好主意:
- 字串存在永久代中,容易出現性能問題和記憶體溢位
- 類及方法的資訊等比較難確定其大小,因此對于永久代的大小指定比較困難,太小容易出現永久代溢位,太大則容易導致老年代溢位,
- 永久代會為 GC 帶來不必要的復雜度,并且回收效率偏低,
因此,在JDK1.8中完全廢除了“永久代”,使用元空間替代了永久代,其他內容移至元空間,元空間直接在本地記憶體分配,
當方法區無法滿足記憶體分配需求時,將拋出OutOfMemoryError例外,元空間是使用直接記憶體實作的,我們下文再詳細說,
Java記憶體區域大致就這些了,下面我們再補充幾個比較讓人迷惑的概念
字串常量池
字串屬于參考資料型別,但是可以說字串是Java中使用頻繁的一種資料型別,因此,為了節省程式記憶體,提高性能,Java的設計者開辟了一塊叫字串常量池的區域,用來存盤這些字串,避免字串的重復創建,字串常量池是所有類公用的一塊空間,在一個虛擬機中只有一塊常量池區域,
在類加載完成,經過驗證,準備階段之后在堆中生成字串物件實體,然后將該字串物件實體的參考值存到字串常量池中(這里描述指的是JDK7及以后的HotSpot虛擬機), 在HotSpot虛擬機中字串常量池是通過一個StringTable類來實作的,它是一個哈希表,里面存的是字串參考
在JDK7以前,字串常量池在方法區(永久代)中,此時常量池中存放的是字串物件,而在JDK7及其以后中,字串常量池從方法區遷移到了堆記憶體,同時將字串物件存到了堆記憶體,只在字串常量池中存入了字串物件的參考,
在JDK7 就已經開始了HotSpot 的永久代的移除作業,主要由于永久代的 GC 回收效率太低,等到JDK 8 的時候,永久代被徹底移除了
Java 程式中通常會有大量的被創建的字串等待回收,將字串常量池放到堆中,能夠更高效及時地回收字串記憶體,
運行時常量池
運行時常量池(Runtime Constant Pool)是方法區的一部分,我們知道Class 檔案中除了有類的版本、欄位、方法、介面等常見描述資訊外,但還有一項資訊是常量池(Constant Pool Table),用于存放編譯期生成的各種字面量,符號參考還有翻譯出來的直接參考,這部分內容將在類加載后進入方法區的運行時常量池中存放,因此,每一個類都會有一個運行時常量池
因為Java語言并不要求常量一定在編譯期間才能生成,也就是并非預置入Class檔案常量池中的內容才能進入運行時常量池,運行期間也可以將新的常量放入常量池中,運行時常量池另外一個重要特征是具備動態性,
既然運行時常量池是方法區的一部分,自然受到方法區記憶體的限制,當常量池無法再申請到記憶體時會拋出 OutOfMemoryError 例外,
直接記憶體
JDK 8 版本之后 永久代已被元空間取代,元空間使用的就是直接記憶體,直接記憶體(Direct Memory)并不是Java虛擬機運行時資料區的一部分,也不是 Java 虛擬機規范中定義的記憶體區域,
在 JDK 1.4 中新加入了 NIO,引入了一種基于通道(Channel)與緩沖區(Buffer)的 I/O 方式,它可以使用 Native 函式庫直接分配堆外記憶體,然后通過一個存盤在 Java 堆中的 DirectByteBuffer 物件作為這塊記憶體的參考進行操作,這樣能在一些場景中顯著提高性能,因為避免了在 Java 堆和 Native 堆中來回復制資料,
顯然,本機直接記憶體的分配不會受到 Java 堆大小的限制,但是,既然是記憶體,肯定還是會受到本機總記憶體(包括 RAM 以及 SWAP 區或者分頁檔案)大小以及處理器尋址空間的限制,服務器管理員在配置虛擬機引數時,會根據實際記憶體設定 -Xmx 等引數資訊,但經常忽略直接記憶體,使得各個記憶體區域總和大于物理記憶體限制(包括物理的和作業系統級的限制),從而導致動態擴展時出現 OutOfMemoryError 例外,
小結
- 執行緒私有區域(包括 程式計數器, 虛擬機堆疊, 本地方法堆疊),生命周期跟隨執行緒的啟動而創建,隨執行緒的結束而銷毀
- 執行緒共享區域(包括 方法區 和 堆 ),生命周期跟隨虛擬機的啟動而創建,隨虛擬機的關閉而銷毀

參考資料:
《深入理解 Java 虛擬機:JVM 高級特性與最佳實踐》
《On Java 8》
https://www.cnblogs.com/newAndHui/p/11168791.html
https://blog.csdn.net/qq_20394285/article/details/104673913
https://www.cnblogs.com/czwbig/p/11127124.html
本篇文章到這里就結束啦,很感謝你能看到最后,如果覺得文章對你有幫助,別忘記關注我!更多精彩的文章
計算機內功、JAVA底層、面試相關資料等更多精彩文章在公眾號「小牛呼嚕嚕 」

轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/541544.html
標籤:其他
