柳暗花明又一村

問題一下子明朗了起來，「隨著每次接口的調(diào)用，極有可能是某個(gè)類都在不斷的被創(chuàng)建，占用了元空間的內(nèi)存」。

觀察JVM類加載情況 -verbose

?  

在調(diào)試程序時(shí)，有時(shí)需要查看程序加載的類、內(nèi)存回收情況、調(diào)用的本地接口等。這時(shí)候就需要-verbose命令。在myeclipse可以通過右鍵設(shè)置（如下），也可以在命令行輸入java -verbose來查看。

?  

-verbose:class 查看類加載情況
-verbose:gc 查看虛擬機(jī)中內(nèi)存回收情況
-verbose:jni 查看本地方法調(diào)用的情況

我們?cè)诒镜丨h(huán)境，添加啟動(dòng)參數(shù)-verbose:class循環(huán)調(diào)用接口。

可以看到生成了無數(shù)com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto:

[Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar]
[Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar]
[Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar]
[Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar]
[Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar]
[Loaded com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto from file:/C:/Users/yangzhendong01/.m2/repository/com/alibaba/fastjson/1.2.71/fastjson-1.2.71.jar]

當(dāng)調(diào)用了很多次，積攢了一定的類時(shí)，我們手動(dòng)執(zhí)行Full GC，進(jìn)行類加載器的回收，我們發(fā)現(xiàn)大量的fastjson相關(guān)類被回收。

 

「如果在回收前，使用jmap查看類加載情況，同樣也可以發(fā)現(xiàn)大量的fastjson相關(guān)類：」

jmap -clstats 7984

 

這下有了方向，「這次仔細(xì)排查代碼」，查看代碼邏輯里哪里用到了fastjson，發(fā)現(xiàn)了如下代碼：

/**
 * 返回Json字符串.駝峰轉(zhuǎn)_
 * @param bean 實(shí)體類.
 */
public static String buildData(Object bean) {
    try {
        SerializeConfig CONFIG = new SerializeConfig();
        CONFIG.propertyNamingStrategy = PropertyNamingStrategy.SnakeCase;
        return jsonString = JSON.toJSONString(bean, CONFIG);
    } catch (Exception e) {
        return null;
    }
}

問題根因

我們?cè)谡{(diào)用wcs前將駝峰字段的實(shí)體類序列化成下劃線字段，**這需要使用fastjson的SerializeConfig，而我們?cè)陟o態(tài)方法中對(duì)其進(jìn)行了實(shí)例化。SerializeConfig創(chuàng)建時(shí)默認(rèn)會(huì)創(chuàng)建一個(gè)ASM代理類用來實(shí)現(xiàn)對(duì)目標(biāo)對(duì)象的序列化。也就是上面被頻繁創(chuàng)建的類com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto,如果我們復(fù)用SerializeConfig，fastjson會(huì)去尋找已經(jīng)創(chuàng)建的代理類，從而復(fù)用。但是如果new SerializeConfig()，則找不到原來生成的代理類，就會(huì)一直去生成新的WlkCustomerDto代理類。

下面兩張圖時(shí)問題定位的源碼：

 

 

我們將SerializeConfig作為類的靜態(tài)變量，問題得到了解決。

private static final SerializeConfig CONFIG = new SerializeConfig();

static {
    CONFIG.propertyNamingStrategy = PropertyNamingStrategy.SnakeCase;
}

fastjson SerializeConfig 做了什么

SerializeConfig介紹：

?  

SerializeConfig的主要功能是配置并記錄每種Java類型對(duì)應(yīng)的序列化類（ObjectSerializer接口的實(shí)現(xiàn)類），比如Boolean.class使用BooleanCodec（看命名就知道該類將序列化和反序列化實(shí)現(xiàn)寫到一起了）作為序列化實(shí)現(xiàn)類，float[].class使用FloatArraySerializer作為序列化實(shí)現(xiàn)類。這些序列化實(shí)現(xiàn)類，有的是FastJSON中默認(rèn)實(shí)現(xiàn)的（比如Java基本類），有的是通過ASM框架生成的（比如用戶自定義類），有的甚至是用戶自定義的序列化類（比如Date類型框架默認(rèn)實(shí)現(xiàn)是轉(zhuǎn)為毫秒，應(yīng)用需要轉(zhuǎn)為秒）。當(dāng)然，這就涉及到是使用ASM生成序列化類還是使用JavaBean的序列化類類序列化的問題，這里判斷根據(jù)就是是否Android環(huán)境（環(huán)境變量"java.vm.name"為"dalvik"或"lemur"就是Android環(huán)境），但判斷不僅這里一處，后續(xù)還有更具體的判斷。

?  

理論上來說，每個(gè)SerializeConfig實(shí)例若序列化相同的類，都會(huì)找到之前生成的該類的代理類，來進(jìn)行序列化。們的服務(wù)在每次接口被調(diào)用時(shí)，都實(shí)例化一個(gè)ParseConfig對(duì)象來配置Fastjson反序列的設(shè)置，而未禁用ASM代理的情況下，由于每次調(diào)用ParseConfig都是一個(gè)新的實(shí)例，因此永遠(yuǎn)也檢查不到已經(jīng)創(chuàng)建的代理類，所以Fastjson便不斷的創(chuàng)建新的代理類，并加載到metaspace中，最終導(dǎo)致metaspace不斷擴(kuò)張，將機(jī)器的內(nèi)存耗盡。

