目錄

一、運行時資料區域

1.1 程式計數器

1.2 虛擬機堆疊

1.2.1 區域變數表

1.3 本地方法堆疊

1.4 堆

1.5 方法區

1.5.1 運行時常量池

1.5.2 本地直接記憶體

二、HotSpot 虛擬機物件探秘

2.1 物件的創建

2.1.1 記憶體空間分配

2.2 物件記憶體布局

2.2.1 物件頭

2.2.2 實體資料

2.2.3 對齊填充

2.3 物件的訪問定位

2.3.1 句柄

2.3.2 直接指標

三、總結

一、運行時資料區域

Java虛擬機在執行Java程式的程序中，會把它所管理的記憶體劃分為若干個不同的資料區域，這些區域各有各自的用途，以及創建和銷毀時間，

1.1 程式計數器

一塊較小的，執行緒私有的記憶體空間，可以看做是當前程式執行的位元組碼的行號指示器，在虛擬機的概念模型里（僅僅是概念模型，各個虛擬機可能會通過一些更高效的方式去實作），位元組碼解釋器作業時就是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令，分支、回圈、跳轉、例外處理、執行緒恢復等都需要依賴它完成，

注：為了執行緒切換后能恢復到正確的執行位置，每個執行緒都需要一個獨立的程式計數器，所以這塊記憶體區域執行緒私有，

如果執行緒正在執行Java方法，那這個計數器記錄的是正在執行的虛擬機位元組碼指令的地址；如果正在執行Native方法，則這個計數器為空(Undefined)，此記憶體區域是唯一一個在Java虛擬機規范中沒有規定任何OutOfMemoryError情況的區域，

1.2 虛擬機堆疊

執行緒私有，它的生命周期與執行緒相同，虛擬機堆疊描述的是Java方法執行的記憶體模型：每個方法在執行的同時都會創建一個堆疊幀(Stack Frame)用于存盤區域變數表、運算元堆疊、動態鏈接、方法出入口等資訊，每一個方法從呼叫到執行完成的程序，就對應一個堆疊幀在虛擬機堆疊中從入堆疊到出堆疊的程序，

在Java虛擬機規范中，對虛擬機堆疊規定了兩種例外狀況：如果執行緒請求的堆疊深度大于虛擬機所允許的深度（比如過度遞回），拋出StackOverflowError例外；如果虛擬機堆疊擴展時無法申請到足夠的記憶體，拋出OutOfMemoryError例外，

1.2.1 區域變數表

區域變數表存放了編譯期可知的各種基本資料型別(byte、short等)、物件參考(reference型別)，其中64位長度的long和double型別會占用2個區域變數表空間（Slot）,其余的資料型別只占用一個，區域變數表所需要的記憶體空間在編譯期完成分配，在進入方法時是完全確定的，方法運行期間也不會改變區域變數表的大小，

1.3 本地方法堆疊

與虛擬機堆疊的作用類似，區別是虛擬機堆疊為虛擬機執行Java方法（也就是位元組碼）服務，而本地方法堆疊為虛擬機使用到的Native方法服務，Java虛擬機規范沒有對本地方法堆疊中使用的語言、使用方式和資料結構等做強制規定，因此虛擬機可以自由實作它，有的虛擬機直接將本地方法堆疊和虛擬機堆疊合并，比如Sun HotSpot，和虛擬機堆疊一樣，可能拋出StackOverflowErro或OutOfMemoryError，

1.4 堆

所有執行緒共享，在虛擬機啟動時創建，幾乎所有的物件實體都在這里分配記憶體（由于堆疊上分配、標量替換等技術的發展，比如逃逸分析，并不是所有物件都在堆上分配），

Java堆是GC的主要區域，站在GC的角度，還細分為新生代和老年代，新生代還可以分為Eden空間、From Survivor空間和To Survivor空間（可參考Hot Spot虛擬機新生代為什么是一個eden+2個survivor），而站在記憶體分配的角度來看，Java堆中可能劃分出多個執行緒私有的分配緩沖區（Thread Local Allocation Buffer，TLAB，主要為了解決分配記憶體時的并發問題），

根據Java虛擬機規范的規定，Java堆可以處于物理上不連續的記憶體空間中，只要邏輯上連續即可，當前主流虛擬機的實作都是可擴展的(通過-Xmx和-Xms控制)，如果實體分配時，堆中沒有可用空間，也無法再擴展時，將會拋出OutOfMemoryError，

1.5 方法區

