JVM完全解讀之Metaspace解密源碼分析

概述

metaspace，顧名思義，元數據空間，專門用來存元數據的，它是jdk8裡特有的數據結構用來替代perm，這塊空間很有自己的特點，前段時間公司這塊的問題太多瞭，主要是因為升級瞭中間件所致，看到大傢討論來討論去，看得出很多人對metaspace還是模棱兩可，不是很瞭解它，因此我覺得有必要寫篇文章來介紹一下它，解開它神秘的面紗，當我們再次碰到它的相關問題的時候不會再感到束手無策。

通過這篇文章，你將可以瞭解到

• 為什麼會有metaspace
• metaspace的組成
• metaspace的VM參數
• jstat裡我們應該關註metaspace的哪些值

為什麼會有metaspace

metaspace的由來民間已有很多傳說，不過我這裡隻談我自己的理解，因為我不是oracle參與這塊的開發者，所以對其真正的由來不怎麼瞭解。

我們都知道jdk8之前有perm這一整塊內存來存klass等信息，我們的參數裡也必不可少地會配置-XX:PermSize以及-XX:MaxPermSize來控制這塊內存的大小，jvm在啟動的時候會根據這些配置來分配一塊連續的內存塊，但是隨著動態類加載的情況越來越多，這塊內存我們變得不太可控，到底設置多大合適是每個開發者要考慮的問題，如果設置太小瞭，系統運行過程中就容易出現內存溢出，設置大瞭又總感覺浪費，盡管不會實質分配這麼大的物理內存。基於這麼一個可能的原因，於是metaspace出現瞭，希望內存的管理不再受到限制，也不要怎麼關註元數據這塊的OOM問題，雖然到目前來看，也並沒有完美地解決這個問題。

或許從JVM代碼裡也能看出一些端倪來，比如MaxMetaspaceSize默認值很大，CompressedClassSpaceSize默認也有1G，從這些參數我們能猜到metaspace的作者不希望出現它相關的OOM問題。

metaspace的組成

metaspace其實由兩大部分組成

• Klass Metaspace
• NoKlass Metaspace

Klass Metaspace就是用來存klass的，klass是我們熟知的class文件在jvm裡的運行時數據結構，不過有點要提的是我們看到的類似A.class其實是存在heap裡的，是java.lang.Class的一個對象實例。這塊內存是緊接著Heap的，和我們之前的perm一樣，這塊內存大小可通過-XX:CompressedClassSpaceSize參數來控制，這個參數前面提到瞭默認是1G，但是這塊內存也可以沒有，假如沒有開啟壓縮指針就不會有這塊內存，這種情況下klass都會存在NoKlass Metaspace裡，另外如果我們把-Xmx設置大於32G的話，其實也是沒有這塊內存的，因為會這麼大內存會關閉壓縮指針開關。還有就是這塊內存最多隻會存在一塊。

NoKlass Metaspace專門來存klass相關的其他的內容，比如method，constantPool等，這塊內存是由多塊內存組合起來的，所以可以認為是不連續的內存塊組成的。這塊內存是必須的，雖然叫做NoKlass Metaspace，但是也其實可以存klass的內容，上面已經提到瞭對應場景。

Klass Metaspace和NoKlass Mestaspace都是所有classloader共享的，所以類加載器們要分配內存，但是每個類加載器都有一個SpaceManager，來管理屬於這個類加載的內存小塊。如果Klass Metaspace用完瞭，那就會OOM瞭，不過一般情況下不會，NoKlass Mestaspace是由一塊塊內存慢慢組合起來的，在沒有達到限制條件的情況下，會不斷加長這條鏈，讓它可以持續工作。

metaspace的幾個參數

如果我們要改變metaspace的一些行為，我們一般會對其相關的一些參數做調整，因為metaspace的參數本身不是很多，所以我這裡將涉及到的所有參數都做一個介紹，也許好些參數大傢都是有誤解的

• UseLargePagesInMetaspace
• InitialBootClassLoaderMetaspaceSize
• MetaspaceSize
• MaxMetaspaceSize
• CompressedClassSpaceSize
• MinMetaspaceExpansion
• MaxMetaspaceExpansion
• MinMetaspaceFreeRatio
• MaxMetaspaceFreeRatio

UseLargePagesInMetaspace

默認false，這個參數是說是否在metaspace裡使用LargePage，一般情況下我們使用4KB的page size，這個參數依賴於UseLargePages這個參數開啟，不過這個參數我們一般不開。

InitialBootClassLoaderMetaspaceSize

64位下默認4M，32位下默認2200K，metasapce前面已經提到主要分瞭兩大塊，Klass Metaspace以及NoKlass Metaspace，而NoKlass Metaspace是由一塊塊內存組合起來的，這個參數決定瞭NoKlass Metaspace的第一個內存Block的大小，即2*InitialBootClassLoaderMetaspaceSize，同時為bootstrapClassLoader的第一塊內存chunk分配瞭InitialBootClassLoaderMetaspaceSize的大小

