常见JVM问题

1.java.lang.OutOfMemoryError：GC overhead limit exceeded

1). 问题详情

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded

2). 问题分析

GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略，通过统计GC时间来预测是否要OOM了，提前抛出异常，防止OOM发生。

Sun 官方对此的定义是："并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError, 过长的定义是超过98%的时间用来做GC并且回收了不到2%的堆内存(if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown.), 用来避免内存过小造成应用不能正常工作。"

听起来没啥用...预测OOM有啥用？起初开这玩意只能用来Catch住释放内存资源，避免应用挂掉。后来发现一般情况下这个策略不能拯救你的应用，但是可以在应用挂掉之前做最后的挣扎，比如数据保存或者保存现场（Heap Dump）。

而且有些时候这个策略还会带来问题，比如加载某个大的内存数据时频繁OOM。

假如你也生产环境中遇到了这个问题，在不知道原因时不要简单的猜测和规避。可以通过-verbose:gc -XX:+PrintGCDetails看下到底什么原因造成了异常。通常原因都是因为old区占用过多导致频繁Full GC，最终导致GC overhead limit exceed。如果gc log不够可以借助于JProfile等工具查看内存的占用，old区是否有内存泄露。分析内存泄露还有一个方法-XX:+HeapDumpOnOutOfMemoryError，这样OOM时会自动做Heap Dump，可以拿MAT来排查了。还要留意young区，如果有过多短暂对象分配，可能也会抛这个异常.

3). 解决方案

1、查看系统是否有使用大内存的代码或死循环。

2、可以添加JVM的启动参数来限制使用内存：-XX:-UseGCOverheadLimit

2.CMS GC时出现Concurrent Mode Failure？

1)问题详情

90003.167: [GC 90003.167: [ParNew: 261760K->0K(261952K), 0.0204310secs] 778897K->520196K(1310528K), 0.0207190 secs]

90006.049: [GC 90006.050: [ParNew: 261760K->0K(261952K), 0.0136380 secs]781956K->521446K(1310528K), 0.0138720 secs]

90010.628: [GC 90010.628: [ParNew: 261760K->261760K(261952K), 0.0000350secs]90010.628: [CMS (concurrent mode failure)[Unloadingclass sun.reflect.GeneratedSerializationConstructorAccessor1818]

[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor1816]

2)问题分析

并发收集器（concurrentcollector）指的是回收年老代和持久代时，采用多个线程和应用线程并发执行，减少应用停顿时间，但如果参数设置不当，容易出现Concurrent ModeFailure现象，此时JVM将会启用Serial Old收集器作为备用的垃圾收集进行full gc，整个gc时间相当可观，完全违背了采用CMS GC的初衷。

 出现此现象的原因主要有两个：一个是在老年代被用完之前不能完成对无引用对象的回收；一个是当新空间分配请求在老年代的剩余空间中得到满足。

（if theconcurrent collector is unable to finish reclaiming the unreachable objectsbefore the tenured generation fills up, or if an allocation cannot be satisfiedwith the available free space blocks in the tenured generation, then theapplication is paused and the collection is completed with all the applicationthreads stopped）

当时的JVM参数如下：

-server -Xms1280m -Xmx1280m -Xmn256m -Xss256k -XX:PermSize=128m-XX:MaxPermSize=128m-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:CMSFullGCsBeforeCompaction=5-XX:+UseCMSCompactAtFullCollection  -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled-XX:+DisableExplicitGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

3)解决方案

因为配置了+CMSClassUnloadingEnabled参数，所以出现Unloading classsun.reflect.GeneratedSerializationConstructorAccessor的日志，这是个好习惯，如果空间不够时可以卸载类来释放空间，以进行FULL GC，相反，如果gc日志中出现了此日志，应该检查各代的大小设置是否合理。

这里应用从启动到上述现象出现时还没有进行过CMS GC，出现concurrent modefailure现象的原因是年轻代GC（ParNew），年老代所剩下的空间不足以满足年轻代，也就是开头提到的原因二。要避免此现象，方法一是降低触发CMS的阀值，即参数-XX:CMSInitiatingOccupancyFraction的值，默认值是68，所以这里调低到50，让CMS GC尽早执行，以保证有足够的空间，如下：

-server -Xms1280m -Xmx1280m -Xmn256m -Xss256k -XX:PermSize=128m-XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC-XX:CMSFullGCsBeforeCompaction=1 -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50-XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -verbose:gc-XX:+PrintGCDetails -XX:+PrintGCTimeStamps

调完之后发现还是一样的现象（这里有点不是很明白，年老代空间为1024m（1280m-256m），50%时触发CMS GC，也就是在年老代512m的时候，剩下的堆空间有512m，就算年轻代全部装进去应该也是够的）,所以怀疑是年轻代太大，有大的对象，在年老代有碎片的情况下将很难分配，所以有了第二个解决办法，即减少年轻代大小，避免放入年老代时需要分配大的空间，同时调整full gc时压缩碎片的频次，减少持久代大小，以及将触发CMS GC的阀值适当增大（因为年轻代小了，这个调大点没关系，后面可以再调试这个参数），参数如下：

-server -Xms1280m -Xmx1280m -Xmn128m -Xss256k -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSFullGCsBeforeCompaction=1 -XX:+UseCMSCompactAtFullCollection -XX:+CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

调整完后没有那个现象了，这里主要起作用的就是调小年轻代大小。在年老代到达826m(触发CMS阀值(1280-128)*0.7=806m)时出现了CMS GC，用时27ms.

最后总结下，出现Concurrent ModeFailure现象时，解决办法就是要让年老代留有足够的空间，以保证新对象空间的分配。

GC时还有一个常见的错误Promotion Failed，解决办法类似，也是调整年轻代和年老代的比例，还有CMS GC的时机。

4）延伸

为了防止出现Promotion Failed和concurrent mode failure现象， -XX:CMSInitiatingOccupancyFraction的值设置要满足以下关系：

遇到一种情况：promontion faild产生的原因是Eden空间不足的情况下将Eden与From survivor中的存活对象存入To survivor区时, To survivor区的空间不足，再次晋升到old gen区，而old gen区内存也不够的情况下产生了promontion faild从而导致full gc.

那可以推断出：eden+from survivor < old gen区剩余内存时，不会出现promontion faild的情况，即：

(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2))  进而推断出：

CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

例如：

当xmx=3000 xmn=600 SurvivorRatior=1时  CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33

CMSInitiatingOccupancyFraction低于70% 需要调整xmn或SurvivorRatior值。