触发JVM进行Full GC的情况及应对策略
2016-03-17 11:39
232 查看
堆内存划分为 Eden、Survivor 和 Tenured/Old 空间,例如以下图所看到的:
![](http://img.blog.csdn.net/20150731163641941?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
从年轻代空间(包含 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。
老年代空间仅仅有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象,当运行Full GC后空间仍然不足。则抛出例如以下错误:
java.lang.OutOfMemoryError: Java heap space
为避免以上两种状况引起的Full GC,调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。
假设经过Full GC仍然回收不了。那么JVM会抛出例如以下错误信息:
java.lang.OutOfMemoryError: PermGen space
为避免Perm Gen占满造成Full GC现象。可採用的方法为增大Perm Gen空间或转为使用CMS GC。
对于採用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)来避免。
这是一个较为复杂的触发情况。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。
为了解决问题。CMS垃圾收集器提供了一个可配置的參数,即-XX:+UseCMSCompactAtFullCollection开关參数,用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程,内存整理的过程无法并发的。空间碎片问题没有了,但提顿时间不得不变长了。JVM设计者们还提供了另外一个參数 -XX:CMSFullGCsBeforeCompaction,这个參数用于设置在运行多少次不压缩的Full GC后,跟着来一次带压缩的。
从年轻代空间(包含 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后,跟着来一次带压缩的。
相关文章推荐
- github使用
- 第三周作业(一):安装VS以及创建单元测试
- 微信获取openid过滤黑名单_写入文件_多协程版5500条10几秒
- nginx常用变量
- MyBatis学习 之 五、MyBatis配置文件
- 集合类层次关系
- Redis 学习 ---- 4.字典
- Android USB Host
- iOS通过http post上传图片
- iOS学习之iOS沙盒(sandbox)机制和文件操作(二)
- Hadoop之使用python实现数据集合间join操作
- 标准C++复数运算类详解及使用例程
- svg格式嵌入html中方法之一
- 友盟分享 第三方平台白名单
- 给 IIS Express 配置虚拟目录
- MyBatis学习 之 四、动态SQL语句
- myeclipse自定义java注释
- Notepad++ -- 不打开上次打开的文件
- leetcode:235. Lowest Common Ancestor of a Binary Search Tree
- Bootstrap 徽章、大屏幕展播、页面标题、缩略图