所有執行緒共享，它用于存盤已被虛擬機加載的類資訊、常量、靜態變數、即時編譯器編譯后的代碼等資料，Java虛擬機規范將其描述為堆的一個邏輯部分，但是它有一個別名叫做Non-Heap(非堆)，目的是與Java堆區分開，

方法區和永久代并不等價，只是HotSpot虛擬機選擇把GC分代收集擴展至方法區，也就是用永久代來實作方法區，這樣垃圾收集器就能像管理Java堆一樣管理這部分記憶體，而不用再專門去為方法區撰寫記憶體管理代碼，如何實作方法區屬于虛擬機實作細節，不受虛擬機規范約束，而對于其它虛擬機來說是沒有永久代的概念的，

這個區域的記憶體回收目標主要是針對常量池的回收和對型別的卸載，當方法區無法滿足記憶體分配需求時，拋出OutOfMemoryError，

永久代有-XX:MaxPermSize的上限，以永久代來實作方法區容易出現記憶體溢位，少數方法（比如String.intern()）會導致在不同的虛擬機中有不同的表現，所以在JDK1.7中，原本位于方法區的字串常量池被移到Java堆（邏輯上）中，而在JDK1.8之后，方法區已被元空間（MetaSpace，本地直接記憶體）取代，

注：可以認為永久代和元空間是方法區的不同實作方式，而方法區是Java虛擬機規范中的概念模型，

1.5.1 運行時常量池

運行時常量池是方法區的一部分，Class檔案中除了有類的版本、欄位、方法、介面等描述資訊外，還有一項資訊是常量池，用于存放編譯期生成的各種字面量和符號參考，這部分內容將在類加載后進入方法區的運行時常量池存放，對于運行時常量池，Java虛擬機規范沒有做什么細節上的要求，不同的虛擬機可以根據自己的需要來實作這個記憶體區域，

運行時常量池具備動態性，常量不一定只有編譯期才產生，也就是并非只有預置入Class檔案中的常量池的內容才能進入方法區運行時常量池，運行時也可以將新的常量放入池中，比如使用String.intern()方法，

1.5.2 本地直接記憶體

本地直接記憶體不是虛擬機運行時資料區域的一部分，也不是Java虛擬機規范中定義的記憶體區域，但是也可能導致OutOfMemoryError出現，NIO引入的一種基于通道(Channel)和緩沖區(Buffer)的I/O方式，可以使用Native函式庫直接分配對外記憶體，然后通過一個存盤在Java堆中的DirectByteBuffer物件作為這塊記憶體的參考進行操作，

本地直接記憶體的分配不受Java堆大小的限制，但是會受到本機總記憶體大小（包括RAM以及SWAP磁區或者分頁檔案）以及處理器尋址空間的限制，

二、HotSpot 虛擬機物件探秘

2.1 物件的創建

當虛擬機遇到一條new指令時，首先檢查這個指令的引數是否能在常量池中定位到一個類的符號參考，并檢查這個符號參考代表的類是否已經被加載、決議和初始化過，如果沒有，那么執行類加載程序，（類加載檢查）

在類加載檢查通過后，虛擬機將會為新生物件分配記憶體，所需的記憶體大小在內加載完成后便可確定，記憶體分配完成之后，虛擬機需要將分配到的記憶體都初始化為零值（不包括物件頭），這一步操作保證了物件的實體欄位在Java代碼中可以不賦初始值就可直接使用，程式能訪問到這些欄位的資料型別所對應的零值，（分配記憶體，初始化零值）

接下來，虛擬機對物件進行必要的設定，比如物件的哈希碼、GC分代年齡、模板類等等，這些資訊存放在物件的物件頭之中，（設定物件頭）

此時，一個新的物件已經產生，但是<init>方法（編譯自動生成的實體構造器方法）還沒有執行，所有的欄位都還為零值，所以一般來說（由位元組碼中是否跟隨invokespecial指令決定），執行new指令之后會接著執行<init>方法，把物件按照程式員的意愿進行初始化，（執行<init>方法）

2.1.1 記憶體空間分配

指標碰撞：假設Java堆中的記憶體是絕對規整的，所有用過的記憶體都放在一邊，空閑的記憶體放在另外一邊，中間放著一個指標作為分界點的指示器，那分配記憶體就是把那個指標向空閑空間那邊挪動一段與物件大小相等的距離，

空閑串列：如果Java堆中的記憶體不是規整的，那虛擬機就必須維護一個記錄了哪些記憶體塊可用的一個串列，在分配時從串列中找到一塊足夠大的空間劃分給物件實體，并更新串列上的記錄，

