線上問題

雙12之前壓測的時候起了很小的量，直接觸發了Full GC，嚇尿了，因為馬上雙12大促預熱就要開始了，這搞不好妥妥的3.25啦。

趕緊拉群，把相關同學拉在一起排查問題。

第一時間查看GC日志：

可以看到原因是超過了Metadata GC的閾值，觸發了Full GC，Metaspace從243M 回收到231M，基本沒怎么回收掉，所以稍微再來點量，很容易再次觸發Metaspace 的回收。

知識儲備

GC問題排查需要很多儲備知識，最主要是JVM相關的，之前文章已經講過一些了，這里主要講Matespace是什么？后面講怎么做的GC問題的排查。

這里有二個知識點：

• Matespace（元空間）是什么？在JVM中扮演什么角色，也就是存放什么的？
• Full GC跟Matespace 大小設置有什么關系？

Matespace叫做元空間，從JDK 8開始，永久代(PermGen)的概念被廢棄掉了，取而代之的是一個稱為Metaspace的存儲空間。

Metaspace用來存放：Class文件在JVM 里的運行時數據結構；以及存Klass相關的其他的內容，比如Method，ConstantPool等。

Metaspace使用的是本地內存，而不是堆內存，也就是說在默認情況下Metaspace的大小只與本地內存大小有關。但是很容易有個誤區是Matespace可以隨便用，不管使用多少，只要不超本地內存就不會觸發GC，這是錯誤的。

Matespace的設置方式是：-XX: MetaspaceSize=**M, 這個JVM參數的作用是讓Matespace 達到MetaspaceSize時觸發Full GC, 如果不設置Matespace, 默認值很小，也就 20M左右(不同系統會有一點差別)，如果程序Load Class比較多，很容易觸發Full GC。這里要明白的是Class信息和加載Class 的ClassLoader 都存放在Metaspace，我們知道一個類是由這個類的類加載器加上全限定名（由包名&類名組成）確定唯一性的。

所以大家可以檢查一下自己應用JVM Metaspace 設置的大小，如果沒設置可以通過 -XX:+PrintFlagsInitial 查看一下默認值。

（之前文章發過GC日志的詳細講解以及JVM 參數的配置說明，如果有疑問的同學可以去看看歷史文章。）

問題排查

剛開始看到 Full GC頻繁，查看日志是由于Metaspace 空間不夠造成的，第一反應是調整Metaspace 大小，把MetaspaceSize 從256M提高到了512M。但是發現Metaspace引發的Full GC還是沒有消除。

立即dump了二臺機器的日志，第一次分析GC 日志文件，沒發現異常，這里有個注意的地方，大家dump文件時機很重要，有時候dump 的GC 日志沒問題是因為剛好 Full GC完成之后dump的，內存回收的干干凈凈，有些內存緩慢增加的問題一定要在Full GC前dump。

期間我們還發現緩存相關的對象占用內存較高，但是經過分析，緩存對象生命周期本身就比較長，所以常駐在堆上，沒有問題，繼續看。

排查發現Metaspace內存占用是隨著雙12新接口壓測流量的增長而增長，所以可以確定是新接口代碼引入。

分析GC dump日志發現可疑點，同一個ClassCloader 加載了接近3000個，如下圖所示，前面我們說過，ClassCloader 信息在Metaspace 區域。

破案了，fastjson使用不當引入了ASM Serializer的坑。

故障定位&修復

FastJson之所以快，原因就是使用asm字節碼增強替代了反射。所以肯定是代碼中應用了fastjson的ASM處理數據時造成的頻繁加載同一個類，基本問題清楚了，那就是擼代碼了，很快就定位了問題代碼。

因為保密原因，不方便放原始代碼，安琪拉擼了個類似邏輯的代碼：

for(Item item -> arrays) {
  SerializeConfig serializeConfig = new SerializeConfig();
   serializeConfig.put(Custom.class, new CustomSerializer());
   jsonString = JSON.toJSONString(item, serializeConfig);
}

這段代碼是自定義了一個序列化實現類CustomSerializer，在進行序列化時進行了一個類似AOP的切面處理，對所有Custom類型的字段進行統一自定義序列化（使用CustomSerializer）。

實現原理上是對需要序列化的Class使用asm動態生成了代理類，在這里就是Item類，使用SerializeConfig配置動態生成字節碼代理類: com.alibaba.fastjson.serializer.ASMSerializer_1_Item，但是每次new SerializeConfig對象，會當作每次代理的目標是不一樣的，導致每次會使用一個新的類加載器ASMClassLoader，所以Metaspace很快就滿了，觸發了頻繁Full GC。

如果希望深入研究可以看下FastJson源碼：

com.alibaba.fastjson.serializer.SerializeConfig#createASMSerializer

問題修復：

注冊ObjectSerializer，讓ObjectSerializer 成為全局唯一的，相當于是單例的。

SerializeConfig.getGlobalInstance().put(Character.class, new CharacterSerializer()); 

SerializeConfig 改成單例的后，每次序列化不用重復加載。

類似問題排查 & 調優

1. 如果dump 日志發現很多classloader 名稱前綴相同，排查是否有這種動態代理技術的使用，可能在不斷生成代理對象。
2. 發現內存緩慢增長，GC回收不掉，dump GC日志，查看是否有類被重復加載；
3. Metaspace調優，比如我們現在生產環境 Metaspace 基本會設置256M 或者512M，可以根據應用的類型和機器內存配置來決定，因素：1. 是否會加載比較多的類，2. 機器內存允許, 可以適當調大Metaspace。