正擼著代碼，公司內(nèi)的聊天工具彈出一條信息：
“狼哥，我這個(gè)機(jī)器總是頻繁FGC...”
我趕緊打開對話框，機(jī)智的回復(fù)一個(gè)表情
然后繼續(xù)默默擼碼。
隨后，小伙伴砸了一段GC日志過來
2019-09-17T20:33:57.889+0800: 4753520.554: [Full GC (Metadata GC Threshold) 4753520.554: [CMS[YG occupancy: 723220 K (1887488 K)]4753520.988: [weak refs process ing, 0.0042134 secs]4753520.992: [class unloading, 0.0987343 secs]4753521.091: [scrub symbol table, 0.0237609 secs]4753521.115: [scrub string table, 0.0025983 s ecs]: 145423K->141376K(3354624K), 0.6260023 secs] 868644K->864597K(5242112K), [Metaspace: 128179K->128179K(1234944K)], 0.6264315 secs] [Times: user=1.24 sys=0.0 0, real=0.63 secs]
4159962 Heap after GC invocations=8029 (full 50):
4159963 par new generation total 1887488K, used 723220K [0x0000000673400000, 0x00000006f3400000, 0x00000006f3400000)
4159964 eden space 1677824K, 42% used [0x0000000673400000, 0x000000069ed59090, 0x00000006d9a80000)
4159965 from space 209664K, 4% used [0x00000006d9a80000, 0x00000006da36c210, 0x00000006e6740000)
4159966 to space 209664K, 0% used [0x00000006e6740000, 0x00000006e6740000, 0x00000006f3400000)
4159967 concurrent mark-sweep generation total 3354624K, used 141376K [0x00000006f3400000, 0x00000007c0000000, 0x00000007c0000000)
4159968 Metaspace used 128145K, capacity 136860K, committed 262144K, reserved 1234944K
4159969 class space used 14443K, capacity 16168K, committed 77312K, reserved 1048576K
4159970 }
4159971 {Heap before GC invocations=8029 (full 50):
4159972 par new generation total 1887488K, used 723220K [0x0000000673400000, 0x00000006f3400000, 0x00000006f3400000)
4159973 eden space 1677824K, 42% used [0x0000000673400000, 0x000000069ed59090, 0x00000006d9a80000)
4159974 from space 209664K, 4% used [0x00000006d9a80000, 0x00000006da36c210, 0x00000006e6740000)
4159975 to space 209664K, 0% used [0x00000006e6740000, 0x00000006e6740000, 0x00000006f3400000)
4159976 concurrent mark-sweep generation total 3354624K, used 141376K [0x00000006f3400000, 0x00000007c0000000, 0x00000007c0000000)
4159977 Metaspace used 128145K, capacity 136860K, committed 262144K, reserved 1234944K
4159978 class space used 14443K, capacity 16168K, committed 77312K, reserved 1048576K
我這慧眼一瞧，看到了幾個(gè)關(guān)鍵單詞Full GC 、Metadata GC Threshold，然后很隨意的回復(fù)了
“是不是metaspace沒有設(shè)置，或者設(shè)置太小，導(dǎo)致了FGC” 外加一個(gè)得意的表情
然后，又砸過來一段JVM參數(shù)配置
CATALINA_OPTS="$CATALINA_OPTS -server -Djava.awt.headless=true -Xms5324m -Xmx5324m -Xss512k -XX:PermSize=350m -XX:MaxPermSize=350m -XX:MetaspaceSize=256m -XX:MaxMet aspaceSize=256m -XX:NewSize=2048m -XX:MaxNewSize=2048m -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=9 -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX :+CMSScavengeBeforeRemark -XX:+ScavengeBeforeFullGC -XX:+UseCMSCompactAtFullCollection -XX:+CMSParallelRemarkEnabled -XX:CMSFullGCsBeforeCompaction=9 -XX:CMSInitiat ingOccupancyFraction=80 -XX:+CMSClassUnloadingEnabled -XX:SoftRefLRUPolicyMSPerMB=0 -XX:-ReduceInitialCardMarks -XX:+CMSPermGenSweepingEnabled -XX:CMSInitiatingPerm OccupancyFraction=80 -XX:+ExplicitGCInvokesConcurrent -Djava.nio.channels.spi.SelectorProvider=[sun.nio.ch](http://sun.nio.ch/).EPollSelectorProvider -Djava.util.logging.manager=org.apac he.juli.ClassLoaderLogManager -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintHeapAtGC -Xloggc:/data/applogs/heap_trace.txt -XX:+IgnoreUnrecognizedVMOptions -XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/applogs/HeapDumpOnOutOfMemoryError"
“應(yīng)該不是，我們配置了-XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m”
看到配置之后，有點(diǎn)懵逼，好像超出了我的認(rèn)知范圍，一下子沒回復(fù)，又扔過來一堆數(shù)據(jù)。
“看cat監(jiān)控?cái)?shù)據(jù)，Metaspace使用率在50%的時(shí)候就FGC了，GC 日志上的顯示也只用了142M，可是我們明明設(shè)置了初始值是256M，最大值250M，這還沒達(dá)到閾值”
機(jī)智如我，趕緊回復(fù) “等等，我空的時(shí)候再看看”
等空閑下來，我又想起了這個(gè)問題，決定好好研究下。
既然是Metadata GC Threshold引起的FGC，那么只可能是MetadataSpace使用完了，我又反復(fù)的看了下GC日志片段，盯著下面看了會
[0x00000006f3400000, 0x00000007c0000000, 0x00000007c0000000)
4159977 Metaspace used 128145K, capacity 136860K, committed 262144K, reserved 1234944K
發(fā)生FGC之前，Metaspace的committed確實(shí)達(dá)到了256M，
我們需要知道一點(diǎn)：當(dāng)目前的committed內(nèi)存+當(dāng)前需要分配的內(nèi)存達(dá)到Metaspace閾值，就會發(fā)生Metadata GC Threshold的FGC。
看到這里，我們也能大概猜出了，這次FGC是合理的。
但是，為什么used指標(biāo)只有125M，卻還要申請其它內(nèi)存？
看來只有一個(gè)原因可以解釋了：內(nèi)存碎片。
之前只聽過老年代因?yàn)镃MS的標(biāo)記清理會產(chǎn)生內(nèi)存碎片導(dǎo)致FGC，為什么Metaspace也會有這樣的問題？
讓同事對有問題的機(jī)器dump了下，用mat打開之后，發(fā)現(xiàn)了一個(gè)新大陸，包含了大量的類加載器。
難道這個(gè)碎片問題是大量類加載器引起的？
本地驗(yàn)證
有了這個(gè)疑問，那就簡單了，看看能不能在本地復(fù)現(xiàn)。
1、先定義一個(gè)自定義的類加載器，破壞雙親委派
public class MyClassLoader extends ClassLoader {
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try{
String filePath = "/Users/zhanjun/Desktop/" + name.replace('.', File.separatorChar) + ".class";
//指定讀取磁盤上的某個(gè)文件夾下的.class文件：
File file = new File(filePath);
FileInputStream fis = new FileInputStream(file);
byte[] bytes = new byte[fis.available()];
fis.read(bytes);
//調(diào)用defineClass方法，將字節(jié)數(shù)組轉(zhuǎn)換成Class對象
Class<?> clazz = this.defineClass(name, bytes, 0, bytes.length);
fis.close();
return clazz;
}catch (FileNotFoundException e){
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} finally {
}
return super.findClass(name);
}
}
2、然后在while循環(huán)中，不斷的 load 已經(jīng)編譯好的class文件
public static void main(String[] args) throws Exception {
while (true) {
Class clazz0 = new MyClassLoader().loadClass("com.sankuai.discover.memory.OOM");
}
}
3、最后，配置一下jvm啟動參數(shù)
-Xmx2688M -Xms2688M -Xmn960M -XX:MetaspaceSize=50M -XX:MaxMetaspaceSize=100M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+UseConcMarkSweepGC
啟動之后，不一會兒在控制臺果然出現(xiàn)了日志
{Heap before GC invocations=0 (full 0):
par new generation total 884736K, used 330302K [0x0000000752400000, 0x000000078e400000, 0x000000078e400000)
eden space 786432K, 42% used [0x0000000752400000, 0x000000076668fae0, 0x0000000782400000)
from space 98304K, 0% used [0x0000000782400000, 0x0000000782400000, 0x0000000788400000)
to space 98304K, 0% used [0x0000000788400000, 0x0000000788400000, 0x000000078e400000)
concurrent mark-sweep generation total 1769472K, used 0K [0x000000078e400000, 0x00000007fa400000, 0x00000007fa400000)
Metaspace used 22636K, capacity 102360K, committed 102400K, reserved 1118208K
class space used 8829K, capacity 33008K, committed 33008K, reserved 1048576K
2019-09-21T16:09:28.562-0800: [Full GC (Metadata GC Threshold) 2019-09-21T16:09:28.562-0800: [CMS: 0K->5029K(1769472K), 0.0987115 secs] 330302K->5029K(2654208K), [Metaspace: 22636K->22636K(1118208K)], 0.1340367 secs] [Times: user=0.11 sys=0.03, real=0.13 secs]
Heap after GC invocations=1 (full 1):
par new generation total 884736K, used 0K [0x0000000752400000, 0x000000078e400000, 0x000000078e400000)
eden space 786432K, 0% used [0x0000000752400000, 0x0000000752400000, 0x0000000782400000)
from space 98304K, 0% used [0x0000000782400000, 0x0000000782400000, 0x0000000788400000)
to space 98304K, 0% used [0x0000000788400000, 0x0000000788400000, 0x000000078e400000)
concurrent mark-sweep generation total 1769472K, used 5029K [0x000000078e400000, 0x00000007fa400000, 0x00000007fa400000)
Metaspace used 2885K, capacity 4500K, committed 43008K, reserved 1058816K
class space used 291K, capacity 388K, committed 33008K, reserved 1048576K
}
從日志可以看出來，發(fā)生FGC之前，used大概22M，committed已經(jīng)達(dá)到100M，這時(shí)再加載class的時(shí)候，需要申請內(nèi)存，就不夠了，只能通過FGC對Metaspace的內(nèi)存進(jìn)行整理壓縮。
到現(xiàn)在，我們已經(jīng)驗(yàn)證了過多的類加載器確實(shí)可以引起FGC。
內(nèi)存碎片是怎么產(chǎn)生的？
其實(shí)，JVM內(nèi)部為了實(shí)現(xiàn)高效分配，在類加載器第一次加載類的時(shí)候，會在Metaspace分配一個(gè)獨(dú)立的內(nèi)存塊，隨后該類加載加載的類信息都保存在該內(nèi)存塊。但如果這個(gè)類加載器只加載了一個(gè)類或者少數(shù)類，那這塊內(nèi)存就被浪費(fèi)了，如果類加載器又特別多，那內(nèi)存碎片就產(chǎn)生了。
