一段死循环引发的Java heap space类型的OutOfMemory

   **************************************事情的经过******************************************

        7月份，公司各部门都开始进行绩效考核，我们一个产品用户需要从系统中导出数据进行绩效考核的依据。系统已经正常运行了一段时间了，这个导出功能一直是正常的。但是用户在导出7月份的数据时，系统直接挂了。

        用户把问题反馈到研发这边，到生产环境导出尝试了下，点击导出按钮后不到1分钟，直接抛出了内存溢出的异常信息。这是一个维护项目，导出没有使用buffer的处理方式来防止大数据导出时的内存溢出。所以看到内存溢出的异常，首先想到的就是是不是7月份的导出数据量太大了？于是到样本库上查询7月份的数量才区区几千条数据，这也能导致内存溢出？虽然有了这个疑问，但还是沿着这个思路去验证了这个导出功能在导出时的内存消耗情况。具体验证的信息如下：

验证工具：jvisualvm

jvm内存配置情况：-Xms512M -Xmx512M

导出数据量：1W条

结果：导出都正常

测试环境下JVM的内存在512M的情况下都能够支撑1W条数据的导出，生产环境下单节点的JVM配置都是

-Xms4096M -Xmx4096M，区区几千条数据怎么会导致内存溢出呢？

        没办法，原本不想看这个维护项目的具体代码的，只能硬着头皮看代码，看能不能从代码层面找出一些错误的端倪。这里要谢谢东硕的提醒看具体的代码中是否有可能存在死循环的语句。朝着这个思路，很快看到一段代码从逻辑上有可能导致死循环：

        只要当needAdd<0的场合，while循环就永远循环了。一旦出现了死循环，serverTypeList对象会不断的被复制，从而导致serverTypeList对象瞬间飙大，进而导致jvm需要进行full gc将年轻代内存移动到年老大内存，但是尽管进行了full gc 但是年轻代内存大小仍然满足不了serverTypeList的大小。这时候就会jvm则会抛出OutOfMemoryError： Java heap space的异常了。

        接下来找DBA帮忙把7月份样本库数据同步到我们测试环境，然后在测试环境中验证我们上面的推测。接下来一共进行了10次导出测试，一共出现了3次内存溢出，其余八次程序并没有出现内存溢出，但是jvm非常频繁的进行full gc。这里基本上已经验证了内存溢出是因为这段代码出现死循环导致的。

        但是这里还是有一个疑问？生产环境下每次导出7月份的数据时很快就会出现内存溢出，但是测试环境下为什么有7次情况下full gc能够非常频繁的进行而程序没有最终报内存溢出异常呢？

        对比生产环境和测试环境jvm配置：

       生产环境: -Xms4096M -Xmx4096M    每次都出现内存溢出

       测试环境1:-Xms1024M -Xmx1024M   两次出现内存溢出 

       测试环境2:-Xms512M -Xmx512M        一次出现内存溢出、7次未出现内存溢出

推测：jvm堆内存越大，full gc更新频率越低，full gc的时间间隔太长导致不能通过频繁的full gc避免内存溢            出。这边欢迎有小伙伴能够给出更好的解释。

*******************************一篇关于Full GC的参考文章*******************************

触发JVM进行Full GC的情况及应对策略

堆内存划分为 Eden、Survivor 和 Tenured/Old 空间，如下图所示：

从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC，对老年代GC称为Major GC,而Full GC是对整个堆来说的，在最近几个版本的JDK里默认包括了对永生带即方法区的回收（JDK8中无永生带了），出现Full GC的时候经常伴随至少一次的Minor GC,但非绝对的。Major GC的速度一般会比Minor GC慢10倍以上。下边看看有那种情况触发JVM进行Full GC及应对策略。

 

1、System.gc()方法的调用

 此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

2、老年代代空间不足

老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误：
java.lang.OutOfMemoryError: Java heap space 
为避免以上两种状况引起的Full GC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

3、永生区空间不足

JVM规范中运行时数据区域中的方法区，在HotSpot虚拟机中又被习惯称为永生代或者永生区，Permanet Generation中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息：
java.lang.OutOfMemoryError: PermGen space 
为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

4、CMS GC时出现promotion failed和concurrent mode failure

对于采用CMS进行老年代GC的程序而言，尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况，当这两种状况出现时可能

会触发Full GC。
promotion failed是在进行Minor GC时，survivor space放不下、对象只能放入老年代，而此时老年代也放不下造成的；concurrent mode failure是在

执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足造成的（有时候“空间不足”是CMS GC时当前的浮动垃圾过多导致暂时性的空间不足触发Full GC）。
对措施为：增大survivor space、老年代空间或调低触发并发GC的比率，但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕

后很久才触发sweeping动作。对于这种状况，可通过设置-XX: CMSMaxAbortablePrecleanTime=5（单位为ms）来避免。

5、统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间

这是一个较为复杂的触发情况，Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象，在进行Minor GC时，做了一个判断，如果之

前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间，那么就直接触发Full GC。
例如程序第一次触发Minor GC后，有6MB的对象晋升到旧生代，那么当下一次Minor GC发生时，首先检查旧生代的剩余空间是否大于6MB，如果小于6MB，

则执行Full GC。
当新生代采用PS GC时，方式稍有不同，PS GC是在Minor GC后也会检查，例如上面的例子中第一次Minor GC后，PS GC会检查此时旧生代的剩余空间是否

大于6MB，如小于，则触发对旧生代的回收。
除了以上4种状况外，对于使用RMI来进行RPC或管理的Sun JDK应用而言，默认情况下会一小时执行一次Full GC。可通过在启动时通过- java -

Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

 

6、堆中分配很大的对象

 所谓大对象，是指需要大量连续内存空间的java对象，例如很长的数组，此种对象会直接进入老年代，而老年代虽然有很大的剩余空间，但是无法找到足够大的连续空间来分配给当前对象，此种情况就会触发JVM进行Full GC。

为了解决这个问题，CMS垃圾收集器提供了一个可配置的参数，即-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程，内存整理的过程无法并发的，空间碎片问题没有了，但提顿时间不得不变长了，JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction,这个参数用于设置在执行多少次不压缩的Full GC后,跟着来一次带压缩的。

转载于：http://blog.csdn.net/chenleixing/article/details/46706039