[[337100]]

 JVM運行時數據區的劃分

 

 

線程共享的數據區特征

• 虛擬機啟動時創建，生命周期與進程相同
• 內存分配和回收是動態的，GC負責的區域

線程私有的數據區特征

• 線程啟動時創建，生命周期與線程相同
• 內存的分配和回收都具備確定性，方法結束或線程結束就回收，不需過多考慮回收問題

程序計數器(Program Counter Register)

一塊較小的內存空間，當前線程所執行字節碼的行號指示器。

• 線程私有
• JVM 5大數據區中唯一一個沒有規定OOM的區域
• 執行Java方法時，計數器記錄的是字節碼指令的地址;執行Native方法時，計數器值為空(undefined)

為什么需要程序計數器呢?

JVM 的多線程是通過線程輪流切換并分配CPU時間的方式來實現的，在任何一個確定的時刻，一個處理器(對于多核處理器來說是一個內核)都只會執行一條線程中的指令。因此，為了線程切換后能恢復到正確的執行位置，每條線程都需要有一個獨立的程序計數器。

Java虛擬機棧(Java Virtual Machine Stacks)

虛擬機棧描述的是Java方法執行的內存模型：每個方法在執行的同時都會創建一個棧幀(Stack Frame)用于存儲局部變量表、操作數棧、動態鏈接、方法出口等信息。每一個方法從調用直至執行完成的過程，就對應著一個棧幀在虛擬機棧中入棧到出棧的過程。

 

 

• 線程私有，生命周期與線程相同
• StackOverflowError：棧深度大于虛擬機所允許的深度
• OutOfMemorryError：如果虛擬機棧可以動態擴展(大部分虛擬機可動態擴展，只不過Java虛擬機規范中也允許固定長度的虛擬機棧)，擴展時無法申請足夠內存

經常有人把Java內存區分為堆內存(Heap)和棧內存(Stack)，這種分法比較粗糙，其流行只能說明大多數程序員最關注的、與對象內存分配關系最密切的內存區域是這兩塊。其中所指的『堆』就是后面即將提到的Java堆，而所指的『棧』就是這里的虛擬機棧，或者說是虛擬機棧中局部變量表部分。

局部變量表

局部變量表存放了編譯期可知的各種基本數據類型(boolean、byte、char、short、int、float、long、double)、對象引用(reference)和returnAddress類型(指向了一條字節碼指令的地址)。

局部變量表的容量以變量槽(Variable Slot)為最小單位

64位長度的 long 和 double 類型的數據占用2個slot，其余數據類型只占用1個slot

局部變量表所需內存空間在編譯期已經確定，在方法運行期間不會改變大小

局部變量表的影響

讓我們通過以下示例代碼直觀地感受一下局部變量表的影響。第一個recursion()沒有參數和局部變量，第二個包含3個參數和4個局部變量，因此后者占用更多內存空間，在jvm參數-Xss 128K下分別執行兩個方法：

private static int count=0; 
public static void recursion(){ 
 System.out.println("count="+count); 
 count++; 
 recursion(); 
} 
public static void recursion(int a,int b,int c){ 
 long l1=12; 
 short sl=1; 
 byte b1=1; 
 String s="1"; 
 System.out.println("count="+count); 
 count++; 
 recursion(1,2,3); 
} 

執行第一個無參的recursion()的輸出：

count=4495 
Exception in thread "main" java.lang.StackOverflowError 
at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77) 

執行第二個有參的recursion()的輸出：

count=3865 
Exception in thread "main" java.lang.StackOverflowError 
at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77) 
at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:564) 
at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:619) 

可見，在同等的棧容量下，局部變量少的函數可以支持更深的調用層次，換句話說，一個線程中可調用的方法數就越多。

本地方法棧(Native Method Stack)

本地方法棧與虛擬機棧的作用類似，區別只是前者為執行Native方法服務，后者為執行Java方法服務。有的虛擬機(如Sun HotSpot虛擬機)直接把本地方法棧和虛擬機棧合二為一。

• 線程私有
• 和Java虛擬機棧一樣，也會拋出StackOverflowError 和 OutOfMemorryError

Java堆(Java Heap)

所有的對象實例以及數組都要在堆上分配，但是隨著JIT編譯器的發展與逃逸分析技術逐漸成熟，棧上分配、標量替換優化技術將會導致一些微妙的變化發生，所有的對象都分配在堆上也漸漸變得不是那么"絕對"了。

 

