本篇部落格內容主要參考《深入理解Java虛擬機器》
記憶體區域與記憶體溢位異常
執行時資料區
Java虛擬機器執行時資料區：
程式計數器（Program Counter Register）是一塊較小的記憶體空間，它可以看作是當前執行緒所執行的位元組碼的行號指示器。執行緒私有
如果執行緒正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果正在執行的是本地（Native）方法，這個計數器值則應為空（Undefined）。此記憶體區域是唯一一個在《Java虛擬機器規範》中沒有規定任何OutOfMemoryError情況的區域。
JAVA方法 是由JAVA編寫的，編譯成位元組碼，儲存在class檔案中。本地方法 是由其它語言編寫的，編譯成和處理器相關的機器程式碼，與平臺高度相關。
本地方法儲存在動態連結庫中，即.dll(windows系統)檔案中，格式是各個平臺專有的
執行中的JAVA方法呼叫本地方法時，虛擬機器裝載包含這個本地方法的動態庫的，並呼叫這個方法。通過本地方法，JAVA程式可以直接訪問底層作業系統的資源，如果你這樣用，你的程式就變成平臺相關了，因為本地方法的動態庫是與平臺相關的，此外使用本地方法還可能把程式變得和特定的JAVA平臺實現相關。一個本地方法介面——JAVA本地介面JNI——使得本地方法可以在特定主機系統的任何一個JAVA平臺實現上執行
JAVA虛擬機器棧與程式計數器一樣，Java虛擬機器棧（Java Virtual Machine Stack）也是執行緒私有的，它的生命週期與執行緒相同。虛擬機器棧描述的是Java方法執行的執行緒記憶體模型：每個方法被執行的時候，Java虛擬機器都會同步建立一個棧幀（Stack Frame）用於儲存區域性變數表、運算元棧、動態連線、方法出口等資訊。每一個方法被呼叫直至執行完畢的過程，就對應著一個棧幀在虛擬機器棧中從入棧到出棧的過程。
區域性變數表裡存放各種基本資料型別，物件引用和returnAddress型別。其中，這些資料型別在區域性變數表中的儲存空間以區域性變數槽（Slot）表示。long和double會佔兩個區域性變數槽，其餘資料型別只佔一個。區域性變數表所需的記憶體空間在編譯期間完成分配，當進入一個方法時，這個方法需要在棧幀中分配多大的區域性變數空間是完全確定的，在方法執行期間不會改變區域性變數表的大小。請讀者注意，這裡說的“大小”是指變數槽的數量，虛擬機器真正使用多大的記憶體空間（譬如按照1個變數槽佔用32個位元、64個位元，或者更多）來實現一個變數槽，這是完全由具體的虛擬機器實現自行決定的事情。
本地方法棧與虛擬機器棧所發揮的作用是非常相似的，其區別只是虛擬機器棧為虛擬機器執行Java方法（也就是位元組碼）服務，而本地方法棧則是為虛擬機器使用到的本地（Native）方法服務。
Java堆，對於Java應用程式來說，Java堆（Java Heap）是虛擬機器所管理的記憶體中最大的一塊。Java堆是被所有執行緒共享的一塊記憶體區域，在虛擬機器啟動時建立。此記憶體區域的唯一目的就是存放物件例項，Java世界裡“幾乎”所有的物件例項都在這裡分配記憶體。
Java堆是垃圾收集器管理的記憶體區域，因此有時候它也被稱為“GC堆”。
從分配記憶體的角度看，所有執行緒共享的Java堆中可以劃分出多個執行緒私有的分配緩衝區（Thread Local Allocation Buffer，TLAB），以提升物件分配時的效率。不過無論從什麼角度，無論如何劃分，都不會改變Java堆中儲存內容的共性，無論是哪個區域，儲存的都只能是物件的例項，將Java堆細分的目的只是為了更好地回收記憶體，或者更快地分配記憶體。
方法區與Java堆一樣，是各個執行緒共享的記憶體區域，它用於儲存已被虛擬機器載入的型別資訊、常量、靜態變數、即時編譯器編譯後的程式碼快取等資料。雖然《Java虛擬機器規範》中把方法區描述為堆的一個邏輯部分，但是它卻有一個別名叫作“非堆”（Non-Heap），目的是與Java堆區分開來。
執行時常量池（Runtime Constant Pool）是方法區的一部分。Class檔案中除了有類的版本、欄位、方法、介面等描述資訊外，還有一項資訊是常量池表（Constant Pool Table），用於存放編譯期生成的各種字面量與符號引用，這部分內容將在類載入後存放到方法區的執行時常量池中。
物件
物件的建立
一個物件的建立，首先當JVM遇到一條位元組碼指令new時，首先檢查這條指令的引數能否定位到一個符號引用，定位到之後，檢查這個符號引用是否已被載入、解析和初始化過。如果沒有，則先執行相應的類載入過程。經歷了類載入後，物件所需的記憶體大小即可確定，接下來是為物件分配記憶體空間。
為物件分配記憶體空間實際上等同於將一塊確定大小的記憶體空間從Java堆中劃分出來。
劃分方式有兩種：1. 如果記憶體是規整的，則可以使用“指標碰撞”的方式進行記憶體分配。 2. 如果記憶體不規整，虛擬機器則需要維護一個列表，記錄那些記憶體塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給物件例項，並更新列表上的記錄，這種分配方式稱為“空閒列表”（Free List）。
記憶體是否規整由垃圾收集器是否具有“空間壓縮整理”的能力。
另外需要考慮的一個問題：修改指標所指向的位置，在併發情況下並不是執行緒安全的。可能出現正在給物件A分配記憶體，指標還沒來得及修改，物件B又同時使用了原來的指標來分配記憶體的情況。解決這個問題有兩種可選方案：一種是對分配記憶體空間的動作進行同步處理——實際上虛擬機器是採用CAS配上失敗重試的方式保證更新操作的原子性；另外一種是把記憶體分配的動作按照執行緒劃分在不同的空間之中進行，即每個執行緒在Java堆中預先分配一小塊記憶體，稱為本地執行緒分配緩衝（Thread Local AllocationBuffer，TLAB），哪個執行緒要分配記憶體，就在哪個執行緒的本地緩衝區中分配，只有本地緩衝區用完了，分配新的快取區時才需要同步鎖定。
記憶體分配完成後，JVM必須將分配到的記憶體空間（不包括物件頭）都初始化為零值。
此外，JVM還需要對物件進行必要的設定，例如這個物件是哪個類的例項，如何找到類的後設資料資訊等等一些資訊。這些都完成之後，JVM的視角中，物件已經建立完畢。但從程式角度看，還有建構函式，（.class檔案中的<init>()），一般來說（由位元組碼流中new指令後面是否跟隨invokespecial指令所決定，Java編譯器會在遇到new關鍵字的地方同時生成這兩條位元組碼指令，但如果直接通過其他方式產生的則不一定如此），new指令之後會接著執行<init>()方法，，按照coder的想法進行初始化，物件構造完成。
物件的記憶體佈局
HotSpot虛擬機器中，物件在堆記憶體的儲存佈局可以分為三個部分：物件頭（Header）、例項資料（Instance Data）和對齊填充（Padding）。
HotSpot虛擬機器物件的物件頭部分包括兩類資訊。第一類是用於儲存物件自身的執行時資料，如雜湊碼（HashCode）、GC分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒ID、偏向時間戳等，這部分資料的長度在32位和64位的虛擬機器（未開啟壓縮指標）中分別為32個位元和64個位元，官方稱它為“Mark Word”。物件需要儲存的執行時資料很多，其實已經超出了32、64位Bitmap結構所能記錄的最大限度，但物件頭裡的資訊是與物件自身定義的資料無關的額外儲存成本，考慮到虛擬機器的空間效率，Mark Word被設計成一個有著動態定義的資料結構，以便在極小的空間記憶體儲儘量多的資料，根據物件的狀態複用自己的儲存空間。
物件頭的另外一部分是型別指標，即物件指向它的型別後設資料的指標，Java虛擬機器通過這個指標來確定該物件是哪個類的例項。並不是所有的虛擬機器實現都必須在物件資料上保留型別指標，換句話說，查詢物件的後設資料資訊並不一定要經過物件本身，這點我們會在下一節具體討論。此外，如果物件是一個Java陣列，那在物件頭中還必須有一塊用於記錄陣列長度的資料，因為虛擬機器可以通過普通Java物件的後設資料資訊確定Java物件的大小，但是如果陣列的長度是不確定的，將無法通過後設資料中的資訊推斷出陣列的大小。
總結下來，物件頭儲存了物件自身的執行時資料（各種狀態資訊），以及型別指標（指向型別後設資料）。
例項資料部分儲存著物件的有效資訊，即在程式碼中定義的各種型別的欄位內容，無論是從父類繼承下來的，還是子類中定義的欄位都需要記錄下來。這部分儲存順序受虛擬機器分配策略引數（-XX: FieldsAllocationStyle引數）和欄位在Java原始碼中定義順序的影響。
HotSpot虛擬機器預設的分配順序為longs/doubles、ints、shorts/chars、bytes/booleans、oops（Ordinary Object Pointers，OOPs），從以上預設的分配策略中可以看到，相同寬度的欄位總是被分配到一起存放，在滿足這個前提條件的情況下，在父類中定義的變數會出現在子類之前。如果HotSpot虛擬機器的+XX：CompactFields引數值為true（預設就為true），那子類之中較窄的變數也允許插入父類變數的空隙之中，以節省出一點點空間。
對齊填充部分：HotSpot記憶體自動管理系統要求物件起始地址必須是8Bytes的整數倍，實際上任何物件的大小都必須是8位元組的整數倍，物件頭部分已被設計為該格式，如果例項資料部分沒有對齊的話，就需要通過該機制補全。
物件的訪問定位
Java程式會通過棧上的reference資料來操作堆上的具體物件。在Java虛擬機器規範裡只規定了reference型別是一個指向物件的引用，並沒有定義這個引用應該通過什麼方式去定位、訪問到堆中物件的具體位置，所以物件訪問方式也是由虛擬機器實現而定的，主流的訪問方式主要有使用控制程式碼和直接指標兩種：
- 如果使用控制程式碼訪問的話，Java堆中將可能會劃分出一塊記憶體來作為控制程式碼池，reference中儲存的就是物件的控制程式碼地址，而控制程式碼中包含了物件例項資料與型別資料各自具體的地址資訊，其結構如圖2-2所示。
- 如果使用直接指標訪問的話，Java堆中物件的記憶體佈局就必須考慮如何放置訪問型別資料的相關資訊，reference中儲存的直接就是物件地址，如果只是訪問物件本身的話，就不需要多一次間接訪問的開銷。
使用直接指標的話，reference可以直接訪問到物件，節省了一次指標定位的時間開銷，速度更快。HotSpot就主要使用這種方式進行物件訪問。
使用控制程式碼訪問，好處在於reference中儲存的是穩定控制程式碼地址，在物件被移動時只需要改變控制程式碼中的例項資料指標，reference本身不需要更改。
OOM（OutOfMemoryError）
Java堆溢位
假設限制Java堆的大小，通過最小值引數-Xms和最大值引數-Xmx設定一致以避免堆自動擴充套件，如果保證GC Roots到物件之間有可達路徑來避免垃圾回收機制清楚物件，則會出現OOM。-XX: +HeapDumpOnOutOf-MemoryError 可以讓虛擬機器在出現記憶體溢位異常的時候Dump出當前的記憶體堆轉儲快照以便進行事後分析。
虛擬機器棧和本地方法棧溢位
HotSpot虛擬機器並不區分虛擬機器棧和本地方法棧。因此對於HotSpot來說，-Xoss引數（設定本地方法棧大小）是無效的，棧容量只能由-Xss引數來確定，《Java虛擬機器規範》描述了兩種異常：
- 如果執行緒請求的棧深度大於虛擬機器所允許的最大深度，將丟擲StackOverflowError異常。
- 如果虛擬機器的棧記憶體允許動態擴充套件，當擴充套件棧容量無法申請到足夠的記憶體時，將丟擲OutOfMemoryError異常。
《Java虛擬機器規範》明確允許Java虛擬機器實現自行選擇是否支援棧的動態擴充套件，而HotSpot虛擬機器的選擇是不支援擴充套件，所以除非在建立執行緒申請記憶體時就因無法獲得足夠記憶體而出現OutOfMemoryError異常，否則線上程執行時是不會因為擴充套件而導致記憶體溢位的，只會因為棧容量無法容納新的棧幀而導致StackOverflowError異常。
在單執行緒的情況下，例如HotSpot不支援擴充套件，當棧幀過大（區域性變數定義過多）或者棧容量過小裝不下，都是StackOverFlowError。而多執行緒情況下，每個執行緒都會私有棧，當棧容量很大的時候，開過多執行緒將會導致OOM，作業系統記憶體不足。
在Windows平臺的虛擬機器中，Java的執行緒是對映到作業系統的核心執行緒
方法區和執行時常量池溢位
JDK6及之前的HotSpot虛擬機器中，執行時常量池分配在永久代中，所以當通過-XX：PermSize和-XX：MaxPermSize限制永久代的大小即可間接限制永久代的大小。
如果利用String.intern()然後建立一個HashSet<Stinrg>進行字串常量的無限增加，則很快在6的版本中會出現OOM。這裡可以說明執行時常量池的確是屬於方法區。
而在JDK7之後，字串常量池放在了堆中，限制上面說的永久代大小並不會導致OOM，相反，通過-Xmx引數限制堆的大小將會出現OOM。
對下列程式碼進行分析：
String str1 = new StringBuilder("計算機").append("軟體").toString();
System.out.println(str1.intern() == str1);
String str2 = new StringBuilder("ja").append("va").toString();
System.out.println(str2.intern() == str2);
這段程式碼在JDK 6中執行，會得到兩個false，而在JDK 7中執行，會得到一個true和一個false。產生差異的原因是，在JDK 6中，intern()方法會把首次遇到的字串例項複製到永久代的字串常量池中儲存，返回的也是永久代裡面這個字串例項的引用，而由StringBuilder建立的字串物件例項在Java堆上，所以必然不可能是同一個引用，結果將返回false。
而JDK 7（以及部分其他虛擬機器，例如JRockit）的intern()方法實現就不需要再拷貝字串的例項到永久代了，既然字串常量池已經移到Java堆中，那隻需要在常量池裡記錄一下首次出現的例項引用即可，因此intern()返回的引用和由StringBuilder建立的那個字串例項就是同一個。而對str2比較返回false，這是因為“java”[2]這個字串在執行String-Builder.toString()之前就已經出現過了，字串常量池中已經有它的引用，不符合intern()方法要求“首次遇到”的原則，“計算機軟體”這個字串則是首次出現的，因此結果返回true。
"java" 是在載入sun.misc.Version這個類的時候進入常量池的。
方法區的內容除了執行時常量池外，還需要用來存放型別的相關資訊：類名，訪問修飾符，常量池，欄位描述，方法描述等。動態代理CGLib可以直接生成大量的動態類，在這種情況下如果方法區比較小的時候，將會OOM。（JDK7測試時仍是限制永久代大小）
在JDK8以後，永久代便退出了，元空間登場。在預設設定下，那些正常的動態建立新型別的測試用例已經很難再迫使虛擬機器產生方法區的溢位異常了。元空間的一些相關引數：
- -XX：MaxMetaspaceSize：設定元空間最大值，預設是-1，即不限制，或者說只受限於本地記憶體大小。
- -XX：MetaspaceSize：指定元空間的初始空間大小，以位元組為單位，達到該值就會觸發垃圾收集進行型別解除安裝，同時收集器會對該值進行調整：如果釋放了大量的空間，就適當降低該值；如果釋放了很少的空間，那麼在不超過-XX：MaxMetaspaceSize（如果設定了的話）的情況下，適當提高該值。
- -XX：MinMetaspaceFreeRatio：作用是在垃圾收集之後控制最小的元空間剩餘容量的百分比，可減少因為元空間不足導致的垃圾收集的頻率。類似的還有-XX：Max-MetaspaceFreeRatio，用於控制最大的元空間剩餘容量的百分比。
本機直接記憶體溢位
直接記憶體不是執行時資料區的一部分，也不是《Java虛擬機器規範》中定義的記憶體區域。JDK1.4中引入了NIO類，基於Channel和Buffer的IO方式，它可以使用本地函式庫直接分配堆外記憶體，然後通過一個存在Java堆中的DirectByteBuffer物件作為這塊記憶體的引用進行操作。這樣避免了在Java堆和Native堆中來回複製資料。
直接記憶體（Direct Memory）的容量大小可通過-XX：MaxDirectMemorySize引數來指定，如果不去指定，則預設與Java堆最大值（由-Xmx指定）一致。
ByteBuffer堆外記憶體使用：
- 從nio時代開始，可以使用ByteBuffer等類來操縱堆外記憶體了，使用ByteBuffer分配本地記憶體則非常簡單，ByteBuffer buffer = ByteBuffer.allocateDirect(10 * 1024 * 1024);
- 可以通過指定JVM引數來確定堆外記憶體大小限制：-XX:MaxDirectMemorySize=512m
- 對於這種direct buffer記憶體不夠的時候會丟擲錯誤： java.lang.OutOfMemoryError: Direct buffer memory
雖然使用DirectByteBuffer分配記憶體也會丟擲記憶體溢位異常，但它丟擲異常時並沒有真正向作業系統申請分配記憶體，而是通過計算得知記憶體無法分配就會在程式碼裡手動丟擲溢位異常，真正申請分配記憶體的方法是Unsafe::allocateMemory()。
JDK10，Unsafe的部分功能通過VarHandle開放給外部使用。
由直接記憶體導致的記憶體溢位，一個明顯的特徵是在Heap Dump檔案中不會看見有什麼明顯的異常情況，如果讀者發現記憶體溢位之後產生的Dump檔案很小，而程式中又直接或間接使用了 DirectMemory（堆外記憶體，典型的間接使用就是NIO），那就可以考慮重點檢查一下直接記憶體方面的原因了。