干貨，記一次Metaspace導(dǎo)致頻繁fgc的問題排查過程-創(chuàng)新互聯(lián)

最近線上有一條機器在運行了10幾天后出現(xiàn)告警，頻繁出現(xiàn)fgc，在切斷流量之后，從運維那邊拿了應(yīng)用的heapdump文件。在一開始出現(xiàn)fgc時，我就上了容器平臺查看了gc日志，gc日志如下：

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供上猶網(wǎng)站建設(shè)、上猶做網(wǎng)站、上猶網(wǎng)站設(shè)計、上猶網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、上猶企業(yè)網(wǎng)站模板建站服務(wù)，十多年上猶做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

從日志中可以看出很明顯優(yōu)于metaspace空間不夠造成的fgc，而且不斷進行fgc，且metaspace空間回收不了。于是查看一下jvm啟動參數(shù)，參數(shù)如下：

這里Metaspace和MaxMetaspace都設(shè)置成了256M，奇怪了gc日志中Metaspace才使用了165M就出現(xiàn)了fgc，難道是新加載的類90M的空間嗎，這個可以肯定不是，如果不是新申請90M的空間這個原因引起的，那么就只有metaspace內(nèi)存碎片引起的了。于是通過mat分析heapdump，發(fā)現(xiàn) DelegatingClassLoader有1100多個，于是先查看一下 DelegatingClassLoader是個什么東西？其屬于sun.reflect包下，代碼如下：