MetaspaceSize

默認20.8M左右(x86下開啟c2模式)，主要是控制metaspaceGC發生的初始閾值，也是最小閾值，但是觸發metaspaceGC的閾值是不斷變化的，與之對比的主要是指Klass Metaspace與NoKlass Metaspace兩塊committed的內存和。

MaxMetaspaceSize

默認基本是無窮大，但是我還是建議大傢設置這個參數，因為很可能會因為沒有限制而導致metaspace被無止境使用(一般是內存泄漏)而被OS Kill。這個參數會限制metaspace(包括瞭Klass Metaspace以及NoKlass Metaspace)被committed的內存大小，會保證committed的內存不會超過這個值，一旦超過就會觸發GC，這裡要註意和MaxPermSize的區別，MaxMetaspaceSize並不會在jvm啟動的時候分配一塊這麼大的內存出來，而MaxPermSize是會分配一塊這麼大的內存的。

CompressedClassSpaceSize

默認1G，這個參數主要是設置Klass Metaspace的大小，不過這個參數設置瞭也不一定起作用，前提是能開啟壓縮指針，假如-Xmx超過瞭32G，壓縮指針是開啟不來的。如果有Klass Metaspace，那這塊內存是和Heap連著的。

MinMetaspaceExpansion

MinMetaspaceExpansion和MaxMetaspaceExpansion這兩個參數或許和大傢認識的並不一樣，也許很多人會認為這兩個參數不就是內存不夠的時候，然後擴容的最小大小嗎？其實不然

這兩個參數和擴容其實並沒有直接的關系，也就是並不是為瞭增大committed的內存，而是為瞭增大觸發metaspace GC的閾值

這兩個參數主要是在比較特殊的場景下救急使用，比如gcLocker或者should_concurrent_collect的一些場景，因為這些場景下接下來會做一次GC，相信在接下來的GC中可能會釋放一些metaspace的內存，於是先臨時擴大下metaspace觸發GC的閾值，而有些內存分配失敗其實正好是因為這個閾值觸頂導致的，於是可以通過增大閾值暫時繞過去

默認332.8K，增大觸發metaspace GC閾值的最小要求。假如我們要救急分配的內存很小，沒有達到MinMetaspaceExpansion，但是我們會將這次觸發metaspace GC的閾值提升MinMetaspaceExpansion，之所以要大於這次要分配的內存大小主要是為瞭防止別的線程也有類似的請求而頻繁觸發相關的操作，不過如果要分配的內存超過瞭MaxMetaspaceExpansion，那MinMetaspaceExpansion將會是要分配的內存大小基礎上的一個增量

MaxMetaspaceExpansion

默認5.2M，增大觸發metaspace GC閾值的最大要求。假如說我們要分配的內存超過瞭MinMetaspaceExpansion但是低於MaxMetaspaceExpansion，那增量是MaxMetaspaceExpansion，如果超過瞭MaxMetaspaceExpansion，那增量是MinMetaspaceExpansion加上要分配的內存大小

註：每次分配隻會給對應的線程一次擴展觸發metaspace GC閾值的機會，如果擴展瞭，但是還不能分配，那就隻能等著做GC瞭

MinMetaspaceFreeRatio

MinMetaspaceFreeRatio和下面的MaxMetaspaceFreeRatio，主要是影響觸發metaspaceGC的閾值

默認40，表示每次GC完之後，假設我們允許接下來metaspace可以繼續被commit的內存占到瞭被commit之後總共committed的內存量的MinMetaspaceFreeRatio%，如果這個總共被committed的量比當前觸發metaspaceGC的閾值要大，那麼將嘗試做擴容，也就是增大觸發metaspaceGC的閾值，不過這個增量至少是MinMetaspaceExpansion才會做，不然不會增加這個閾值

這個參數主要是為瞭避免觸發metaspaceGC的閾值和gc之後committed的內存的量比較接近，於是將這個閾值進行擴大

一般情況下在gc完之後，如果被committed的量還是比較大的時候，換個說法就是離觸發metaspaceGC的閾值比較接近的時候，這個調整會比較明顯

註：這裡不用gc之後used的量來算，主要是擔心可能出現committed的量超過瞭觸發metaspaceGC的閾值，這種情況一旦發生會很危險，會不斷做gc，這應該是jdk8在某個版本之後才修復的bug

MaxMetaspaceFreeRatio

默認70，這個參數和上面的參數基本是相反的，是為瞭避免觸發metaspaceGC的閾值過大，而想對這個值進行縮小。這個參數在gc之後committed的內存比較小的時候並且離觸發metaspaceGC的閾值比較遠的時候，調整會比較明顯

jstat裡的metaspace字段

