背景

最近在维护一个项目，转测了，测试同事反馈，有一个功能是生产zip包并提供下载的，但是zip包一直没有生成，然后我就喜提bug了.

我心想，这个功能是提交任务，先返回成功，然后定时任务执行的，应该是出异常了，话不多说，立马连上服务器看日志，幸好结果就只有一条，如下：

cat /app/xxx/log/xxx.log | grep -A 50 'Error'

通过以上的错误信息，可以知道是因为jvm抛出了java.lang.OutOfMemoryError: GC overhead limit exceeded异常，导致执行任务的那个线程挂掉，从而没有生成zip包。

那么问题找到了，如何解决呢？还得从java.lang.OutOfMemoryError: GC overhead limit exceeded开始。就得从Java的GC（再复习一遍Java的垃圾回收）说起。

问题分析

java.lang.OutOfMemoryError: GC overhead limit exceeded 简单来说是因为Java的堆内存因为98%的时间都在进行GC，而只回收不到2%的内存的时候，jvm就会抛出这样一个异常，但应用不会死掉，只是一道警示屏障，如果禁止这个屏障的话，那么应用将耗尽内存，触发java.lang.OutOfMemoryError: Java heap space，也就是常说的内存溢出，这个错误应用是直接挂掉的。由此我们可以得出以下猜测

猜测一：jvm内存分配较小，临时任务量大导致不足以供应用正常的内存分配

为验证此猜想，我加大了jvm堆内存（之前1g，改为2g）

-Xms2g -Xmx2g

可问题依旧，不是这个原因，看来是存在内存泄露。

猜测二：存在内存泄露

为进一步验证此猜想，我将jvm启动参数调整如下：

-Xms1g -Xmx1g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/app/xxx/log

意图应用发生OutOfMemoryError时将内存信息dump下来，以供分析。

问题验证

加大jvm启动参数，重启应用，执行zip包生成，这里先使用jstat命令观测jvm各分区的信息

jstat -gcutil 8555 3000

一边看堆各分区信息，果然又发生了OutOfMemoryError

图中展示的信息我们可以得知：刚开始YGC(young GC)次数逐渐增多，FGC（Full GC）不变，Old区占比逐渐增大；Old去占比达到99%时，FGC次数明显提升，而YGC停止（次数不变），由此基本可以证实Old区的内存无法回收，发生了内存泄露。

问题代码定位

发生了内存泄露如何定位呢，方式比较多，我这里使用了MAT插件进行分析，由以上配置我们可以在/app/xxx/log目录下找到堆转储文件 java_pid8555.hprof，使用STS打开文件,如下：

首先我们看内存泄露报告 Leak Suspects Report

图中说明a、b、c代表的线程正是生成zip包的线程，其中a、b线程分别占用了371M、364M内存，报告中指出a、b、c这三个线程是导致OutOfMemoryError的重大怀疑对象，通过点击Problem Suspect 1 的Details查看该线程的堆栈信息如下：

可以发现LicenseGenertor类有一个List，这个List主要存放对象是LicenseItem对象类，其中这个List占用了385054512B（371M）内存，至此我们找到了占用内存的罪魁祸首（List & LicenseItem ），同理b、c线程所代表的Problem Suspect 2，Problem Suspect 3 Details也一样

结论

通过以上分析，可以得出结论是：LicenseGenertor中对LicenseItem 对象的使用存在内存泄露，需要优化。