基于上一次产线OOM问题排查结果,发现这块的锻炼机会变多了,隔壁组出了个OOM的问题,让帮着一起查问题.
相关日志如下:
Exception in thread "prometheus-http-1-25" Exception in thread "prometheus-http-1-29" Exception in thread "http-nio-8080-exec-7" java.lang.OutOfMemoryError: Metaspace
Exception in thread "prometheus-http-1-26" java.lang.OutOfMemoryError: Metaspace
java.lang.OutOfMemoryError: Metaspace
java.lang.OutOfMemoryError: Metaspace
dump路径:阿里云盘/IT/产线问题积累/OOM/metaspace_oom_groovy_dynamicLoadClass.hprof
相关的JVM参数也要来了,如下:
打开dump文件,先来看看Leak Suspects视图
大致推测跟map相关的内存泄露,点进Details没啥头绪.
MetaSpace 主要由 Klass Metaspace 和 NoKlass Metaspace 两大部分组成.粗略理解就是类的定义信息之类的数据,一般工作中常见MetaSpace OOM大部分情况下都是动态加载类没控制好,导致Classloader不断加载新的类,最终达到MetaSpaceSize设定的最大值,从而OOM.
看下Duplicate Classes视图,这个视图主要是列出重复的类.
点开看到公司包名及count列的个数那一瞬间我基本断定是这块出了问题.由于不熟悉这块业务逻辑,跟同事问了下是否工程中用到了Groovy 动态加载类,嗯...再跟着包路径去翻相关的代码,定位到是相关脚本的缓存实现没控制好,导致在某些场景下会这个缓存会失效,不停动态加载新class放入缓存.哎,这块业务后面得找同事详细了解一下,拓宽一下知识面,嘻嘻.
总结一下,当遇到metaspace OOM的时,经常会出问题的几个点有 Orika 的 classMap、JSON 的 ASMSerializer、Groovy 动态加载类等，基本都集中在反射、Javasisit 字节码增强、CGLIB 动态代理、OSGi 自定义类加载器等的技术点上.