classDelegatingClassLoader?extendsClassLoader?{?DelegatingClassLoader(ClassLoader?var1)?{?super(var1);?}

證明其確實一個ClassLoader。

那到底是什么對象在引用這些ClassLoader呢，通過mat發(fā)現(xiàn)是 GeneratedMethodAccessor在引用這些ClassLoader，繼續(xù)跟蹤發(fā)現(xiàn)是mybatis的Reflector應(yīng)用了這些對象。好辦了，于是繼續(xù)查看了Reflector的代碼，代碼片段如下：

privateMap<String,?Invoker>?setMethods=?newHashMap<String,?Invoker>();privateMap<String,?Invoker>?getMethods=?newHashMap<String,?Invoker>();privateMap<String,?Class<?>>?setTypes=?newHashMap<String,?Class<?>>();privateMap<String,?Class<?>>?getTypes=?newHashMap<String,?Class<?>>();

這個Reflector對象會緩存orm中實體類的getter setter方法，mybatis需要將表中的記錄轉(zhuǎn)換成java實體類，為了提高反射的效率將實體類的方法、構(gòu)造函數(shù)等緩存起來了，Mybatis會在運行的過程中通過 ReflectorFactory為每一個實體類創(chuàng)建一個 Reflector方便后續(xù)進行反射調(diào)用。

問題來了，為什么會有這么多的 DelegatingClassLoader呢？通過mat可以分析出來，這些ClassLoader最終都是被java的 Method對象所引用的。

于是分析Method的創(chuàng)建過程和Method的調(diào)用過程，最終發(fā)現(xiàn)Method在調(diào)用過程會創(chuàng)建一個MethodAccessor并將MehtodAccessor作為存在一個叫做methodAccessor的field中，java為了提高反射調(diào)用的性能，用了一種膨脹（inflation）的方式（從jni調(diào)用轉(zhuǎn)換成classbytes調(diào)用），通過參數(shù)-Dsun.reflect.inflationThreshold進行控制默認(rèn)15，在小于這個次數(shù)時會使用native的方式對方法進行調(diào)用，如果method的調(diào)用次數(shù)超過指定次數(shù)就會使用字節(jié)碼的方式生成方法調(diào)用，如果使用字節(jié)碼的方式最終會為每一個方法都生成 DelegatingClassLoader。具體的源碼如下：Method.invoke方法：

Method.acquireMethodAccessor方法：

ReflectionFactory.newMethodAccessor方法：

NativeMethodAccessorImpl.invoke方法：

publicObject?invoke(Object?var1,?Object[]?var2)?throwsIllegalArgumentException,?InvocationTargetException?{?if(++this.numInvocations?>?ReflectionFactory.inflationThreshold()?&&?!ReflectUtil.isVMAnonymousClass(this.method.getDeclaringClass()))?{?MethodAccessorImpl?var3?=?(MethodAccessorImpl)(newMethodAccessorGenerator()).generateMethod(this.method.getDeclaringClass(),?this.method.getName(),?this.method.getParameterTypes(),?this.method.getReturnType(),?this.method.getExceptionTypes(),?this.method.getModifiers());?this.parent.setDelegate(var3);?}
?returninvoke0(this.method,?var1,?var2);}

MethodAccessorGenerator.generateMethod方法片段：

ClassDefiner.defineClass方法：

另外還有RefectionFactory的checkInitted方法會通過 System.getProperty方法拿 sun.reflect.inflationThresholdproperty，默認(rèn)值為15。代碼的流程不是很長，切比較容易理解。接下來就是驗證是不是java反射的Inflat方式引起的。于是寫了下面的例子進行驗證：

/-XX:MetaspaceSize=64M?-XX:MaxMetaspaceSize=64M?-Xms1g?-Xmx1g?-XX:+UseConcMarkSweepGC?-XX:CMSInitiatingOccupancyFraction=75?-XX:+UseCMSInitiatingOccupancyOnly?-XX:+PrintGCTimeStamps-XX:+PrintGCDetails?-Dsun.reflect.inflationThreshold=0/public?static?voidmain(String[]?args)?throwsIOException,?InvocationTargetException,?IllegalAccessException?{?ReflectorFactory?reflectorFactory?=?newDefaultReflectorFactory();?System.out.println("load?class?start");?//?model有1000個方法Reflector?reflector1?=?reflectorFactory.findForClass(TestModel.class);?Reflector?reflector2?=?reflectorFactory.findForClass(TestModel2.class);?Reflector?reflector3?=?reflectorFactory.findForClass(TestModel3.class);
?System.out.println("load?class?finished");
?//?model有1000個方法TestModel?testModel?=?newTestModel();
?Object[]?empty?=?{};?Object[]?one1?=?{"a"};
?TestModel2?testModel2?=?newTestModel2();
?TestModel3?testModel3?=?newTestModel3();
?System.out.println("method?invoke?start");?for(inti?=?0;?i?<?1;?i++)?{?for(intj?=?0;?j?<?1000;?j++)?{?reflector1.getSetInvoker("field"+?j).invoke(testModel,?one1);?reflector1.getGetInvoker("field"+?j).invoke(testModel,?empty);
?reflector2.getSetInvoker("field"+?j).invoke(testModel2,?one1);?reflector2.getGetInvoker("field"+?j).invoke(testModel2,?empty);
?reflector3.getSetInvoker("field"+?j).invoke(testModel3,?one1);?reflector3.getGetInvoker("field"+?j).invoke(testModel3,?empty);?}?}?System.out.println("method?invoke?finished");?System.in.read();}

通過不設(shè)置參數(shù) sun.reflect.inflationThreshold和設(shè)置參數(shù)為0，運行結(jié)果如下：不設(shè)置的情況：

設(shè)置為0的情況：

可以看出兩種設(shè)置下Metaspace內(nèi)存占用相差很大，基本驗證分析的結(jié)果是正確的。最終針對這次因為Metaspace引起頻繁fgc的修復(fù)的方案可以有：

• 增大Metaspace空間

• 犧牲一些性能，應(yīng)用啟動參數(shù)中添加參數(shù) -Dsun.reflect.inflationThreshold，并將其值設(shè)置的足夠大。

讀者福利

加微信：haolagui521備注51CTO領(lǐng)取附送學(xué)習(xí)進階架構(gòu)資料、PDF書籍文檔、面試資料

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

網(wǎng)頁題目：干貨，記一次Metaspace導(dǎo)致頻繁fgc的問題排查過程-創(chuàng)新互聯(lián)
瀏覽地址：http://muchs.cn/article48/deodhp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、動態(tài)網(wǎng)站、虛擬主機、商城網(wǎng)站、外貿(mào)建站、營銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)