JVM-記憶體區域與OOM
本篇部落格內容主要參考《深入理解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），那就可以考慮重點檢查一下直接記憶體方面的原因了。
