在上一篇博客记录了GC的算法及种类,这篇博客主要记录一下GC的参数如何调整以提高jvm的性能。
一、堆的回顾:
堆的内存空间总体分为新生代和老年代,老年代存放的老年对象,新构造的对象分配在eden区中(栈上分配及新生代内存不足的情况除外)。在经过GC之后,幸存下来的对象会被分配到幸存代中,s0与s1是两块完全相同的内存区域,采用复制算法,在迭代后交换内存空间。经过若干次GC后,仍然未被回收的对象会被分配到老年代中。
二、GC参数--串行收集器(Serial)
串行收集器有以下几个特点:
1)最古老、最稳定
2)效率高
3)可能产生较长时间的停顿,只是用一个线程进行回收,无法发挥多核CPU的优势。(全局停顿在上一篇有介绍过)
通过-XX:+UseSerialGC参数启用,启用之后,新生代和老年代会使用串行回收,新生代会采用复制算法,老年代会使用标记-压缩算法。(参见上一篇博客)
串行回收器的示意图如下:
参数分别记录了新生代和老年代的回收情况。
三、GC参数--并行收集器(PerNew)
PerNew有以下几个特点:
1)是Serial收集器新生代的并行版本
2)采用的是复制算法
3) 是多线程运行的,需要多核CPU的支持。
通过-XX:+UsePerNewGC参数启用,启用之后,新生代采用并行回收,而老年代仍然使用串行回收,采用复制算法。可以通过-XX:ParallelGCThreads参数来限制线程的数量;
通过-XX:MaxGCPauseMills参数控制最大停顿时间,单位是毫秒;GC会尽力保证回收时间不超过设定值;
通过-XX:GCTimeRatio参数控制收集时间占总时间的比,取值范围是0-100;默认是1,即最大允许1%时间用来做GC。
上述两个参数是矛盾的,因为停顿时间和吞吐量不可能同时调优的。GC的次数减少,必然导致单次停顿的时间变长,反之亦然;因此在权衡参数时要抓住性能瓶颈。
并行回收器的示意图如下:
需要注意的一点是,并行收集器只在多核CPU的情况下能提升性能,同时要控制好线程数,否则效率反而打折扣。
四、Paraller收集器
Paraller收集器的特点如下:
1)类似于ParNew收集器
2)新生代采用复制算法,老年代使用标记-压缩算法。
3)更加关注于吞吐量
-XX:UseParallerGC参数:使用Paraller收集器,新生代采用并行收集,老年代采用串行收集;
-XX:UseParallerOldGC参数:使用Paraller收集器,新生代和老年代都采用并行收集。
Paraller收集器示例图:
五、CMS收集器(Concurrent Mask Sweep)
主要的特点如下:
1)采用的是标记-清除算法
2)与标记-压缩算法相比,在并发阶段(与应用程序线程同时执行)会降低吞吐量。
3)老年代的收集器,并不影响新生代收集器,新生代仍然采用ParNew收集器。
通过-XX:UseConcMarkSweepGC参数启用。
CMS运行过程比较复杂,着重实现了标记的过程,可分为:
①初始标记:根对象可以直接关联到对象(速度很快);
②并发标记:同应用程序线程同时进行,标记所有的对象;
③重新标记:由于并发标记时,应用程序线程仍然在运行,因此在正式清理前,需要再次做修正;
④并发清除:基于以上的标记结果,直接清理对象。
注意,在并发标记阶段,同样会产生全局停顿现象,只不过是尽可能的减少了全局停顿的时间,在应用程序运行过程中,会一直产生垃圾,无法进行标记。
CMS收集器示例图如下:
由于在一些标记过程中与应用程序并行,以保证可用对象的地址不发生改变,所以只能简化标记算法而采用标记-清除算法。另外,CMS收集器会影响系统整体的吞吐量,如在用户线程运行的过程中,会占用CPU进行GC操作;同时还存在清理不彻底的情况,在一些标记的过程中,用户的应用程序仍然会产生新的垃圾不会被标记。
注意,因为和用户的应用程序并发,不能在空间快满时才进行清理操作,通过-XX:CMSInitiatingOccupancyFraction参数设置触发GC的阈值,如果内存预留的空间不足,就会引起concurrent mode failure。发生错误的后备方法是,通过串行收集器进行收集,但会产生比较长时间的停顿。
标记-清除算法会产生碎片空间,因此我们需要进行碎片整理:
通过-XX:UseCMSCompactAtFullCollection参数使在进行FullGC之后进行一次整理,这个整理过程是独占的,会引起停顿时间变长;
通过-XX:CMSFullGCsBeforeCompaction参数设置进行几次FullGC之后进行一次碎片整理;
通过-XX:ParallelCMSThreads设定CMS的线程数量。
六、GC参数整理:
-XX:+UseSerialGC:在新生代和老年代使用串行收集器;
-XX:SurvivorRatio:设置eden区大小和survivor区大小的比例;
-XX:NewRatio:设置新生代和老年代的大小比例;
-XX:+UseParNewGC:在新生代使用并行收集器;
-XX:+UseParellelGC:新生代使用并行回收收集器;
-XX:+UseParallelOldGC:老年代使用并行回收收集器;
-XX:ParallelGCThreads:设置用于垃圾回收的线程数;
-XX:+UseConcMarkSweepGC:新生代使用并行收集器,老年代使用CMS+串行收集器;
-XX:ParallelCMSThreads:设定CMS的线程数量;
-XX:CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后被触发;
-XX:+UseCMSCompactAtFullCollection:设置CMS收集器在完成垃圾收集后是否要进行一次内存的碎片整理;
-XX:CMSFullGCsBeforeCompaction:设定进行多少次CMS垃圾回收之后进行一次内存压缩;
-XX:+CMSClassUnloadingEnabled:允许对类元数据进行回收;
-XX:CMSInitiatingPermOccupancyFraction:当永久区占用率达到这一百分比时,启用CMS回收;
-XX:UseCMSInitiatingOccupancyOnly:只有到达阈值的时候才进行CMS回收。
七、GC参数实例:
环境:Tomcat7、JSP网站、JDK6、测试网站的吞吐量及延时。
工具:Jmeter,建立10个线程,每个线程请求Tomcat 1000次 共1w次。
目的:让Tomcat有一个不错的吞吐量。
结构:Tomcat与Jmeter分开部署,防止Jmeter对Tomcat的性能产生影响。
1、参数:set CATALINA_OPTS=-server -Xloggc:gc.log -XX:+PrintGCDetails -Xms32M -Xmx32M -XX:+HeapDumpOnOutOfMemeryError -XX:+UseSerialGC -XX:PermSize=32M
2、参数:set CATALINA_OPTS=-Xmx512M -XX:MaxPermSize=32M -Xloggc:gc.log -XX:PrintGCDetails
将最大堆内存改为512m,结果FullGC发生很少,基本上都是MinorGC。吞吐量由540提高到了650,同时堆大小也在自动拓展,由开始的15872K拓展到38秒的60456K。
3、参数:set CATALINA_OPTS=-Xmx512M -Xms=64M -XX:MaxPermSize=32M -Xloggc:gc.log -XX:PrintGCDetails
将堆内存的初始大小设置为64M,GC数量减少,大部分都是MinorGC.吞吐量由651提升到了674。
4、参数:set CATALINA_OPTS=-Xmx512M -Xms=64M -XX:MaxPermSize=32M -Xloggc:gc.log -XX:PrintGCDetails -XX:+UseParallelGC -XX:+UseParallelOldGC
-XX:ParallelGCThreads
新生代和老年代都使用并行回收收集器,GC原本压力不大,所以影响很小。
5、参数:set CATALINA_OPTS=-Xmx40M -Xms40M -XX:MaxPermSize=32M -Xloggc:gc.log -XX:PrintGCDetails
减少堆大小,增加GC压力,默认使用串行回收收集器,吞吐量为646。
6、参数:set CATALINA_OPTS=-Xmx40M -Xms40M -XX:MaxPermSize=32M -Xloggc:gc.log -XX:PrintGCDetails -XX:+UseParallelOldGC -XX:ParallelGCThreads
减少堆大小,增加GC压力,老年代使用并行回收收集器,吞吐量由646提高到了685。
7、参数:set CATALINA_OPTS=-Xmx40M -Xms40M -XX:MaxPermSize=32M -Xloggc:gc.log -XX:PrintGCDetails -XX:+UseParNewGC
减少堆大小,增加GC压力,新生代使用并行回收收集器,吞吐量由685下降到了660。可见老年代的GC回收机制对系统性能影响更大一些。
8、不添加任何参数,使用JDK6与JDK7对比
发现JDK版本对于系统性能影响不容忽视。升级JDK版本可能会带来额外的性能提升!