一、背景

系统会偶现下面Metaspace区OOM的情况，服务器在重启后就会立马恢复，而且后面基本不会再复现，可能过了一两个月，又会偶现这个问题：

image.png

二、原因定位

2.1 jvm参数

先看下应用的jvm参数，采用的是默认的配置MaxMetaspaceSize=256m，按照经验来看，这个值偏小，但是理论上是够用的。那继续分析下是什么原因导致偶发性的OOM。

image.png

2.2 监控

切换到单机查看Metaspace区监控，发现在服务启动后，Metaspace区使用量在逐步缓慢的增长。应用仅仅在服务器启动后，Metaspace区内存占用会上涨一截。但不会有后面持续一天的增长呀。看看是哪块代码在捣乱~

image.png

2.3 dump内存

为了分析，分别在FGC前后dump两次，用来作对比分析。

image.png

2.4 分析dump文件

打开zprofile，开始分析，左边是第一次dump的文件，右边是第二次dump的文件。在按类型聚合后的ClassLoaderData这个维度，对比了所有的类加载器，发现DynamicJarClassLoader这个类加载器在FGC前后变化最大，基本确定是这个类无疑了。

image.png

同时在重复类列表，可以清楚的看到同属于fc包下面的类被重复加载了高达一千多次。

image.png

同时在服务器的日志里面也可以发现这些类的身影

image.png

2.5 代码分析

至此，可以猜测是fcbuservice的包会启动一个定时任务不停的加载类导致内存上涨，下面去分析下代码。首先找到DynamicJarClassLoader类，搜下引用

image.png

在截图类里面找到了之前猜想的定时任务，这个线程是60秒执行一次。而且线程里面加载的类名是通过远程接口拉取的，目前在线下拉取的结果应该是空的，所以线下环境没有日志，Metaspace区也不会上涨。

image.png

三、结论

Metaspace频繁加载和FGC，会导致内存碎片越来越多，定时任务不停的加载，肯定会导致内存碎片随着时间增长而变的越来越多，再加上服务器本身的Metaspace区剩余空间不是很大，跑了几个礼拜后，就有可能发生OOM的问题了。为解决这个问题，首先要增加Metaspace空间，可立即解决这个问题。同时需要对应责任人优化这块代码逻辑，不要反复加载，仅发生变化再加载，就更优雅了。