Java虛擬機器管理的記憶體包括幾個執行時資料記憶體：方法區、虛擬機器棧、本地方法棧、堆、程式計數器，其中方法區和堆是由執行緒共享的資料區，其他幾個是執行緒隔離的資料區。

2.2 執行時資料區域

2.2.1程式計數器

程式計數器是一塊較小的記憶體，他可以看做是當前執行緒所執行的行號指示器。位元組碼直譯器工作的時候就是通過改變這個計數器的值來選取下一條需要執行的位元組碼的指令，分支、迴圈、跳轉、異常處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成。如果執行緒正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果正在執行的是Native方法，這個計數器則為空。此記憶體區域是唯一一個在Java虛擬機器規範中沒有規定任何OutOfMemotyError情況的區域。

2.2.2 Java虛擬機器棧

Java虛擬機器棧與程式計數器一樣也是執行緒私有的，生命週期與執行緒相同。

虛擬機器棧描述的是Java方法執行的記憶體模型：每個方法在執行的同時都會建立一個棧幀用於儲存區域性變數表、運算元棧、動態連結、方法出口等資訊。每個方法從呼叫直至完成的過程，就對應著一個棧幀在虛擬機器棧中入棧到出棧的過程。

平時所說記憶體分為：堆與棧，其中棧記憶體就是虛擬機器棧，或者說是虛擬機器棧中區域性變數表的部分。

區域性變數表存放了編譯期可知的各種基本資料型別（boolean、byte、char、short、int、float、long、double）、物件引用（refrence）型別和returnAddress型別（指向了一條位元組碼指令的地址）。

其中64位長度的long和double型別的資料會佔用兩個區域性變數空間，其餘的資料型別只佔用1個。區域性變數表所需的記憶體空間在編譯器完成分配，當進入一個方法時，這個方法需要在幀中分配多大的區域性變數空間是完全確定的，在方法執行期間不會改變區域性變數表的大小。

Java虛擬機器規範對這個區域規定了兩種異常狀況：如果執行緒請求的棧深度大於虛擬機器所允許的深度，將丟擲StackOverflowError異常。如果虛擬機器擴充套件時無法申請到足夠的記憶體，就會跑出OutOfMemoryError異常

2.2.3 本地方法棧

本地方法棧和虛擬機器棧發揮的作用是非常類似的，他們的區別是虛擬機器棧為虛擬機器執行Java方法（也就是位元組碼）服務，而本地方法棧則為虛擬機器使用到的Native方法服務。

本地方法棧區域也會丟擲StackOverflowError和OutOfMemoryErroy異常

2.2.4 Java堆

對於大部分應用來說，Java堆（Java Heap）是Java虛擬機器所管理的記憶體中最大的一塊。Java堆是被所有執行緒共享的一塊記憶體區域，在虛擬機器啟動時建立。此記憶體區域的唯一目的就是存放物件例項，幾乎所有的物件例項以及陣列都要在堆上分配。

Java堆是垃圾收集器管理的主要區域，因此Java堆很多時候也被稱為“GC堆”。

記憶體回收角度，收集器基本都採用分代收集演算法，Java堆中可以細分為：新生代和老年代；再細緻一點的有Eden空間、From Survivor空間、To Survivor空間等。

• Eden區 —— 新物件或者生命週期很短的物件會儲存在這個區域中，這個區的大小可以通過-XX:NewSize和-XX:MaxNewSize引數來調整。新生代GC（垃圾回收器）會清理這一區域。
• Survivor區 —— 那些歷經了Eden區的垃圾回收仍能存活下來的依舊存在引用的物件會待在這個區域。這個區的大小可以由JVM引數-XX:SurvivorRatio來進行調節。
• 老年代 —— 那些在歷經了Eden區和Survivor區的多次GC後仍然存活下來的物件（當然了，是拜那些揮之不去的引用所賜）會儲存在這個區裡。這個區會由一個特殊的垃圾回收器來負責。年老代中的物件的回收是由老年代的GC（major GC）來進行的。

記憶體分配角度，執行緒共享的Java堆中可能劃分出多個執行緒私有的分配緩衝區。