選擇哪種分配方式由Java堆是否規整決定，而Java堆是否規整由采用的垃圾收集器是否帶有壓縮整理功能決定，

另外，記憶體分配的操作本身不具備原子性，其在并發情況下可能出現執行緒安全問題，可能出現正在給物件A分配記憶體，指標還沒來得及修改，物件B又同時使用了原來的指標來分配記憶體的情況，解決這個問題有兩個方案：

方案1. 采用CAS配上失敗重試的方式保證更新操作的原子性，

方案2. 每個執行緒在Java堆中都預先分配一小塊記憶體（本地執行緒分配緩沖，Thread Local Allocation Buffer，TLAB）,哪個執行緒要分配記憶體，就在自己的TLAB上分配，當TLAB用完并分配新的TLAB時，才需要同步鎖定，虛擬機是否使用TLAB，可通過-XX+/-UseTLAB引數設定，

2.2 物件記憶體布局

在HotSpot虛擬機中，物件的記憶體布局分為3個區域：物件頭、實體資料和對齊填充，

2.2.1 物件頭

物件頭包含兩部分資訊：

一部分用于存盤物件自身的運行時資料，如哈希碼、GC分代年齡、鎖狀態標識、執行緒持有的鎖、偏向執行緒ID、偏向時間戳等等，這部分資料長度在32位和64位虛擬機(未開啟壓縮指標)中分別為32bit和64bit，官方稱之為“Mark Word”，考慮到空間效率，其被設計成一個非固定的資料結構以便在極小的空間記憶體儲盡量多的資訊，它會根據物件的狀態復用自己的存盤空間，

另一部分是型別指標，即物件指向它的類元資料的指標，虛擬機通過這個指標來確定這個物件是哪個類的實體，但是并不是所有的虛擬機實作都必須在物件資料上保留型別指標，查找物件的元資料資訊不一定非要經過物件本身（采取句柄方式訪問物件，句柄分別包含物件的實體資料和型別資料各自的地址資訊），

注：如果一個物件是Java陣列，那在物件頭中還必須有一塊用于記錄陣列長度的空間，因為虛擬機可以通過普通Java物件的元資料資訊確定Java物件的大小，但是從陣列的元資料中無法確定陣列的大小，

2.2.2 實體資料

物件真正存盤的有效資訊，也就是程式代碼中所定義的各種型別的欄位內容，包括從父類繼承的和子類中定義的欄位，這些欄位會按照順序存盤下來，而具體的存盤順序會受到虛擬機分配策略引數和欄位在代碼中定義順序的影響，默認為longs/doubles、ints、shorts/chars、bytes/booleans、references，可以看到，相同寬度的欄位總是被分配到一起，在滿足整個前提的情況下，父類中的欄位會出現在子類之前，如果開啟了CompactFields，那么子類中較窄的欄位可能會插入到父類欄位的空隙之中，

簡單來說就是，大欄位在前，小欄位在后，references最后，同大小看宣告順序，然后在考慮父類和CompactFields的情況，（詳情可見Java物件記憶體布局概述）

2.2.3 對齊填充

不是必須存在的，只是起占位符的作用，比如Hot Spot虛擬機要求物件大小必須是8位元組的整數倍，而物件頭部分剛好是8位元組的倍數，所以當物件的實體資料沒有對齊時，就需要通過對齊填充來補全，

2.3 物件的訪問定位

目前主流的訪問方式有使用句柄和直接指標兩種，

2.3.1 句柄

Java堆中會劃分出一塊記憶體作為句柄池，reference中存盤的就是物件的句柄地址，而句柄中包含了物件實體資料和型別資料的地址資訊（此時物件頭中不再需要型別指標），好處是在物件被移動時，只會改變句柄中的實體資料指標，而reference本身不需要修改，而且，GC時移動物件是非常普遍的行為，但是訪問物件實體時，需要經過兩次指標定位，

2.3.2 直接指標

reference中存盤的直接就是物件的地址，訪問型別資料資訊需要存盤在物件頭之中，好處是相對于句柄節約了一次指標定位的開銷，速度更快，HotSpot使用的就是直接指標的物件訪問方式，

三、總結

本章介紹了Java虛擬機運行時資料區域劃分，同時以HotSpot虛擬機為例介紹了物件實體的分配和初始化程序、物件的記憶體布局和訪問定位方式，另外還以代碼實體復現了各個區域的記憶體溢位例外，