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

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

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

一. 現(xiàn)象

前段時間公司線上環(huán)境的一個Java應用因為OOM的異常報警，導致整個服務不可用被拉出集群，本地模擬重現(xiàn)的現(xiàn)象如下:

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

二. 分析

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

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

因為了解當時的業(yè)務場景是因為有個郵件服務訪問訂單詳情接口的訪問量突然上升，以及查看log的eroor日志發(fā)現(xiàn)大部分都是訂單詳情接口先報出的這個問題:java.lang.OutOfMemoryError: Metaspace

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

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

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

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

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

繼續(xù)跟代碼可以看到這些反射的實現(xiàn)都會用到java.lang.Class里的ReflectionData對象

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

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

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

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

這個值jvm默認是1000ms，如果被設置為0，就會導致軟引用對象馬上被回收掉，進而會導致重新頻繁的生成新的類，而無法達到復用的效果。

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

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

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

三. 總結

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

所以我們在平時的業(yè)務代碼開發(fā)中如果遇到兩個對象賦值的操作盡量少用反射的方式實現(xiàn)，比如下面的代碼：