三原网站开发,成都建设施工安全协会网站,百度一下百度首页,wordpress模板堂当前位置:我的异常网 编程 java gc 项目终止运行java gc 项目终止运行www.myexceptions.net 网友分享于#xff1a;2013-09-03 浏览#xff1a;6次java gc 项目停止运行首先感谢阿宝同学的帮助#xff0c;我才对这个gc算法的调整有了一定的认识#xff0c;而不是停留在过…当前位置:我的异常网» 编程 » java gc 项目终止运行java gc 项目终止运行www.myexceptions.net 网友分享于2013-09-03 浏览6次java gc 项目停止运行首先感谢阿宝同学的帮助我才对这个gc算法的调整有了一定的认识而不是停留在过去仅仅了解的阶段。在读过sun的文档和跟阿宝讨论之后做个小小的总结如果有谬误敬请指正。CMS全称Concurrent Low Pause Collector是jdk1.4后期版本开始引入的新gc算法在jdk5和jdk6中得到了进一步改进它的主要适合场景是对响应时间的重要性需求大于对吞吐量的要求能够承受垃圾回收线程和应用线程共享处理器资源并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收也就是年老代的回收目标是尽量减少应用的暂停时间减少full gc发生的几率利用和应用程序线程并发的垃圾回收线程来标记清除年老代。在我们的应用中因为有缓存的存在并且对于响应时间也有比较高的要求因此希望能尝试使用CMS来替代默认的server型JVM使用的并行收集器以便获得更短的垃圾回收的暂停时间提高程序的响应性。CMS并非没有暂停而是用两次短暂停来替代串行标记整理算法的长暂停它的收集周期是这样初始标记(CMS-initial-mark) - 并发标记(CMS-concurrent-mark) - 重新标记(CMS-remark) - 并发清除(CMS-concurrent-sweep) -并发重设状态等待下次CMS的触发(CMS-concurrent-reset)。其中的13两个步骤需要暂停所有的应用程序线程的。第一次暂停从root对象开始标记存活的对象这个阶段称为初始标记第二次暂停是在并发标记之后暂停所有应用程序线程重新标记并发标记阶段遗漏的对象(在并发标记阶段结束后对象状态的更新导致)。第一次暂停会比较短第二次暂停通常会比较长并且 remark这个阶段可以并行标记。而并发标记、并发清除、并发重设阶段的所谓并发是指一个或者多个垃圾回收线程和应用程序线程并发地运行垃圾回收线程不会暂停应用程序的执行如果你有多于一个处理器那么并发收集线程将与应用线程在不同的处理器上运行显然这样的开销就是会降低应用的吞吐量。Remark阶段的并行是指暂停了所有应用程序后启动一定数目的垃圾回收进程进行并行标记此时的应用线程是暂停的。CMS的young generation的回收采用的仍然是并行复制收集器这个跟Paralle gc算法是一致的。下面是参数介绍和遇到的问题总结1、启用CMS-XX:UseConcMarkSweepGC。 咳咳这里犯过一个低级错误竟然将号写成了-号2。CMS默认启动的回收线程数目是 (ParallelGCThreads 3)/4) 如果你需要明确设定可以通过-XX:ParallelCMSThreads20来设定,其中ParallelGCThreads是年轻代的并行收集线程数3、CMS是不会整理堆碎片的因此为了防止堆碎片引起full gc通过会开启CMS阶段进行合并碎片选项-XX:UseCMSCompactAtFullCollection开启这个选项一定程度上会影响性能阿宝的blog里说也许可以通过配置适当的CMSFullGCsBeforeCompaction来调整性能未实践。4.为了减少第二次暂停的时间开启并行remark: -XX:CMSParallelRemarkEnabled。如果remark还是过长的话可以开启-XX:CMSScavengeBeforeRemark选项强制remark之前开始一次minor gc减少remark的暂停时间但是在remark之后也将立即开始又一次minor gc。5.为了避免Perm区满引起的full gc建议开启CMS回收Perm区选项CMSPermGenSweepingEnabled -XX:CMSClassUnloadingEnabled6.默认CMS是在tenured generation沾满68%的时候开始进行CMS收集如果你的年老代增长不是那么快并且希望降低CMS次数的话可以适当调高此值-XX:CMSInitiatingOccupancyFraction80这里修改成80%沾满的时候才开始CMS回收。7.年轻代的并行收集线程数默认是(cpu ? cpu : 3 ((cpu * 5) /如果你希望降低这个线程数可以通过-XX:ParallelGCThreads N 来调整。8.进入重点在初步设置了一些参数后例如Java代码-server -Xms1536m -Xmx1536m -XX:NewSize256m -XX:MaxNewSize256m -XX:PermSize64m-XX:MaxPermSize64m -XX:-UseConcMarkSweepGC -XX:UseCMSCompactAtFullCollection-XX:CMSInitiatingOccupancyFraction80 -XX:CMSParallelRemarkEnabled-XX:SoftRefLRUPolicyMSPerMB0-server -Xms1536m -Xmx1536m -XX:NewSize256m -XX:MaxNewSize256m -XX:PermSize64m-XX:MaxPermSize64m -XX:-UseConcMarkSweepGC -XX:UseCMSCompactAtFullCollection-XX:CMSInitiatingOccupancyFraction80 -XX:CMSParallelRemarkEnabled-XX:SoftRefLRUPolicyMSPerMB0需要在生产环境或者压测环境中测量这些参数下系统的表现这时候需要打开GC日志查看具体的信息因此加上参数-verbose:gc -XX:PrintGCTimeStamps -XX:PrintGCDetails -Xloggc:/home/test/logs/gc.log在运行相当长一段时间内查看CMS的表现情况CMS的日志输出类似这样Java代码4391.322: [GC [1 CMS-initial-mark: 655374K(1310720K)] 662197K(1546688K), 0.0303050 secs] [Times: user0.02 sys0.02, real0.03 secs]4391.352: [CMS-concurrent-mark-start]4391.779: [CMS-concurrent-mark: 0.427/0.427 secs] [Times: user1.24 sys0.31, real0.42 secs]4391.779: [CMS-concurrent-preclean-start]4391.821: [CMS-concurrent-preclean: 0.040/0.042 secs] [Times: user0.13 sys0.03, real0.05 secs]4391.821: [CMS-concurrent-abortable-preclean-start]4392.511: [CMS-concurrent-abortable-preclean: 0.349/0.690 secs] [Times: user2.02 sys0.51, real0.69 secs]4392.516: [GC[YG occupancy: 111001 K (235968 K)]4392.516: [Rescan (parallel) , 0.0309960 secs]4392.547: [weak refs processing, 0.0417710 secs] [1 CMS-remark: 655734K(1310720K)] 766736K(1546688K), 0.0932010 secs] [Times: user0.17 sys0.00, real0.09 secs]4392.609: [CMS-concurrent-sweep-start]4394.310: [CMS-concurrent-sweep: 1.595/1.701 secs] [Times: user4.78 sys1.05, real1.70 secs]4394.310: [CMS-concurrent-reset-start]4394.364: [CMS-concurrent-reset: 0.054/0.054 secs] [Times: user0.14 sys0.06, real0.06 secs]4391.322: [GC [1 CMS-initial-mark: 655374K(1310720K)] 662197K(1546688K), 0.0303050 secs] [Times: user0.02 sys0.02, real0.03 secs]4391.352: [CMS-concurrent-mark-start]4391.779: [CMS-concurrent-mark: 0.427/0.427 secs] [Times: user1.24 sys0.31, real0.42 secs]4391.779: [CMS-concurrent-preclean-start]4391.821: [CMS-concurrent-preclean: 0.040/0.042 secs] [Times: user0.13 sys0.03, real0.05 secs]4391.821: [CMS-concurrent-abortable-preclean-start]4392.511: [CMS-concurrent-abortable-preclean: 0.349/0.690 secs] [Times: user2.02 sys0.51, real0.69 secs]4392.516: [GC[YG occupancy: 111001 K (235968 K)]4392.516: [Rescan (parallel) , 0.0309960 secs]4392.547: [weak refs processing, 0.0417710 secs] [1 CMS-remark: 655734K(1310720K)] 766736K(1546688K), 0.0932010 secs] [Times: user0.17 sys0.00, real0.09 secs]4392.609: [CMS-concurrent-sweep-start]4394.310: [CMS-concurrent-sweep: 1.595/1.701 secs] [Times: user4.78 sys1.05, real1.70 secs]4394.310: [CMS-concurrent-reset-start]4394.364: [CMS-concurrent-reset: 0.054/0.054 secs] [Times: user0.14 sys0.06, real0.06 secs]其中可以看到CMS-initial-mark阶段暂停了0.0303050秒而CMS-remark阶段暂停了0.0932010秒因此两次暂停的总共时间是0.123506秒也就是123毫秒左右。两次短暂停的时间之和在200以下可以称为正常现象。但是你很可能遇到两种fail引起full gcPrommotion failed和Concurrent mode failed。Prommotion failed的日志输出大概是这样Java代码[ParNew (promotion failed): 320138K-320138K(353920K), 0.2365970 secs]42576.951: [CMS: 1139969K-1120688K(166784K), 9.2214860 secs] 1458785K-1120688K(2520704K), 9.4584090 secs][ParNew (promotion failed): 320138K-320138K(353920K), 0.2365970 secs]42576.951: [CMS: 1139969K-1120688K(2166784K), 9.2214860 secs] 1458785K-1120688K(2520704K), 9.4584090 secs]这个问题的产生是由于救助空间不够从而向年老代转移对象年老代没有足够的空间来容纳这些对象导致一次full gc的产生。解决这个问题的办法有两种完全相反的倾向增大救助空间、增大年老代或者去掉救助空间。增大救助空间就是调整-XX:SurvivorRatio参数这个参数是Eden区和Survivor区的大小比值默认是32也就是说Eden区是 Survivor区的32倍大小要注意Survivo是有两个区的因此Surivivor其实占整个young genertation的1/34。调小这个参数将增大survivor区让对象尽量在survitor区呆长一点减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代加快年老代的回收频率减少年老代暴涨的可能性这个是通过将-XX:SurvivorRatio 设置成比较大的值(比如65536)来做到。在我们的应用中将young generation设置成256M这个值相对来说比较大了而救助空间设置成默认大小(1/34)从压测情况来看没有出现prommotion failed的现象年轻代比较大从GC日志来看minor gc的时间也在5-20毫秒内还可以接受因此暂不调整。Concurrent mode failed的产生是由于CMS回收年老代的速度太慢导致年老代在CMS完成前就被沾满引起full gc避免这个现象的产生就是调小-XX:CMSInitiatingOccupancyFraction参数的值让CMS更早更频繁的触发降低年老代被沾满的可能。我们的应用暂时负载比较低在生产环境上年老代的增长非常缓慢因此暂时设置此参数为80。在压测环境下这个参数的表现还可以没有出现过Concurrent mode failed。参考资料《JDK5.0垃圾收集优化之--Dont Pause》 by 江南白衣《记一次Java GC调整经历》1,2 by ArbowJava SE 6 HotSpot[tm] Virtual Machine Garbage Collection TuningTuning Garbage Collection with the 5.0 JavaTM Virtual Machine文章评论
