概述

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

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

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

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

Demo

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

其中在JDK7下跑的JVM參數(shù)設(shè)置的是：

在JDK8下跑的JVM參數(shù)是：

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

JDK7下的結(jié)果:

JDK8下的結(jié)果：

重復(fù)類定義

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

不過從2.2.2這個版本開始這種實現(xiàn)就改變了

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

重復(fù)類定義帶來的影響

那重復(fù)類定義會帶來什么危害呢?正常的類加載都會先走一遍緩存查找，看是否已經(jīng)有了對應(yīng)的類，如果有了就直接返回，如果沒有就進(jìn)行定義，如果直接調(diào)用類定義的方法，在JVM里會創(chuàng)建多份臨時的類結(jié)構(gòu)實例，這些相關(guān)的結(jié)構(gòu)是存在Perm或者M(jìn)etaspace里的，也就是說會消耗Perm或Metaspace的內(nèi)存，但是這些類在定義出來之后，最終會做一次約束檢查，如果發(fā)現(xiàn)已經(jīng)定義了，那就直接拋出LinkageError的異常

這樣這些臨時創(chuàng)建的結(jié)構(gòu)，只能等待GC的時候去回收掉了，因為它們不可達(dá)，所以在GC的時候會被回收，那問題來了，為什么在Perm下能正常回收，但是在Metaspace里不能正?；厥漳?

Perm和Metaspace在類卸載上的差異

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

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

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

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

如何證明壓縮能回收Perm里的重復(fù)類

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

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

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

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