升級(jí)JDK1.8才會(huì)出現(xiàn)問題

導(dǎo)致問題發(fā)生的原因還是值得重視。為什么在升級(jí)之前不會(huì)出現(xiàn)這個(gè)問題？這就要分析jdk1.8和1.7自帶的hotspot虛擬機(jī)的差異了。

?  

從jdk1.8開始，自帶的hostspot虛擬機(jī)取消了過去的永久區(qū)，而新增了metaspace區(qū)，從功能上看，metaspace可以認(rèn)為和永久區(qū)類似，其最主要的功用也是存放類元數(shù)據(jù)，但實(shí)際的機(jī)制則有較大的不同。

首先，metaspace默認(rèn)的最大值是整個(gè)機(jī)器的物理內(nèi)存大小，所以metaspace不斷擴(kuò)張會(huì)導(dǎo)致java程序侵占系統(tǒng)可用內(nèi)存，最終系統(tǒng)沒有可用的內(nèi)存；而永久區(qū)則有固定的默認(rèn)大小，不會(huì)擴(kuò)張到整個(gè)機(jī)器的可用內(nèi)存。當(dāng)分配的內(nèi)存耗盡時(shí)，兩者均會(huì)觸發(fā)full gc，但不同的是永久區(qū)在full gc時(shí)，以堆內(nèi)存回收時(shí)類似的機(jī)制去回收永久區(qū)中的類元數(shù)據(jù)（Class對(duì)象），只要是根引用無法到達(dá)的對(duì)象就可以回收掉，而metaspace判斷類元數(shù)據(jù)是否可以回收，是根據(jù)加載這些類元數(shù)據(jù)的Classloader是否可以回收來判斷的，只要Classloader不能回收，通過其加載的類元數(shù)據(jù)就不會(huì)被回收。這也就解釋了我們這兩個(gè)服務(wù)為什么在升級(jí)到1.8之后才出現(xiàn)問題，因?yàn)樵谥暗膉dk版本中，雖然每次調(diào)用fastjson都創(chuàng)建了很多代理類，在永久區(qū)中加載類很多代理類的Class實(shí)例，但這些Class實(shí)例都是在方法調(diào)用是創(chuàng)建的，調(diào)用完成之后就不可達(dá)了，因此永久區(qū)內(nèi)存滿了觸發(fā)full gc時(shí)，都會(huì)被回收掉。

而使用1.8時(shí)，因?yàn)檫@些代理類都是通過主線程的Classloader加載的，這個(gè)Classloader在程序運(yùn)行的過程中永遠(yuǎn)也不會(huì)被回收，因此通過其加載的這些代理類也永遠(yuǎn)不會(huì)被回收，這就導(dǎo)致metaspace不斷擴(kuò)張，最終耗盡機(jī)器的內(nèi)存了。

?  

這個(gè)問題并不局限于fastjson，只要是需要通過程序加載創(chuàng)建類的地方，就有可能出現(xiàn)這種問題。「尤其是在框架中，往往大量采用類似ASM、javassist等工具進(jìn)行字節(jié)碼增強(qiáng)，而根據(jù)上面的分析，在jdk1.8之前，因?yàn)榇蠖鄶?shù)情況下動(dòng)態(tài)加載的Class都能夠在full gc時(shí)得到回收，因此不容易出現(xiàn)問題」，也因此很多框架、工具包并沒有針對(duì)這個(gè)問題做一些處理，一旦升級(jí)到1.8之后，這些問題就可能會(huì)暴露出來。

問題解決了，接下來復(fù)盤下整個(gè)排查問題的流程，整個(gè)流程暴露了我很多問題，最主要的就是「對(duì)于JVM不同版本的內(nèi)存分配還不夠熟悉」，導(dǎo)致了對(duì)于老生代和元空間判斷失誤，走了很多彎路，在直接內(nèi)存中排查了很久，浪費(fèi)了很多時(shí)間。

其次，排查需要的「一是仔細(xì)，二是全面，」，最好將所有可能性先行整理好，不然很容易陷入自己設(shè)定好的排查范圍內(nèi)，走進(jìn)死胡同不出來。

最后，總結(jié)一下這次的問題帶來的收獲：

• JDK1.8開始，自帶的hostspot虛擬機(jī)取消了過去的永久區(qū)，而新增了metaspace區(qū)，從功能上看，metaspace可以認(rèn)為和永久區(qū)類似，其最主要的功用也是存放類元數(shù)據(jù)，但實(shí)際的機(jī)制則有較大的不同。
• 對(duì)于JVM里面的內(nèi)存需要在啟動(dòng)時(shí)進(jìn)行限制，包括我們熟悉的堆內(nèi)存，也要包括直接內(nèi)存和元生區(qū)，這是保證線上服務(wù)正常運(yùn)行最后的兜底。
• 使用類庫，請(qǐng)多注意代碼的寫法，盡量不要出現(xiàn)明顯的內(nèi)存泄漏。
• 對(duì)于使用了ASM等字節(jié)碼增強(qiáng)工具的類庫，在使用他們時(shí)請(qǐng)多加小心（尤其是JDK1.8以后）。