概述

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

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

• 為什么會有metaspace
• metaspace的組成
• metaspace的VM參數(shù)
• jstat里我們應該關注metaspace的哪些值

為什么會有metaspace

metaspace的由來民間已有很多傳說，不過我這里只談我自己的理解，因為我不是oracle參與這塊的開發(fā)者，所以對其真正的由來不怎么了解。

我們都知道jdk8之前有perm這一整塊內(nèi)存來存klass等信息，我們的參數(shù)里也必不可少地會配置-XX:PermSize以及-XX:MaxPermSize來控制這塊內(nèi)存的大小，jvm在啟動的時候會根據(jù)這些配置來分配一塊連續(xù)的內(nèi)存塊，但是隨著動態(tài)類加載的情況越來越多，這塊內(nèi)存我們變得不太可控，到底設置多大合適是每個開發(fā)者要考慮的問題，如果設置太小了，系統(tǒng)運行過程中就容易出現(xiàn)內(nèi)存溢出，設置大了又總感覺浪費，盡管不會實質(zhì)分配這么大的物理內(nèi)存?；谶@么一個可能的原因，于是metaspace出現(xiàn)了，希望內(nèi)存的管理不再受到限制，也不要怎么關注元數(shù)據(jù)這塊的OOM問題，雖然到目前來看，也并沒有完美地解決這個問題。

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

metaspace的組成

metaspace其實由兩大部分組成

• Klass Metaspace
• NoKlass Metaspace

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

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

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

metaspace的幾個參數(shù)

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

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

UseLargePagesInMetaspace

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

InitialBootClassLoaderMetaspaceSize

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

MetaspaceSize

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

MaxMetaspaceSize

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

CompressedClassSpaceSize

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

MinMetaspaceExpansion

MinMetaspaceExpansion和MaxMetaspaceExpansion這兩個參數(shù)或許和大家認識的并不一樣，也許很多人會認為這兩個參數(shù)不就是內(nèi)存不夠的時候，然后擴容的最小大小嗎？其實不然

這兩個參數(shù)和擴容其實并沒有直接的關系，也就是并不是為了增大committed的內(nèi)存，而是為了增大觸發(fā)metaspace GC的閾值

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

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

MaxMetaspaceExpansion

默認5.2M，增大觸發(fā)metaspace GC閾值的最大要求。假如說我們要分配的內(nèi)存超過了MinMetaspaceExpansion但是低于MaxMetaspaceExpansion，那增量是MaxMetaspaceExpansion，如果超過了MaxMetaspaceExpansion，那增量是MinMetaspaceExpansion加上要分配的內(nèi)存大小

注：每次分配只會給對應的線程一次擴展觸發(fā)metaspace GC閾值的機會，如果擴展了，但是還不能分配，那就只能等著做GC了

MinMetaspaceFreeRatio

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

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

這個參數(shù)主要是為了避免觸發(fā)metaspaceGC的閾值和gc之后committed的內(nèi)存的量比較接近，于是將這個閾值進行擴大

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

注：這里不用gc之后used的量來算，主要是擔心可能出現(xiàn)committed的量超過了觸發(fā)metaspaceGC的閾值，這種情況一旦發(fā)生會很危險，會不斷做gc，這應該是jdk8在某個版本之后才修復的bug

MaxMetaspaceFreeRatio

默認70，這個參數(shù)和上面的參數(shù)基本是相反的，是為了避免觸發(fā)metaspaceGC的閾值過大，而想對這個值進行縮小。這個參數(shù)在gc之后committed的內(nèi)存比較小的時候并且離觸發(fā)metaspaceGC的閾值比較遠的時候，調(diào)整會比較明顯

jstat里的metaspace字段

我們看GC是否異常，除了通過GC日志來做分析之外，我們還可以通過jstat這樣的工具展示的數(shù)據(jù)來分析，前面我公眾號里有篇文章介紹了jstat這塊的實現(xiàn)，有興趣的可以到我的公眾號你假笨里去翻閱下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的內(nèi)存大小，單位是KB，雖然從上面的定義里我們看到了是capacity，但是實質(zhì)上計算的時候并不是capacity，而是committed，這個是要注意的

• MU這個無可厚非，說的就是Klass Metaspace以及NoKlass Metaspace兩者已經(jīng)使用了的內(nèi)存大小

• CCSC表示的是Klass Metaspace的已經(jīng)被commit的內(nèi)存大小，單位也是KB

• CCSU表示Klass Metaspace的已經(jīng)被使用的內(nèi)存大小

M & CCS

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

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

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

MCMN & MCMX & CCSMN & CCSMX

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

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

• CCSMX表示Klass Metaspace reserved的內(nèi)存大小

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

以上就是JVM完全解讀之Metaspace解密源碼分析的詳細內(nèi)容，更多關于Metaspace源碼解密的資料請關注腳本之家其它相關文章！