快捷導(dǎo)航

JVM Metaspace內(nèi)存溢出問題解決方案

更新時(shí)間：2020年11月16日 09:27:38 作者：Java老K

這篇文章主要介紹了JVM Metaspace內(nèi)存溢出排查總結(jié)過程圖解,文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下

一. 現(xiàn)象

前段時(shí)間公司線上環(huán)境的一個(gè)Java應(yīng)用因?yàn)镺OM的異常報(bào)警，導(dǎo)致整個(gè)服務(wù)不可用被拉出集群，本地模擬重現(xiàn)的現(xiàn)象如下:

當(dāng)時(shí)的解決方案是增加metaspace的容量：-XX:MaxMetaspaceSize=500m，從原來默認(rèn)的256m改為500m，雖然沒有再出現(xiàn)oom，但這個(gè)只是臨時(shí)解決方案，通過公司的監(jiān)控系統(tǒng)觀察metaspace的使用情況還是在上升，而且后面隨著業(yè)務(wù)訪問量越來越大還是有可能達(dá)到閾值。

二. 分析

Metaspace元空間主要是存儲(chǔ)類的元數(shù)據(jù)信息，我們的應(yīng)用里加載的各種類描述信息，比如類名、屬性、方法、訪問限制等，按照一定的結(jié)構(gòu)存儲(chǔ)在Metaspace里。

由此可知metaspace空間增長(zhǎng)是由于反射類加載，動(dòng)態(tài)代理生成的類加載等導(dǎo)致的，也就是說Metaspace的大小和加載類的數(shù)據(jù)有關(guān)系，加載的類越多metaspace占用的內(nèi)存也就越大。

因?yàn)榱私猱?dāng)時(shí)的業(yè)務(wù)場(chǎng)景是因?yàn)橛袀€(gè)郵件服務(wù)訪問訂單詳情接口的訪問量突然上升，以及查看log的eroor日志發(fā)現(xiàn)大部分都是訂單詳情接口先報(bào)出的這個(gè)問題:java.lang.OutOfMemoryError: Metaspace

這里我在測(cè)試環(huán)境Java應(yīng)用的jvm里增加-XX:+TraceClassLoading -XX:+TraceClassUnloading記錄下類的加載和卸載情況，然后通過jmeter多個(gè)線程調(diào)用訂單詳情接口模擬metaspace溢出的現(xiàn)象，發(fā)現(xiàn)在catalina.out文件里輸出的除了業(yè)務(wù)上用到的類外還有大量的反射類，如下：

這些反射類被頻繁的加載和卸載是不正常的，通過Arthas診斷工具觀察調(diào)用鏈發(fā)現(xiàn)每次調(diào)用接口都是通過反射的方式實(shí)現(xiàn)的。

目前我們的項(xiàng)目都是基于SOA框架對(duì)外提供訪問的，從上圖sun.reflect的調(diào)用者也能看出來

通過上圖可以看出在調(diào)用底層接口時(shí)都是通過反射的方式獲取類的實(shí)例，查看框架底層代碼實(shí)現(xiàn)可以確認(rèn)

同樣對(duì)底層接口返回的json數(shù)據(jù)反序列化時(shí)也會(huì)用到反射

繼續(xù)跟代碼可以看到這些反射的實(shí)現(xiàn)都會(huì)用到j(luò)ava.lang.Class里的ReflectionData對(duì)象

ReflectionData是個(gè)內(nèi)部靜態(tài)類被緩存起來，里面的屬性就是我們做反射操作時(shí)需要用的屬性Field，方法Method和構(gòu)造函數(shù)等。但是有個(gè)問題reflectionData是被SoftReference軟引用修飾的，如下圖

如果是軟引用的話在內(nèi)存空間不足時(shí)就可能會(huì)被回收掉，如果回收掉那下次再使用的話只能重新通過反射獲取。

而SoftReference是否被回收又跟SoftRefLRUPolicyMSPerMB參數(shù)的值有關(guān)系，查看我們線上JVM的配置發(fā)現(xiàn)XX:SoftRefLRUPolicyMSPerMB這個(gè)參數(shù)設(shè)置的是0

SoftRefLRUPolicyMSPerMB這個(gè)參數(shù)大概意思是每1M空閑空間可保持的SoftReference對(duì)象的生存時(shí)長(zhǎng)(單位是ms毫秒)，LRU是Least Recently Used的縮寫，最近最少使用的。

這個(gè)值jvm默認(rèn)是1000ms，如果被設(shè)置為0，就會(huì)導(dǎo)致軟引用對(duì)象馬上被回收掉，進(jìn)而會(huì)導(dǎo)致重新頻繁的生成新的類，而無法達(dá)到復(fù)用的效果。

上圖里大量的sun.reflect.GeneratedSerializationConstructorAccessor，GeneratedMethodAccessor就是這樣產(chǎn)生的。

我把這個(gè)參數(shù)改回默認(rèn)值-XX:SoftRefLRUPolicyMSPerMB=1000 (1秒)，發(fā)布到生產(chǎn)環(huán)境驗(yàn)證了下，發(fā)布后就降下來了，到今天為止基本上趨于穩(wěn)定

調(diào)整后基本上沒有再出現(xiàn)波動(dòng)

三. 總結(jié)

目前主要是通過修改JVM的-XX:SoftRefLRUPolicyMSPerMB值來解決metaspace上升問題，后續(xù)會(huì)持續(xù)觀察變化，適當(dāng)調(diào)整參數(shù)。至于這個(gè)參數(shù)之前為什么會(huì)被設(shè)置成0, 還需要找ops確認(rèn)下。
我們的應(yīng)用需要大量RPC交互，屬于I/O密集型業(yè)務(wù)，使用SOA，Dubbo都會(huì)遇到類似的問題，通過上面的源碼分析可以看出這個(gè)是無法避免的(除非是換一種序列化協(xié)議，比如hessian，不走方法反射的方式來賦值)包括本身使用的Spring框架很多地方也是通過反射實(shí)現(xiàn)的比如AOP，還有我們埋點(diǎn)經(jīng)常使用的JsonUtils工具，通過dump文件也能看出來存在大量的屬性拷貝和反射操作。

所以我們?cè)谄綍r(shí)的業(yè)務(wù)代碼開發(fā)中如果遇到兩個(gè)對(duì)象賦值的操作盡量少用反射的方式實(shí)現(xiàn)，比如下面的代碼：

這里做的對(duì)象拷貝操作使用的是apache common-beanutils.jar中的BeanUtils，這個(gè)類底層采用javabeans+反射實(shí)現(xiàn)，性能比較差，內(nèi)存開銷比較大，當(dāng)系統(tǒng)高并發(fā)的情況容易導(dǎo)致Metaspace空間增長(zhǎng)過快，不建議這樣使用。

如果字段少的話直接賦值就行了，多的話可以使用Cglib的BeanCopier類，BeanCopier類底層是采用asm字節(jié)碼操作方式來進(jìn)行對(duì)象拷貝操作，性能損耗和內(nèi)存開銷都比較小。

或者使用MapStruct這種幫你生成set、get方法的工具，效果會(huì)更好。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

您可能感興趣的文章: