概述

如今JDK8成了主流，大家都緊鑼密鼓地進行著升級，享受著JDK8帶來的各種便利，然而有時候升級并沒有那么順利?比如說今天要說的這個問題。我們都知道JDK8在內存模型上***的改變是，放棄了Perm，迎來了Metaspace的時代。如果你對Metaspace還不熟，之前我寫過一篇介紹Metaspace的文章，大家有興趣的可以看看我前面的那篇文章。

我們之前一般在系統的JVM參數上都加了類似-XX:PermSize=256M -XX:MaxPermSize=256M的參數，升級到JDK8之后，因為Perm已經沒了，如果還有這些參數JVM會拋出一些警告信息，于是我們會將參數進行升級，比如直接將PermSize改成MetaspaceSize，MaxPermSize改成MaxMetaspaceSize，但是我們后面會發現一個問題，經常會看到Metaspace的OutOfMemory異常或者GC日志里提示Metaspace導致的Full GC，此時我們不得不將MaxMetaspaceSize以及MetaspaceSize調大到512M或者更大，幸運的話，發現問題解決了，后面沒再出現OOM，但是有時候也會很不幸，仍然會出現OOM。此時大家是不是非常疑惑了，代碼完全沒有變化，但是加載類貌似需要更多的內存?

之前我其實并沒有仔細去想這個問題，碰到這類OOM的問題，都覺得主要是Metaspace內存碎片的問題，因為之前幫人解決過類似的問題，他們構建了成千上萬個類加載器，確實也是因為Metsapce碎片的問題導致的，因為Metaspace并不會做壓縮，解決的方案主要是調大MetaspaceSize和MaxMetaspaceSize，并將它們設置相等。然后這次碰到的問題并不是這樣，類加載個數并不多，然而卻拋出了Metaspace的OutOfMemory異常，并且Full GC一直持續著，而且從jstat來看，Metaspace的GC前后使用情況基本不變，也就是GC前后基本沒有回收什么內存。

通過我們的內存分析工具看到的現象是同一個類加載器居然加載了同一個類多遍，內存里有多份類實例，這個我們可以通過加上-verbose:class的參數也能得到驗證，要輸出如下日志，那只有在不斷定義某個類才會輸出，于是想構建出這種場景來，于是簡單地寫了個demo來驗證

Demo

代碼很簡單，就是通過反射直接調用ClassLoader的defineClass方法來對某個類做重復的定義。

其中在JDK7下跑的JVM參數設置的是：

在JDK8下跑的JVM參數是：

大家可以通過jstat -gcutil <pid> 1000看看JDK7和JDK8下有什么不一樣，結果你會發現JDK7下Perm的使用率隨著FGC的進行GC前后不斷發生著變化，而Metsapce的使用率到一定階段之后GC前后卻一直沒有變化

JDK7下的結果:

JDK8下的結果：

重復類定義

重復類定義，從上面的Demo里已經得到了證明，當我們多次調用ClassLoader的defineClass方法的時候哪怕是同一個類加載器加載同一個類文件，在JVM里也會在對應的Perm或者Metaspace里創建多份Klass結構，當然一般情況下我們不會直接這么調用，但是反射提供了這么強大的能力，有些人還是會利用這種寫法，其實我想直接這么用的人對類加載的實現機制真的沒有全弄明白，包括這次問題發生的場景其實還是吸納進JDK里的jaxp/jaxws，比如它就存在這樣的代碼實現com.sun.xml.bind.v2.runtime.reflect.opt.Injector里的inject方法就存在直接調用的情況：

不過從2.2.2這個版本開始這種實現就改變了

所以大家如果還是使用jaxb-impl-2.2.2以下版本的請注意啦，升級到JDK8可能會存在本文說的問題。

重復類定義帶來的影響

那重復類定義會帶來什么危害呢?正常的類加載都會先走一遍緩存查找，看是否已經有了對應的類，如果有了就直接返回，如果沒有就進行定義，如果直接調用類定義的方法，在JVM里會創建多份臨時的類結構實例，這些相關的結構是存在Perm或者Metaspace里的，也就是說會消耗Perm或Metaspace的內存，但是這些類在定義出來之后，最終會做一次約束檢查，如果發現已經定義了，那就直接拋出LinkageError的異常

這樣這些臨時創建的結構，只能等待GC的時候去回收掉了，因為它們不可達，所以在GC的時候會被回收，那問題來了，為什么在Perm下能正常回收，但是在Metaspace里不能正常回收呢?

Perm和Metaspace在類卸載上的差異

這里我主要拿我們目前最常用的GC算法CMS GC舉例。

在JDK7 CMS下，Perm的結構其實和Old的內存結構是一樣的，如果Perm不夠的時候我們會做一次Full GC，這個Full GC默認情況下是會對各個分代做壓縮的，包括Perm，這樣一來根據對象的可達性，任何一個類都只會和一個活著的類加載器綁定，在標記階段將這些類標記成活的，并將他們進行新地址的計算及移動壓縮，而之前因為重復定義生成的類結構等，因為沒有將它們和任何一個活著的類加載器關聯(有個叫做SystemDictionary的Hashtable結構來記錄這種關聯)，從而在壓縮過程中會被回收掉。

在JDK8下，Metaspace是完全獨立分散的內存結構，由非連續的內存組合起來，在Metaspace達到了觸發GC的閾值的時候(和MaxMetaspaceSize及MetaspaceSize有關)，就會做一次Full GC，但是這次Full GC，并不會對Metaspace做壓縮，唯一卸載類的情況是，對應的類加載器必須是死的，如果類加載器都是活的，那肯定不會做卸載的事情了

從上面貼的代碼我們也能看出來，JDK7里會對Perm做壓縮，然后JDK8里并不會對Metaspace做壓縮，從而只要和那些重復定義的類相關的類加載一直存活，那將一直不會被回收，但是如果類加載死了，那就會被回收，這是因為那些重復類都是在和這個類加載器關聯的內存塊里分配的，如果這個類加載器死了，那整塊內存會被清理并被下次重用。

如何證明壓縮能回收Perm里的重復類

在沒看GC源碼的情況下，有什么辦法來證明Perm在FGC下的回收是因為壓縮而導致那些重復類被回收呢?大家可以改改上面的測試用例，將***那個死循環改一下：

在System.gc那里設置個斷點，然后再通過jstat -gcutil <pid> 1000來看Perm的使用率是否發生變化，另外你再加上-XX:+ ExplicitGCInvokesConcurrent再重復上面的動作，你看看輸出是怎樣的，為什么這個可以證明，大家可以想一想。

【本文是51CTO專欄作者李嘉鵬的原創文章，轉載請通過微信公眾號(你假笨，id:lovestblog)聯系作者本人獲取授權】

戳這里，看該作者更多好文