關於JVM 記憶體的 N 個高頻面試問題！

狸貓技術窩發表於2019-05-31

JVM記憶體面試

文章來自：melonstreet

JVM的記憶體區域是怎麼劃分的？

JVM的記憶體劃分中，有部分割槽域是執行緒私有的，有部分是屬於整個JVM程式，有些區域會丟擲OOM異常，有些則不會。

瞭解JVM的記憶體區域劃分以及特徵，是定位線上記憶體問題的基礎。

那麼JVM記憶體區域是怎麼劃分的呢？

首先是程式計數器（Program Counter Register)，在JVM規範中，每個執行緒都有自己的程式計數器。

這是一塊比較小的記憶體空間，儲存當前執行緒正在執行的Java方法的JVM指令地址，即位元組碼的行號。如果正在執行Native方法，則這個計數器為空。

另外，該記憶體區域是唯一一個在Java虛擬機器規範中沒有規定任何OOM情況的記憶體區域。

第二，Java虛擬機器棧(Java Virtal Machine Stack)，同樣也是屬於執行緒私有區域。

每個執行緒在建立的時候都會建立一個虛擬機器棧，生命週期與執行緒一致，執行緒退出時，執行緒的虛擬機器棧也回收。

虛擬機器棧內部保持一個個的棧幀，每次方法呼叫都會進行壓棧，JVM對棧幀的操作只有出棧和壓棧兩種，方法呼叫結束時會進行出棧操作。

該區域儲存著區域性變數表，編譯時期可知的各種基本型別資料、物件引用、方法出口等資訊。

第三，本地方法棧（Native Method Stack）與虛擬機器棧類似，本地方法棧是在呼叫本地方法時使用的棧，每個執行緒都有一個本地方法棧。

第四，堆（Heap），幾乎所有建立的Java物件例項，都是被直接分配到堆上的。

堆被所有的執行緒所共享，在堆上的區域，會被垃圾回收器做進一步劃分，例如新生代、老年代的劃分。

Java虛擬機器在啟動的時候，可以使用“Xmx”之類的引數指定堆區域的大小。

第五，方法區（Method Area)。方法區與堆一樣，也是所有的執行緒所共享，儲存被虛擬機器載入的元（Meta）資料，包括類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料。

這裡需要注意的是執行時常量池也在方法區中。根據Java虛擬機器規範的規定，當方法區無法滿足記憶體分配需求時，將丟擲OutOfMemoryError異常。

由於早期HotSpot JVM的實現，將CG分代收集擴充到了方法區，因此很多人會將方法區稱為永久代。

Oracle JDK8中已永久代移除永久代，同時增加了後設資料區（Metaspace）。

第六，執行時常量池（Run-Time Constant Pool)，這是方法區的一部分，受到方法區記憶體的限制，當常量池無法再申請到記憶體時，會丟擲OutOfMemoryError異常。

在Class檔案中，除了有類的版本、方法、欄位、介面等描述資訊外，還有一項資訊是常量池。

每個Class檔案的頭四個位元組稱為Magic Number，它的作用是確定這是否是一個可以被虛擬機器接受的檔案；接著的四個位元組儲存的是Class檔案的版本號。緊挨著版本號之後的，就是常量池入口了。

常量池主要存放兩大類常量：

字面量（Literal），如文字字串、final常量值
符號引用，存放了與編譯相關的一些常量，因為Java不像C++那樣有連線的過程，因此欄位方法這些符號引用在執行期就需要進行轉換，以便得到真正的記憶體入口地址。

class檔案中的常量池，也稱為靜態常量池，JVM虛擬機器完成類裝載操作後，會把靜態常量池載入到記憶體中，存放在執行時常量池。

第七，直接記憶體（Direct Memory），直接記憶體並不屬於Java規範規定的屬於Java虛擬機器執行時資料區的一部分。

Java的NIO可以使用Native方法直接在java堆外分配記憶體，使用DirectByteBuffer物件作為這個堆外記憶體的引用。

下面這張圖，反映了執行中的Java程式記憶體佔用情況：

OOM可能發生在哪些區域上？

根據javadoc的描述，OOM是指JVM的記憶體不夠用了，同時垃圾收集器也無法提供更多的記憶體。從描述中可以看出，在JVM丟擲OutOfMemoryError之前，垃圾收集器一般會出馬先嚐試回收記憶體。

從上面分析的Java資料區來看，除了程式計數器不會發生OOM外，哪些區域會發生OOM的情況呢？

第一，堆記憶體。堆記憶體不足是最常見的傳送OOM的原因之一