• 線程共享
• OutOfMemorryError：Java heap space
• GC的主要區域，因此也被稱作"GC堆"
• JVM所管理的內存中最大的一塊
• 虛擬機啟動時創建

虛擬機規范對該區的限制

• 可以處于物理上不連續的內存空間中，只要邏輯上連續即可
• 即可以實現成固定大小的，也可以是可擴展的，當前主流虛擬機都是按照可擴展來實現的

方法區(Method Area)

用于存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯后的代碼等數據。

• 線程共享
• OutOfMemorryError：PermGen spage
• GC比較少出現(虛擬機實現時也可以選擇不實現GC，但事實證明該區域的GC是必要的)
• 有一個別名叫"Non-Heap"(非堆)：虛擬機規范中把方法區描述為堆的一個邏輯部分，為了與Java堆區分開來

淺談“永久代”(Permanent Generation)

在HotSpot虛擬機上，很多人都更愿意把方法區稱為“永久代”，但本質上兩者并不等價，僅僅是因為HotSpot虛擬機的設計團隊使用永久代來實現方法區而已。而對于其他虛擬機(如BEA JRockit、IBM J9等)來說是不存在永久代的概念的。目前，在HotSpot虛擬機上也有放棄永久代并逐步改為采用Native Memory來實現方法區的規劃了，在JDK1.7的HotSpot中，已經把原本放在永久代的字符串常量池移出。

虛擬機規范對該區的限制

• 可以處于物理上不連續的內存空間中，只要邏輯上連續即可
• 即可以實現成固定大小的，也可以是可擴展的，當前主流虛擬機都是按照可擴展來實現的
• 可以選擇不實現垃圾收集

垃圾收集行為在方法區是比較少出現的，但并非數據進入了方法區就如永久代的名字一樣“永久”存在了。這里的內存回收目標主要是針對常量池的回收和對類型的卸載，一般來說，這里的回收“成績”難以令人滿意，尤其是類型的卸載，條件相當苛刻，但是這部分區域的回收確實是必要的。

運行時常量池(Runtime Constant Pool)

運行時常量池是方法區的一部分。Class文件中除了有類的版本、字段、方法、接口等描述信息外，還有一項信息是常量池(Constant Pool Table)，用于存放編譯期生成的各種字面量和符號引用，這部分內容將在類加載后進入方法區的運行時常量池中存放。

直接內存

并非虛擬機運行時數據區的一部分，也不是Java虛擬機規范定義的內存區域。但這部分也被頻繁使用，而且也可能導致OOM。

JDK 1.4中加入的NIO類，引入了一種基于通道與緩沖區的I/O方式，它可以使用Native函數庫直接分配堆外內存，然后通過一個存儲在Java堆中的 DirectByteBuffer 對象作為這塊內存的引用進行操作。

本機直接內存的分配不會受到Java堆大小的限制，但還是會受到本機總內存大小以及處理器尋址空間的限制。

5大數據區對比

JVM數據區 私有/共享 創建時機 生命周期 垃圾收集 內存溢出 程序計數器 線程私有 線程啟動時 與線程相同 無 無 虛擬機棧 線程私有 線程啟動時 與線程相同 無 StackOverflowError OutOfMemoryError 本地方法棧 線程私有 線程啟動時 與線程相同 無 StackOverflowError OutOfMemoryError Java堆 線程共享 JVM啟動時 與進程相同 主要區域 OutOfMemoryError: Java heap space 方法區 線程共享 JVM啟動時 與進程相同 較少出現 OutOfMemoryError: PermGen space 對象初探秘

對象的創建

在Java中，從語言層面上來看，創建對象通常只是一個 new 關鍵字而已，而在虛擬機中，對象(這里討論的對象僅限于普通對象，不包括數組和Class對象)的創建又是怎樣一個過程呢?

虛擬機遇到一條 new 指令時：

執行類加載檢查

• 檢查指令的參數是否能在常量池中定位到一個類的符號引用，并檢查這個符號引用代表的類是否已被加載、解析和初始化過。
• 若沒有，則執行相應的類加載過程。

為新生對象分配內存

指針碰撞