我們看GC是否異常，除瞭通過GC日志來做分析之外，我們還可以通過jstat這樣的工具展示的數據來分析，前面我公眾號裡有篇文章介紹瞭jstat這塊的實現，有興趣的可以到我的公眾號你假笨裡去翻閱下jstat的這篇文章。

我們通過jstat可以看到metaspace相關的這麼一些指標，分別是M，CCS，MC，MU，CCSC，CCSU，MCMN，MCMX，CCSMN，CCSMX

它們的定義如下：

  column {
    header "^M^"  /* Metaspace - Percent Used */
    data (1-((sun.gc.metaspace.capacity - sun.gc.metaspace.used)/sun.gc.metaspace.capacity)) * 100
    align right
    width 6
    scale raw
    format "0.00"
  }
  column {
    header "^CCS^"    /* Compressed Class Space - Percent Used */
    data (1-((sun.gc.compressedclassspace.capacity - sun.gc.compressedclassspace.used)/sun.gc.compressedclassspace.capacity)) * 100
    align right
    width 6
    scale raw
    format "0.00"
  }
  column {
    header "^MC^" /* Metaspace Capacity - Current */
    data sun.gc.metaspace.capacity
    align center
    width 6
    scale K
    format "0.0"
  }
  column {
    header "^MU^" /* Metaspae Used */
    data sun.gc.metaspace.used
    align center
    width 6
    scale K
    format "0.0"
  }
   column {
    header "^CCSC^"   /* Compressed Class Space Capacity - Current */
    data sun.gc.compressedclassspace.capacity
    width 8
    align right
    scale K
    format "0.0"
  }
  column {
    header "^CCSU^"   /* Compressed Class Space Used */
    data sun.gc.compressedclassspace.used
    width 8
    align right
    scale K
    format "0.0"
  }
  column {
    header "^MCMN^"   /* Metaspace Capacity - Minimum */
    data sun.gc.metaspace.minCapacity
    scale K
    align right
    width 8
    format "0.0"
  }
  column {
    header "^MCMX^"   /* Metaspace Capacity - Maximum */
    data sun.gc.metaspace.maxCapacity
    scale K
    align right
    width 8
    format "0.0"
  }
  column {
    header "^CCSMN^"    /* Compressed Class Space Capacity - Minimum */
    data sun.gc.compressedclassspace.minCapacity
    scale K
    align right
    width 8
    format "0.0"
  }
  column {
    header "^CCSMX^"  /* Compressed Class Space Capacity - Maximum */
    data sun.gc.compressedclassspace.maxCapacity
    scale K
    align right
    width 8
    format "0.0"
  }

我這裡對這些字段分類介紹下

MC & MU & CCSC & CCSU

• MC表示Klass Metaspace以及NoKlass Metaspace兩者總共committed的內存大小，單位是KB，雖然從上面的定義裡我們看到瞭是capacity，但是實質上計算的時候並不是capacity，而是committed，這個是要註意的

• MU這個無可厚非，說的就是Klass Metaspace以及NoKlass Metaspace兩者已經使用瞭的內存大小

• CCSC表示的是Klass Metaspace的已經被commit的內存大小，單位也是KB

• CCSU表示Klass Metaspace的已經被使用的內存大小

M & CCS

• M表示的是Klass Metaspace以及NoKlass Metaspace兩者總共的使用率，其實可以根據上面的四個指標算出來，即(CCSU+MU)/(CCSC+MC)

• CCS表示的是NoKlass Metaspace的使用率，也就是CCSU/CCSC算出來的

PS：所以我們有時候看到M的值達到瞭90%以上，其實這個並不一定說明metaspace用瞭很多瞭，因為內存是慢慢commit的，所以我們的分母是慢慢變大的，不過當我們committed到一定量的時候就不會再增長瞭

MCMN & MCMX & CCSMN & CCSMX

• MCMN和CCSMN這兩個值大傢可以忽略，一直都是0

• MCMX表示Klass Metaspace以及NoKlass Metaspace兩者總共的reserved的內存大小，比如默認情況下Klass Metaspace是通過CompressedClassSpaceSize這個參數來reserved 1G的內存，NoKlass Metaspace默認reserved的內存大小是2* InitialBootClassLoaderMetaspaceSize

• CCSMX表示Klass Metaspace reserved的內存大小

綜上所述，其實看metaspace最主要的還是看MC，MU，CCSC，CCSU這幾個具體的大小來判斷metaspace到底用瞭多少更靠譜

以上就是JVM完全解讀之Metaspace解密源碼分析的詳細內容，更多關於Metaspace源碼解密的資料請關註WalkonNet其它相關文章！

推薦閱讀：

• Java JVM虛擬機調優詳解
• Java JVM調優五大技能詳解
• 一篇帶你入門Java垃圾回收器
• java.lang.OutOfMemoryError: Metaspace異常解決的方法
• JVM中最耗cpu的線程查找方法