[[337100]]

 JVM運行時數(shù)據(jù)區(qū)的劃分

線程共享的數(shù)據(jù)區(qū)特征

• 虛擬機啟動時創(chuàng)建，生命周期與進程相同
• 內(nèi)存分配和回收是動態(tài)的，GC負責的區(qū)域

線程私有的數(shù)據(jù)區(qū)特征

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

程序計數(shù)器(Program Counter Register)

一塊較小的內(nèi)存空間，當前線程所執(zhí)行字節(jié)碼的行號指示器。

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

為什么需要程序計數(shù)器呢?

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

Java虛擬機棧(Java Virtual Machine Stacks)

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

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

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

局部變量表

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

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

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

局部變量表所需內(nèi)存空間在編譯期已經(jīng)確定，在方法運行期間不會改變大小

局部變量表的影響

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

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); 
} 

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

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

執(zhí)行第二個有參的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) 

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

本地方法棧(Native Method Stack)

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

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

Java堆(Java Heap)

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

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

虛擬機規(guī)范對該區(qū)的限制

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

方法區(qū)(Method Area)

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

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

淺談“永久代”(Permanent Generation)

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

虛擬機規(guī)范對該區(qū)的限制

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

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

運行時常量池(Runtime Constant Pool)

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

直接內(nèi)存

并非虛擬機運行時數(shù)據(jù)區(qū)的一部分，也不是Java虛擬機規(guī)范定義的內(nèi)存區(qū)域。但這部分也被頻繁使用，而且也可能導致OOM。

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

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

5大數(shù)據(jù)區(qū)對比

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

對象的創(chuàng)建

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

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

執(zhí)行類加載檢查

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

為新生對象分配內(nèi)存

指針碰撞

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

空閑列表

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

如何選擇分配方式

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

對象的內(nèi)存布局

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

對象頭

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

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

實例數(shù)據(jù)

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

對齊填充

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

對象的訪問定位

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

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

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

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

句柄式

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

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

直接指針

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

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

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