最近线上一个特别重要的服务频繁出现问题，因为该服务要为多个项目提供基础底层数据，要求该服务每个季度停服不能超过一次，但是因为内存溢出一个月挂了两次。。。。于是不得不抽出时间进入底层探究。
问题复现：
1.该机器内存为32G，通过监控大盘发现，jvm的metaspace内存不断升高，持续升高将机器内存打爆导致服务挂掉。
2.收到报警重启系统，为避免metaspace野蛮占用，在启动参数里面添加了两个参数-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=1g，限制metaspace最高只能占用1G内存。
3.突然有一天下午，同事跟我反馈说系统打不开了，我还疑惑是不是断网了，因为我没有收到服务告警及进程监控告警。进入服务器查看日志 java.lang.OutOfMemoryError: Metaspace........metaspace在用尽1G内存之后，无法再申请内存，直接OOM。就很离谱，full gc呢，一点都不回收吗？
从java1.8开始metaspace（元数据空间）替代持久代，metaspace位于堆外，也就是说机器内存的上限决定metasapce内存的上限，metaspace存放的都是创建的类信息，常量池，注解，方法计数器等等。如果这个区域被打爆，大概率就是创建了大量的类且没有被回收，这里要么代码写的有bug要么就是引入的第三方的一些工具包不讲究。这里我们立刻怀疑到阿里巴巴的fastjson，这货有前科而且特别多，fastjson除了性能好以外bug极多，出过安全问题，反射创建大量的类将metasapce打爆，反正就是让人又爱又恨。所以我们全面排查代码，将用到fastjson的地方全部替换一个不留。再次上线之后，大概过了有半个多月吧，在一个阳光明媚的下午，又挂了。。。。。翻开日志又是metasapace OOM。
此次决心找出问题的究竟，因为是metaspce内存溢出大概率是疯狂创建了大量的类且没有被回收，所以我们可以看下jvm内存中到底创建了哪些类且没有被回收，于是dump内存
jmap -dump:live,format=b,file=m.hprof 18071
请注意，这个动作在生产环境下一定要谨慎，因为它会触发一次full gc
内存dump下来之后，打开mat工具分析了一波。
在我们的代码中确实使用了groovy，但是只是用于获取时间参数并没有频繁使用，却创建了8万多个，显然是没有回收，于是查看gc日志
35406.969: [Full GC (Ergonomics) [PSYoungGen: 452036K->0K(4116480K)] [ParOldGen: 8378221K->706275K(8388608K)] 8373957K->706275K(12505088K), [Metaspace: 155472K->155472K(1185792K)], 1.3947156 secs] [Times: user=3.73 sys=0.21, real=1.39 secs]
[Metaspace: 155472K->155472K(1185792K)]
果然full gc的时候回收了个寂寞，metaspce区域根本就没有回收，所以导致了大量的groovy大量堆积，那么问题来了，为啥groovy就没有被回收呢?
在官网上终于找到了答案，这是groovy本身的一个bug，bug编号GROOVY-7913，在2.4.6版本中发现，在2.4.8版本中修复
看了下我们代码中引用的版本【2.4.7】！！！！
好了问题算是明了了，替换版本为【2.4.8】即可
当然还有一个方案就是在启动参数中添加
-Dgroovy.use.classvalue=true
重启之后持续观察gc日志，终于在一个full gc之后看到metaspace区域进行回收了
54006.969: [Full GC (Ergonomics) [PSYoungGen: 45236K->0K(4116480K)] [ParOldGen: 8328721K->706275K(8388608K)] 8373957K->706275K(12505088K), [Metaspace: 155472K->111204K(1185792K)], 1.3156947 secs] [Times: user=5.63 sys=0.25, real=1.19 secs]
[Metaspace: 167371K->111204K(1185792K)]
建议再出现内存溢出的问题，直接dump内存上mat分析，更高效更直观
网友评论