如果在堆中沒有記憶體完成物件例項的分配，並且堆無法再擴充套件時，將丟擲OutOfMemoryError異常，丟擲的錯誤資訊是“java.lang.OutOfMemoryError:Java heap space”。

當前主流的JVM可以通過-Xmx和-Xms來控制堆記憶體的大小，發生堆上OOM的可能是存在記憶體洩露，也可能是堆大小分配不合理。

第二，Java虛擬機器棧和本地方法棧，這兩個區域的區別不過是虛擬機器棧為虛擬機器執行Java方法服務，而本地方法棧則為虛擬機器使用到的Native方法服務，在記憶體分配異常上是相同的。

在JVM規範中，對Java虛擬機器棧規定了兩種異常：

如果執行緒請求的棧大於所分配的棧大小，則丟擲StackOverFlowError錯誤，比如進行了一個不會停止的遞迴呼叫；
如果虛擬機器棧是可以動態擴充的，擴充時無法申請到足夠的記憶體，則丟擲OutOfMemoryError錯誤。

第三，直接記憶體。直接記憶體雖然不是虛擬機器執行時資料區的一部分，但既然是記憶體，就會受到實體記憶體的限制。

在JDK1.4中引入的NIO使用Native函式庫在堆外記憶體上直接分配記憶體，但直接記憶體不足時，也會導致OOM。

第四，方法區。隨著Metaspace後設資料區的引入，方法區的OOM錯誤資訊也變成了“java.lang.OutOfMemoryError:Metaspace”。

對於舊版本的Oracle JDK，由於永久代的大小有限，而JVM對永久代的垃圾回收並不積極，如果往永久代不斷寫入資料，例如String.Intern()的呼叫，在永久代佔用太多空間導致記憶體不足，也會出現OOM的問題

對應的錯誤資訊為“java.lang.OutOfMemoryError:PermGen space”

記憶體區域	是否執行緒私有	是否可能發生OOM
程式計數器	是	否
虛擬機器棧	是	是
本地方法棧	是	是
方法區	否	是
直接記憶體	否	是
堆	否	是

堆記憶體的結構？

可以藉助一些工具來了解JVM的記憶體內容，具體到特定的記憶體區域，應該用什麼工具去定位呢？

圖形化工具。圖形化工具的優點是直觀，連線到Java程式後，可以顯示堆記憶體、堆外記憶體的使用情況，類似的工具有JConsole,VisualVm等。
命令列工具。這類工具可以在執行時進行查詢，包括jstat，jmap等，可以對堆記憶體、方法區等進行檢視。定位線上問題時也多會使用這些工具。jmap也可以生成堆轉儲檔案（Heap Dump）檔案，如果是在linux上，可以將堆轉儲檔案拉到本地來，使用Eclipse MAT進行分析，也可以使用jhap進行分析。

關於記憶體的監控與診斷，在後面會進行深入瞭解。現在來看下一個問題：堆內的結構是怎麼的呢？

站在垃圾收集器的角度來看，可以把記憶體分為新生代與老年代。

記憶體的分配規則取決於當前使用的是哪種垃圾收集器的組合，以及記憶體相關的引數配置。

往大的方向說，物件優先分配在新生代的Eden區域，而大物件直接進入老年代。

第一, 新生代的Eden區域。

物件優先分配在該區域，同時JVM可以為每個執行緒分配一個私有的快取區域，稱為TLAB（Thread Local Allocation Buffer），避免多執行緒同時分配記憶體時需要使用加鎖等機制而影響分配速度。TLAB在堆上分配，位於Eden中。

TLAB的結構如下：

// ThreadLocalAllocBuffer: a descriptor for thread-local storage used by
// the threads for allocation.
//            It is thread-private at any time, but maybe multiplexed over
//            time across multiple threads. The park()/unpark() pair is
//            used to make it avaiable for such multiplexing.
class ThreadLocalAllocBuffer: public CHeapObj{
  friend class VMStructs;
private:
  HeapWord* _start;                              // address of TLAB
  HeapWord* _top;                                // address after last allocation
  HeapWord* _pf_top;                             // allocation prefetch watermark
  HeapWord* _end;                                // allocation end (excluding alignment_reserve)
  size_t    _desired_size;                       // desired size   (including alignment_reserve)
  size_t    _refill_waste_limit;                 // hold onto tlab if free() is larger than this複製程式碼

從本質上來說，TLAB的管理是依靠三個指標：start、end、top。

start與end標記了Eden中被該TLAB管理的區域，該區域不會被其他執行緒分配記憶體所使用，top是分配指標，開始時指向start的位置，隨著記憶體分配的進行，慢慢向end靠近，當撞上end時觸發TLAB refill。

因此記憶體中Eden的結構大體為：