根據Java虛擬機器規範的規定，Java堆可以處於物理上不連續的記憶體空間中，只要邏輯上連續就可以了。在實現時，既可以實現成固定大小的，也可以是可擴充套件的，不過當前主流的虛擬機器都是按照可擴充套件來實現的（通過-Xmx和-Xms控制）。如果在堆中沒有記憶體完成例項分配，並且在堆也無法再擴充套件時，將會丟擲OutOfMemoryError異常。

2.2.5方法區

方法區它用於儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料。

雖然Java虛擬機器規範把方法區描述為堆得一個邏輯部分，但是它卻有一個別名叫做Non-Heap（非堆）目的是與Java堆區分開來。

當方法區無法滿足記憶體分配需求時，將丟擲OutOfMemoryErroy異常。

2.2.6 執行時常量池

執行時常量池（Runtime Constants Pool）是方法區的一部分。Class檔案中除了有類的版本、欄位、方法、介面等描述資訊外，還有一項資訊是常量池（Constants Pool Table），用於存放編譯期生成的各種字面量和符號引用。

Java虛擬機器對Class檔案每一部分（自然也包括常量池）的格式都有嚴格規定，每一個位元組用於儲存哪種資料必須符合規範上的要求才會被虛擬機器認可、裝載和執行。但對於執行時常量池，Java虛擬機器規範並沒有任何細節上的要求，不同的提供商實現的虛擬機器可以按照自己的需求來實現這個記憶體區域。一般來說，除了儲存Class檔案中描述的符號引用外，還會把翻譯出來的直接引用也儲存在執行時常量池中。

執行時常量池相對於Class檔案常量池的另外一個重要特徵是具備動態性，Java語言並不要求常量一定要在編譯器才能產生，執行期間也可能將新的常量放入池，這種特性被開發人員利用的比較多的便是String類的intern()方法。

既然執行時常量池是方法區的一部分，自然受到方法區記憶體的限制，當常量池無法再申請到記憶體時，會丟擲OutOfMemoryError異常。

2.3 Hotspot虛擬機器物件探祕

2.3.1 物件的建立

虛擬機器遇到一條new指令時，首先將去檢查這個指令的引數是否能夠在常量池中定位到一個類的符號引用，並且檢查這個符號引用代表的類是否已被載入、解析和初始化過。如果沒有，那必須先執行相應的類載入過程。

在類載入檢查通過後，接下來虛擬機器將為新生物件分配記憶體。物件所需的記憶體大小在類載入完成之後便可以完全確定，為物件分配空間的任務等同於把一塊確定大小的記憶體從Java堆中劃分出來。

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

如果Java堆中的記憶體並不是規整的，已使用的記憶體和空閒的記憶體相互交錯，虛擬機器就需要維護一張足夠大的空間劃分給物件例項，並更新列表上的記錄，這種分配方式稱為“空閒列表”（Free List）。

在併發情況下，可能出現正在給物件A分配記憶體，指標還沒來得及修改，物件B又同時使用了原來的指標來分配記憶體的情況。

解決這個問題有兩種方案，

一種是對分配記憶體空間的動作進行同步處理——實際上是虛擬機器採用CAS配上失敗重試的方式保證更能新操作的原子性；

另一種是把記憶體分配的動作按照執行緒劃分在不同的空間之中進行，即每個執行緒在Java堆中預先分配一小塊記憶體，稱為本地執行緒分配快取（TLAB）。那個執行緒要分配記憶體，站在哪個執行緒的TLAB上分配時，才需要同步鎖定。虛擬機器是否使用TLAB，可以通過

-XX：+UseTLAB 引數來設定。

記憶體分配完成後，虛擬機器需要將分配到的記憶體空間都初始化為零值（不包括物件頭），如果使用TLAB，這一工作也可以提前至TLAB分配時進行。這一步操作保證了物件的例項欄位在Java程式碼中可以不賦值就直接使用，程式能訪問到這些欄位資料型別所對應的零值。

接下來，虛擬機器要對物件進行必要的設定。例如這個物件是哪個類的例項、如何才能找到類的後設資料資訊、物件的雜湊碼、物件的GC分代年齡等資訊。這些資訊放在物件的物件頭（Object header）之中。

