史上最詳細JVM，Java記憶體區域講解
本人免費整理了Java高階資料一共30G，需要自己領取；
傳送門：https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q
執行時資料區域
JVM載執行Java程式的過程中會把它所管理的記憶體劃分為若干個不同的資料區域。這些區域都有各自的用途，以及建立和銷燬的時間，有的區域隨著虛擬機器程序的啟動而存在，有些區域則是依賴使用者執行緒的啟動和結束而建立和銷燬。具體如下圖所示：
程式計數器（Program Counter Register）
程式計數器（Program Counter Register）
程式計數器是一塊“執行緒私有”的記憶體，如上文的圖所示，每條執行緒都有一個獨立的程式計數器，各條執行緒之間的計數器互不影響，獨立儲存。這樣設計使得在多執行緒環境下，執行緒切換後能恢復到正確的執行位置。
如果執行緒正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；若執行的是Native方法，則計數器為空（Undefined）
Java虛擬機器棧（Java Virtual Machine Stacks）
Java虛擬機器棧（Java Virtual Machine Stacks）描述的是Java方法執行的記憶體模型：每個方法在執行的同時都會建立一個棧幀（Stack Frame），棧幀中儲存著區域性變量表、運算元棧、動態連結、方法出口等資訊。每一個方法從呼叫直至執行完成的過程，會對應一個棧幀在虛擬機器棧中入棧到出棧的過程。
函式的呼叫有完美的巢狀關係——呼叫者的生命期總是長於被呼叫者的生命期，並且後者在前者的之內。這樣，被呼叫者的區域性資訊所佔空間的分配總是後於呼叫者的（後入），而其釋放則總是先於呼叫者的（先出），所以正好可以滿足棧的LIFO順序，選用棧這種資料結構來實現呼叫棧是一種很自然的選擇。
區域性變量表中存放了編譯期可知的各種：
- 基本資料型別(boolen、byte、char、short、int、 float、 long、double）
- 物件引用（reference型別，它不等於物件本身，可能是一個指向物件起始地址的指標，也可能是指向一個代表物件的控制代碼或其他與此物件相關的位置）
- returnAddress型別（指向了一條位元組碼指令的地址）
其中64位長度的long和double型別的資料會佔用2個區域性變數空間（Slot），其餘資料型別只佔用1個。區域性變量表所需的記憶體空間在編譯期間完成分配，當進入一個方法時，這個方法需要在幀中分配多大的區域性變數空間是完全確定的，在方法執行期間不會改變區域性變量表的大小。
Java虛擬機器規範中對這個區域規定了兩種異常狀況：
- StackOverflowError：執行緒請求的棧深度大於虛擬機器所允許的深度，將會丟擲此異常。
- OutOfMemoryError：當可動態擴充套件的虛擬機器棧在擴充套件時無法申請到足夠的記憶體，就會丟擲該異常。
本地方法棧（Native Method Stack）
本地方法棧（Native Method Stack）與Java虛擬機器棧作用很相似，它們的區別在於虛擬機器棧為虛擬機器執行Java方法（即位元組碼）服務，而本地方法棧則為虛擬機器使用到的Native方法服務。
在虛擬機器規範中對本地方法棧中使用的語言、方式和資料結構並無強制規定，因此具體的虛擬機器可實現它。甚至有的虛擬機器（Sun HotSpot虛擬機器）直接把本地方法棧和虛擬機器棧合二為一。與虛擬機器一樣，本地方法棧會丟擲StackOverflowError和OutOfMemoryError異常。
Java堆（Heap）
對於大多數應用而言，Java堆（Heap）是Java虛擬機器所管理的記憶體中最大的一塊，它被所有執行緒共享的，在虛擬機器啟動時建立。此記憶體區域唯一的目的是存放物件例項，幾乎所有的物件例項都在這裡分配記憶體，且每次分配的空間是不定長的。在Heap 中分配一定的記憶體來儲存物件例項，實際上只是儲存物件例項的屬性值，屬性的型別和物件本身的型別標記等，並不儲存物件的方法（方法是指令，儲存在Stack中）,在Heap 中分配一定的記憶體儲存物件例項和物件的序列化比較類似。物件例項在Heap 中分配好以後，需要在Stack中儲存一個4位元組的Heap 記憶體地址，用來定位該物件例項在Heap 中的位置，便於找到該物件例項。
Java虛擬機器規範中描述道：所有的物件例項以及陣列都要在堆上分配，但是隨著JIT編譯器的發展和逃逸分析技術逐漸成熟，棧上分配、標量替換優化技術將會導致一些微妙的變化發生，所有的物件都在堆上分配的定論也並不“絕對”了。
Java堆是垃圾收集器管理的主要區域，因此也被稱為“GC堆（Garbage Collected Heap）”。從記憶體回收的角度看記憶體空間可如下劃分：
- 新生代（Young）： 新生成的物件優先存放在新生代中，新生代物件朝生夕死，存活率很低。在新生代中，常規應用進行一次垃圾收集一般可以回收70% ~ 95% 的空間，回收效率很高。新生代又可細分為Eden空間、From Survivor空間、To Survivor空間，預設比例為8:1:1。它們的具體作用將在下一篇文章講解GC時介紹。
- 老年代（Tenured/Old）：在新生代中經歷了多次（具體看虛擬機器配置的閥值）GC後仍然存活下來的物件會進入老年代中。老年代中的物件生命週期較長，存活率比較高，在老年代中進行GC的頻率相對而言較低，而且回收的速度也比較慢。
- 永久代（Perm）：永久代儲存類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料，對這一區域而言，Java虛擬機器規範指出可以不進行垃圾收集，一般而言不會進行垃圾回收。
其中新生代和老年代組成了Java堆的全部記憶體區域，而永久代不屬於堆空間，它在JDK 1.8以前被Sun HotSpot虛擬機器用作方法區的實現，關於方法區的具體內容將在稍後介紹。
方法區（Method Area）
方法區（Method Area）與Java堆一樣，是各個執行緒共享的記憶體區域。Object Class Data(類定義資料)是儲存在方法區的，此外，常量、靜態變數、JIT編譯後的程式碼也儲存在方法區。正因為方法區所儲存的資料與堆有一種類比關係，所以它還被稱為 Non-Heap。
JDK 1.8以前的永久代（PermGen）
Java虛擬機器規範對方法區的限制非常寬鬆，除了和Java堆一樣不需要連續的記憶體和可以選擇固定大小或者可擴充套件外，還可以選擇不實現垃圾收集，也就是說，Java虛擬機器規範只是規定了方法區的概念和它的作用，並沒有規定如何去實現它。對於JDK 1.8之前的版本，HotSpot虛擬機器設計團隊選擇把GC分代收集擴充套件至方法區，即用永久代來實現方法區，這樣HotSpot的垃圾收集器可以像管理Java堆一樣管理這部分記憶體，能夠省去專門為方法區編寫記憶體管理程式碼的工作。對於其他的虛擬機器（如Oracle JRockit、IBM J9等）來說是不存在永久代的概念的。
如果執行時有大量的類產生，可能會導致方法區被填滿，直至溢位。常見的應用場景如：
- Spring和ORM框架使用CGLib操縱位元組碼對類進行增強，增強的類越多，就需要越大的方法區來保證動態生成的Class可以載入入記憶體。
- 大量JSP或動態產生JSP檔案的應用（JSP第一次執行時需要編譯為Java類）。
- 基於OSGi的應用（即使是同一個類檔案，被不同的類載入器載入也會視為不同的類）。 ……
這些都會導致方法區溢位，報出java.lang.OutOfMemoryError: PermGen space。
JDK 1.8的元空間（Metaspace）
在JDK 1.8中，HotSpot虛擬機器設計團隊為了促進HotSpot與 JRockit的融合，修改了方法區的實現，移除了永久代，選擇使用本地化的記憶體空間（而不是JVM的記憶體空間）存放類的元資料，這個空間叫做元空間（Metaspace）。
做了這個改動以後，java.lang.OutOfMemoryError: PermGen的空間問題將不復存在，並且不再需要調整和監控這個記憶體空間。且虛擬機器需要為方法區設計額外的GC策略：如果類元資料的空間佔用達到引數“MaxMetaspaceSize”設定的值，將會觸發對死亡物件和類載入器的垃圾回收。 為了限制垃圾回收的頻率和延遲，適當的監控和調優元空間是非常有必要的。元空間過多的垃圾收集可能表示類、類載入器記憶體洩漏或對你的應用程式來說空間太小了。
元空間的記憶體管理由元空間虛擬機器來完成。先前，對於類的元資料我們需要不同的垃圾回收器進行處理，現在只需要執行元空間虛擬機器的C++程式碼即可完成。在元空間中，類和其元資料的生命週期和其對應的類載入器是相同的。話句話說，只要類載入器存活，其載入的類的元資料也是存活的，因而不會被回收掉。
我們從行文到現在提到的元空間稍微有點不嚴謹。準確的來說，每一個類載入器的儲存區域都稱作一個元空間，所有的元空間合在一起就是我們一直說的元空間。當一個類載入器被垃圾回收器標記為不再存活，其對應的元空間會被回收。在元空間的回收過程中沒有重定位和壓縮等操作。但是元空間內的元資料會進行掃描來確定Java引用。
元空間虛擬機器負責元空間的分配，其採用的形式為組塊分配。組塊的大小因類載入器的型別而異。在元空間虛擬機器中存在一個全域性的空閒組塊列表。當一個類載入器需要組塊時，它就會從這個全域性的組塊列表中獲取並維持一個自己的組塊列表。當一個類載入器不再存活，那麼其持有的組塊將會被釋放，並返回給全域性組塊列表。類載入器持有的組塊又會被分成多個塊，每一個塊儲存一個單元的元資訊。組塊中的塊是線性分配（指標碰撞分配形式）。組塊分配自記憶體對映區域。這些全域性的虛擬記憶體對映區域以連結串列形式連線，一旦某個虛擬記憶體對映區域清空，這部分記憶體就會返回給作業系統。
上圖展示的是虛擬記憶體對映區域如何進行元組塊的分配。類載入器1和3表明使用了反射或者為匿名類載入器，他們使用了特定大小組塊。 而類載入器2和4根據其內部條目的數量使用小型或者中型的組塊。
執行時常量池（Runtime Constant Pool）
執行時常量池（Runtime Constant Pool）是方法區的一部分。Class檔案中除了有類的版本、欄位、方法、介面等描述資訊外，還有一項資訊是常量池（Constant Pool Table），用於存放編譯期生成的各種字面量和符號引用，這部分內容將在類載入後進入方法區的執行時常量池存放。
Java虛擬機器對Class檔案每一部分（自然包括常量池）的格式有嚴格規定，每一個位元組用於儲存那種資料都必須符合規範上的要求才會被虛擬機器認可、裝載和執行。但對於執行時常量池，Java虛擬機器規範沒有做任何有關細節的要求，不同的提供商實現的虛擬機器可以按照自己的需求來實現此記憶體區域。不過一般而言，除了儲存Class檔案中的描述符號引用外，還會把翻譯出的直接引用也儲存在執行時常量池中。
執行時常量池相對於Class檔案常量池的另外一個重要特徵是具備動態性，Java語言並不要求常量一定只有編譯器才能產生，也就是並非置入Class檔案中的常量池的內容才能進入方法區執行時常量池，執行期間也可能將新的常量放入池中，此特性被開發人員利用得比較多的便是String類的intern() 方法。
直接記憶體
直接記憶體（Direct Memory）並不是虛擬機器執行時資料區的一部分，也不是Java虛擬機器規範中定義的記憶體區域。但這部分記憶體也被頻繁運用，而卻可能導致OutOfMemoryError異常出現，所以這裡放到一起講解。
以NIO（New Input/Output）類為例，NIO引入了一種基於通道（Channel）與緩衝區（Buffer）的I/O方式，它可以使用Native函式庫直接分配堆外記憶體，然後通過一個儲存在Java堆中的DirectByteBuffer物件作為這塊記憶體的引用進行操作。這樣能避免在Java堆和Native堆中來回複製資料，在一些場景裡顯著提高效能。
本機直接記憶體的分配不會受到Java堆大小的限制，但是既然是記憶體，還是會受到本機總記憶體（包括RAM以及SWAP區或分頁檔案）大小以及處理器定址空間的限制。伺服器管理員在配置虛擬機器引數時，會根據實際記憶體設定-Xmx等引數資訊，但經常忽略直接記憶體，使得各個記憶體區域總和大於實體記憶體限制（包括物理的和作業系統的限制），從而導致動態擴充套件時出現OutOfMemoryError異常。
HotSpot中的物件
物件的建立
Java的物件建立大致有如下四種方式：
- new關鍵字 這應該是我們最常見和最常用最簡單的建立物件的方式。
- 使用
newInstance()方法 這裡包括Class類的newInstance()方法和Constructor類的newInstance()方法（前者其實也是呼叫的後者）。 - 使用
clone()方法 要使用clone()方法我們必須實現實現Cloneable介面，用clone()方法建立物件並不會呼叫任何建構函式。即我們所說的淺拷貝。 - 反序列化 要實現反序列化我們需要讓我們的類實現Serializable介面。當我們序列化和反序列化一個物件，JVM會給我們建立一個單獨的物件，在反序列化時，JVM建立物件並不會呼叫任何建構函式。即我們所說的深拷貝。
上面的四種建立物件的方法除了第一種使用new指令之外，其他三種都是使用invokespecial(建構函式的直接呼叫)。這裡我們只說new建立物件的方式，關於invokespecial的內容將在後續文章中介紹。下面我們來看看當虛擬機器遇到new指令的時候物件是如何建立的。
1. 類載入檢查
虛擬機器遇到一條new指令時，首先將去檢查這個指令的引數是否能在常量池中定位到一個類的符號引用，並且檢查這個符號引用代表的類是否已被載入、解析和初始化過的，如果沒有，則必須先執行相應的類載入過程，關於類載入機制和類載入器的詳細內容將在後續文章中介紹。
2. 分配記憶體
在類載入檢查通過後，虛擬機器就將為新生物件分配記憶體。物件所需記憶體的大小在類載入完成後便可完全確定（如何確定在下一節物件記憶體佈局時再詳細講解），為物件分配空間的任務具體便等同於從Java堆中劃出一塊大小確定的記憶體空間，可以分如下兩種情況討論：
- Java堆中記憶體絕對規整 所有用過的記憶體都被放在一邊，空閒的記憶體被放在另一邊，中間放著一個指標作為分界點的指示器，那所分配記憶體就僅僅是把那個指標向空閒空間那邊挪動一段與物件大小相等的距離，這種分配方式稱為“指標碰撞”（Bump The Pointer）。
- Java堆中的記憶體不規整 已被使用的記憶體和空閒的記憶體相互交錯，那就沒有辦法簡單的進行指標碰撞了，虛擬機器就必須維護一個列表，記錄哪些記憶體塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給物件例項，並更新列表上的記錄，這種分配方式稱為“空閒列表”（Free List）。
選擇哪種分配方式由Java堆是否規整決定，而Java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。因此在使用Serial、ParNew等帶Compact過程的收集器時，系統採用的分配演算法是指標碰撞，而使用CMS這種基於Mark-Sweep演算法的收集器時（說明一下，CMS收集器可以通過UseCMSCompactAtFullCollection或CMSFullGCsBeforeCompaction來整理記憶體），就通常採用空閒列表。關於垃圾收集器的具體內容將在下一篇文章中介紹。
除如何劃分可用空間之外，另外一個需要考慮的問題是物件建立在虛擬機器中是非常頻繁的行為，即使是僅僅修改一個指標所指向的位置，在併發情況下也並非執行緒安全的，可能出現正在給物件A分配記憶體，指標還沒來得及修改，物件B又同時使用了原來的指標來分配記憶體。解決這個問題有如下兩個方案：
- 對分配記憶體空間的動作進行同步 實際上虛擬機器是採用CAS配上失敗重試的方式保證更新操作的原子性。
- 把記憶體分配的動作按照執行緒劃分在不同的空間之中進行 即每個執行緒在Java堆中預先分配一小塊記憶體，稱為本地執行緒分配緩衝（TLAB ，Thread Local Allocation Buffer），哪個執行緒要分配記憶體，就在哪個執行緒的TLAB上分配，只有TLAB用完，分配新的TLAB時才需要同步鎖定。虛擬機器是否使用TLAB，可以通過-XX:+/-UseTLAB引數來設定。
3. 初始化
記憶體分配完成之後，虛擬機器需要將分配到的記憶體空間都初始化為零值（不包括物件頭），如果使用TLAB的話，這一個工作也可以提前至TLAB分配時進行。這步操作保證了物件的例項欄位在Java程式碼中可以不賦初始值就直接使用。
4. 設定物件頭
接下來，虛擬機器要設定物件的資訊（如這個物件是哪個類的例項、如何才能找到類的元資料資訊、物件的雜湊碼、物件的GC分代年齡等資訊）並存放在物件的物件頭（Object Header）中。根據虛擬機器當前的執行狀態的不同，如是否啟用偏向鎖等，物件頭會有不同的設定方式。關於物件頭的具體內容，在下一節再詳細介紹。
5. 執行<init>方法
在上面工作都完成之後，在虛擬機器的視角來看，一個新的物件已經產生了。但是在Java程式的視角看來，物件建立才剛剛開始——<init>方法還沒有執行，所有的欄位都還為零值。所以一般來說（由位元組碼中是否跟隨有invokespecial指令所決定），new指令之後會接著執行<init>方法，把物件按照程式設計師的意願進行初始化，這樣一個真正可用的物件才算完全產生出來。
物件的記憶體佈局
HotSpot虛擬機器中，物件在記憶體中儲存的佈局可以分為三塊區域：物件頭（Header）、例項資料（Instance Data）和對齊填充（Padding）。
1. 物件頭
HotSpot虛擬機器的物件頭包括兩部分資訊：
- 物件自身的執行時資料 “Mark Word” 如雜湊碼（HashCode）、GC分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒ID、偏向時間戳等等，這部分資料的長度在32位和64位的虛擬機器（暫不考慮開啟壓縮指標的場景）中分別為32個和64個Bits，官方稱它為“Mark Word”。物件需要儲存的執行時資料很多，其實已經超出了32、64位Bitmap結構所能記錄的限度，但是物件頭資訊是與物件自身定義的資料無關的額外儲存成本，考慮到虛擬機器的空間效率，Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲儘量多的資訊，它會根據物件的狀態複用自己的儲存空間。例如在32位的HotSpot虛擬機器中物件未被鎖定的狀態下，Mark Word的32個Bits空間中的25Bits用於儲存物件雜湊碼（HashCode），4Bits用於儲存物件分代年齡，2Bits用於儲存鎖標誌位，1Bit固定為0，在其他狀態（輕量級鎖定、重量級鎖定、GC標記、可偏向）下物件的儲存內容如下圖所示：
- 型別指標 型別指標即物件指向它的類元資料的指標，虛擬機器通過這個指標來確定這個物件是哪個類的例項。並不是所有的虛擬機器實現都必須在物件資料上保留型別指標，換句話說查詢物件的元資料資訊並不一定要經過物件本身，這點我們在下一節討論。另外，如果物件是一個Java陣列，那在物件頭中還必須有一塊用於記錄陣列長度的資料，因為虛擬機器可以通過普通Java物件的元資料資訊確定Java物件的大小，但是從陣列的元資料中無法確定陣列的大小。
2. 例項資料
例項資料是物件真正儲存的有效資訊，也既是我們在程式程式碼裡面所定義的各種型別的欄位內容，無論是從父類繼承下來的，還是在子類中定義的都需要記錄起來。這部分的儲存順序會受到虛擬機器分配策略引數（FieldsAllocationStyle）和欄位在Java原始碼中定義順序的影響。HotSpot虛擬機器預設的分配策略為longs/doubles、ints、shorts/chars、bytes/booleans、oops（Ordinary Object Pointers），從分配策略中可以看出，相同寬度的欄位總是被分配到一起。在滿足這個前提條件的情況下，在父類中定義的變數會出現在子類之前。如果CompactFields引數值為true（預設為true），那子類之中較窄的變數也可能會插入到父類變數的空隙之中。
3. 對齊填充
對齊填充並不是必然存在的，也沒有特別的含義，它僅僅起著佔位符的作用。由於HotSpot VM的自動記憶體管理系統要求物件起始地址必須是8位元組的整數倍，換句話說就是物件的大小必須是8位元組的整數倍。物件頭部分正好似8位元組的倍數（1倍或者2倍），因此當物件例項資料部分沒有對齊的話，就需要通過對齊填充來補全。
物件的訪問定位
我們的Java程式需要通過棧上的物件引用（reference）資料（儲存在棧上的區域性變量表中）來操作堆上的具體物件。由於reference型別在Java虛擬機器規範裡面也只規定了是一個指向物件的引用，並沒有定義這個引用的具體實現，物件訪問方式也是取決於虛擬機器實現而定的。主流的訪問方式有使用控制代碼和直接指標兩種。
1. 使用控制代碼訪問
如果使用控制代碼訪問的話，Java堆中將會劃分出一塊記憶體來作為控制代碼池，reference中儲存的就是物件的控制代碼地址，而控制代碼中包含了物件例項資料與型別資料的各自的具體地址資訊。如下圖所示：
2. 使用直接指標訪問
如果使用直接指標訪問的話，Java堆物件的佈局中就必須考慮如何放置訪問型別資料的相關資訊，reference中儲存的直接就是物件地址，如下圖所示：
這兩種物件訪問方式各有優勢，下面分別來談一談：
- 控制代碼 使用控制代碼訪問的最大好處就是reference中儲存的是穩定的控制代碼地址，在物件被移動（垃圾收集時移動物件是非常普遍的行為）時只會改變控制代碼中的例項資料指標，而reference本身不需要被修改。
- 直接指標 使用直接指標來訪問最大的好處就是速度更快，它節省了一次指標定位的時間開銷，由於物件訪問的在Java中非常頻繁，因此這類開銷積小成多也是一項 非常可觀的執行成本。從上一部分講解的物件記憶體佈局可以看出，HotSpot是使用直接指標進行物件訪問的，不過在整個軟體開發的範圍來 看，各種語言、框架中使用控制代碼來訪問的情況也十分常見。
本人免費整理了Java高階資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分散式等教程，一共30G，需要自己領取。
傳送門：https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL