JVM Metaspace內存溢出問題解決方案

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

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

一. 現(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ù)據信息，我們的應用里加載的各種類描述信息，比如類名、屬性、方法、訪問限制等，按照一定的結構存儲在Metaspace里。

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

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

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

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

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

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

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

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

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

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

而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就是這樣產生的。

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

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

三. 總結

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

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