在上面工作都完成之後，從虛擬機器的視角來看，一個新的物件已經產生，但從java程式的視角來看，物件建立才剛剛開始：方法還沒有執行，所有欄位都還為零。所以，一般來說，執行new指令之後會接著執行方法，把物件按照程式設計師的醫院進行初始化，這樣一個真正可用的物件才算完全生產出來。

2.3.2 物件的記憶體佈局

在HotSpot虛擬機器中，物件在記憶體中儲存的佈局可以分為3個區域：物件頭（Header）、例項資料（Instance Data）和對其填充（Padding）。

HotSpot虛擬機器的物件頭包括來哪個部分資訊，第一部分用於儲存物件自身的執行時資料，如雜湊嗎（HashCode）、GC分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒ID、偏向時間戳等，這部分資料的長度在32位和64位的虛擬機器中分別為32bit和64bit。

物件頭的另外一部分是型別指標，即物件指向它的類後設資料的指標，虛擬機器通過這個指標來確定這個物件是哪個類的例項。並不是所有的虛擬機器實現都必須在物件資料上保留型別指標。換句話說，查詢物件的後設資料資訊，不一定要經過物件本身。

另外，如果一個物件是Java陣列，那在物件頭中還必須有一塊用於記錄陣列長度的資料。因為虛擬機器可以通過普通Java物件的後設資料資訊確定Java物件的大小，但是從陣列的後設資料中卻無法確定陣列的大小。

2.3.3 物件的訪問定位

建立物件是為了使用物件。目前主流的訪問方式有使用控制程式碼和直接指標兩種。

使用控制程式碼訪問的話，那麼Java堆中將會劃分出一塊記憶體來作為控制程式碼池，reference中儲存的就是物件的控制程式碼地址，而控制程式碼中包含了物件例項資料與型別資料各自的具體地址資訊。

使用直接控制程式碼來訪問

使用直接控制程式碼來訪問，那麼Java堆物件的佈局來訪問的最大好處就是reference中儲存的是穩定的控制程式碼地址，在物件被移動時只會改變控制程式碼中的例項資料指標，而reference本身不需要修改。

使用指標訪問最大的好處就是速度更快，它節省了一次指標定位的時間開銷。

2.4 實戰： OutOfMemoryError異常

2.4.1 Java堆溢位

Java堆用於儲存物件例項，只要不斷地建立物件，並且保證GC Roots到物件之間有可達路徑來避免垃圾回收機制清除這些物件，那麼在物件數量到達最大堆的容量限制後就會產生記憶體溢位異常。

要解決這個區域的異常，一般的手段是先通過記憶體映像分析工具（如Eclipse Memory Analyzer）對Dump出來的堆轉儲快照進行分析，重點是確認記憶體中的物件是否是必須的，也就是要先分清楚到底是出現了記憶體洩露（Memory Analyzer）還是記憶體溢位（Memory Overflow）

2.4.2 虛擬機器棧和本地方法棧溢位（略）

-Xoss引數（設定本地方法棧）存在，棧容量只由-Xss引數設定。

如果執行緒請求的棧深度大於虛擬機器所允許的最大深度，將丟擲StackOverflowError異常。

如果虛擬機器在擴充套件棧時無法申請到足夠的記憶體空間，則丟擲OutOfMemoryError異常。

2.4.3 方法區和執行時常量池溢位（略）

-XX:PermSize和-XX:MaxPermSize限制方法區大小，從而間接限制其中常量池的容量。

方法區用於存放Class的相關資訊，如類名、訪問修飾符、常量池、欄位描述、方法描述等。對於這些區域的測試，基本思路是執行時產生大量的類去填滿方法區，直到溢位。想想Spring 嗯哼。

2.4.4 本機直接記憶體溢位（略）

DirecMemory容量可通過-XX:MaxDirectMemorySize指定，如果不指定，則預設與Java堆最大值（-Xmx指定）一樣。

由DirectMemory導致的記憶體溢位，一個明顯的特徵在Heap Dump檔案中不會看見明顯的異常，如果讀者發現OOM之後Dump檔案很小，而程式中又直接或間接使用了NIO，那就可以考慮檢查一下是不是這方面的原因。

深入理解Java虛擬機器——JVM高階特性與最佳實踐(第2版)PDF版下載：
http://download.csdn.net/detail/xunzaosiyecao/9648998

作者：jiankunking 出處：http://blog.csdn.net/jiankunking