假設Java堆中內存是絕對規整的，所有用過的內存放在一邊，空閑的內存放在另一邊，中間放著一個指針作為分界點的指示器，那所分配內存就僅僅是把指針向著空閑內存那邊移動一段與對象大小相等的距離，這種分配方式稱為“指針碰撞”。

空閑列表

如果Java堆中的內存并不是規整的，已使用內存和空閑內存相互交錯，那就沒辦法簡單地進行指針碰撞了，虛擬機就必須維護一個列表，記錄哪些內存塊是可用的，在分配的時候從列表中找出一塊足夠大的空間劃分給對象實例，并更新列表上的記錄，這種分配方式稱為“空閑列表”。

如何選擇分配方式

選擇哪種分配方式由Java堆是否規整決定，而Java堆是否規整又由所采用的垃圾收集器是否帶有 壓縮整理 功能決定。因此，在使用Serial、ParNew等待Compact過程的收集器時，系統采用的分配算法是指針碰撞，而使用CMS這種基于Mark-Sweep算法的收集器時，通常采用空閑列表。

對象的內存布局

在HotSpot虛擬機中，對象在內存中存儲的布局可以分為 3 塊區域：對象頭(Header)、實例數據(Instance Data)、和對齊填充(Padding)。

對象頭

對象頭包括兩部分信息，第一部分用于存儲對象自身的運行時數據，如哈希碼(HashCode)、GC分代年齡、鎖狀態標志等，官方稱這些數據為 “Mark Word” 。

對象頭的另一部分是類型指針，即對象指向它的類元數據的指針，虛擬機通過該指針來確定這個對象是哪個類的實例。但并非所有的虛擬機實現都必須在對象數據上保留類型指針，換句話說，查找對象的元數據信息并不一定要經過對象本身。另外，如果對象是一個Java數組，那在對象頭中還必須有一塊用于記錄數組長度的數據，因為虛擬機可以通過普通對象的元數據確定該對象的大小，但是從數組的元數據中卻無法確定數組的大小。

實例數據

實例數據是對象真正存儲的有效信息，也是在程序代碼中定義的各種類型的字段內容。無論是從父類繼承下來的，還是子類中定義的，都需要記錄。

對齊填充

對齊填充并不是必然存在的，也沒有特別的含義，它僅僅起著占位符的作用。由于HotSpot VM要求對象起始地址必須是8字節的整數倍，話句話說，就是對象大小必須是8字節的整數倍。而對象頭部分正好是8字節的倍數，因此，當對象的實例數據部分沒有對齊時，就需要通過對齊填充來補全。

對象的訪問定位

Java程序需要通過棧(具體是虛擬機棧中的局部變量表)上的reference數據來操作堆上的具體對象。而reference如何定位、訪問堆中對象的具體位置，則取決于不同的虛擬機實現。目前主流的訪問方式有使用 句柄 和 直接指針 兩種。

問題：毫無疑問，局部變量中的reference存放在棧中，那么成員變量中的reference又是存放在哪里?

筆者也是看到這里時感到疑惑，上網查證了很多，但是說法不一，有的認為在棧中(一概而論：對象在堆，引用在棧)，有的認為在堆中(比如https://blog.csdn.net/qq_36596145/article/details/76300922)，筆者認為在方法區中(具體是方法區中的運行時常量池，因為class文件中有一個常量池，用于存放編譯期生成的各種字面量和符號引用，這部分信息在類加載后進入方法區的運行時常量池中存放)。

如果有讀者可以給出明確的結論，還請不吝賜教!

句柄式

在Java堆中劃分出一塊內存用作句柄池，reference中存儲對象的句柄地址，而句柄中包含了對象實例數據與類型數據各自的具體地址信息。

 

 

使用句柄訪問方式的最大好處就是reference中存儲的是穩定的句柄地址，在對象被移動(垃圾收集時移動對象是很普遍的行為)時只會改變句柄中的實例數據指針，而reference本身不需要修改。

直接指針

reference中存儲的直接就是對象地址，此時對象的布局中就必須考慮如何放置對象類型數據的指針。

HotSpot虛擬機采用的就是這種方式。

 

 

使用直接指針訪問方式的最大好處就是速度更快，它節省了一次指針定位的時間開銷。由于對象訪問在Java中非常頻繁，因此這類開銷積少成多后也是一項非常可觀的執行成本。