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

標籤：Java

上一篇：dubbo常見例外及原因分析（<i>UPDATING...</i>）

下一篇：mybatis_day01