深入JVM内核(五)

JAVA 2015-12-10

下面我们继续对GC原理进行探究

1.串行收集器 1.png 是GC最最古老,最稳定的收集器,特点是效率高,但可能会产生较长的停顿 使用参数是-XX:+UseSerialGC(新生代、老年代使用串行回收;新生代复制算法;老年代标记-压缩算法)。

2.并行收集器 2.png a.一种是Serial收集器新生代的并行版本,使用复制算法,是多线程,需要多核支持,可以使用参数:-XX:ParallelGCThreads 限制线程数量。 使用参数:-XX:+UseParNewGC(新生代并行;老年代串行) 3.png b.还有一种是Parallel收集器,它类似ParNew,新生使用代复制算法,老年代使用标记-压缩,但是更加关注吞吐量 使用参数:-XX:+UseParallelGC (使用Parallel收集器+ 老年代串行) -XX:+UseParallelOldGC(使用Parallel收集器+ 并行老年代) 相关参数:-XX:MaxGCPauseMills(最大停顿时间,单位毫秒;GC尽力保证回收时 间不超过设定值)-XX:GCTimeRatio(0-100的取值范围;垃圾收集时间占总时间的比;默认99,即最大允许1%时间做GC)注意:这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优!

3.CMS收集器 4.png Concurrent Mark Sweep 并发标记清除,与用户线程一起执行,采用标记-清除算法,与标记-压缩相比,并发阶段会降低吞吐量,老年代收集器(新生代使用ParNew) 使用参数:-XX:+UseConcMarkSweepGC CMS运行过程比较复杂,着重实现了标记的过程,可分为 a.初始标记(根可以直接关联到的对象;速度快) b.并发标记(和用户线程一起),主要标记过程,标记全部对象c.重新标记,由于并发标记时,用户线程依然运行,因此在正式清理前,再做修正 d.并发清除(和用户线程一起),基于标记结果,直接清理对象。 特点:尽可能降低停顿,会影响系统整体吞吐量和性能,比如,在用户线程运行过程中,分一半CPU去做GC,系统性能在GC阶段,反应速度就下降一半,并且清理不彻底,因为在清理阶段,用户线程还在运行,会产生新的垃圾,无法清理,因为和用户线程一起运行,不能在空间快满时再清理,如使用-XX:CMSInitiatingOccupancyFraction设置触发GC的阈值,如果不幸内存预留空间不够,就会引起concurrent mode failure。 4.碎片整理 标记-清除后留下 使用-XX:+ UseCMSCompactAtFullCollection Full GC后,进行一次整理,因为整理过程是独占的,会引起停顿时间变长。若使XX:+CMSFullGCsBeforeCompaction 设置进行几次Full GC后,进行一次碎片整理。也可以使用-XX:ParallelCMSThreads设定CMS的线程数量。 相关参数: -XX:+UseSerialGC:在新生代和老年代使用串行收集器 -XX:SurvivorRatio:设置eden区大小和survivior区大小的比例 -XX:NewRatio:新生代和老年代的比 -XX:+UseParNewGC:在新生代使用并行收集器 -XX:+UseParallelGC :新生代使用并行回收收集器 -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回收 下面给出一个实例,对Tomcat7进行调优 这里使用的工具是JMeter(Meter是Apache组织开发的基于Java的压力测试工具,下载地址下载JMeter)我这里用的是2.13版本,JDK8,具体使用请参考我的另一篇文章。 我们建立10个线程,每个线程请求Tomcat 1000次 共10000次请求 分别用不同的方法进行性能测试: 首先使用32M堆处理请求, 参数:set CATALINA_OPTS=-server -Xloggc:gc.log - XX:+PrintGCDetails -Xmx32M -Xms32M -XX:+HeapDumpOnOutOfMemoryError -XX:+UseSerialGC -XX:PermSize=32M 然后用使用最大堆512M堆处理请求 参数:set CATALINA_OPTS=-Xmx512m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails 结果:FULL GC很少,基本上是Minor GC 参数:set CATALINA_OPTS=-Xmx512m -Xms64m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails 结果 GC数量减少 大部分是Minor GC 进一步测试,同样适用最大512M,参数:set CATALINA_OPTS=-Xmx512m -Xms64m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:ParallelGCThreads=4 结果:GC压力原本不大,修改GC方式影响很小 若减小堆: 参数:set CATALINA_OPTS=-Xmx40m -Xms40m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails 减小堆大小,增加GC压力,使用Serial回收器 参数:set CATALINA_OPTS=-Xmx40m -Xms40m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails -XX:+UseParallelOldGC -XX:ParallelGCThreads=4 减小堆大小,增加GC压力,使用并行回收器 参数:set CATALINA_OPTS=-Xmx40m -Xms40m -XX:MaxPermSize=32M -Xloggc:gc.log -XX:+PrintGCDetails -XX:+UseParNewGC 减小堆大小,增加GC压力,使用ParNew回收器 可见不同的方式对Tomcat的吞吐量是有影响的。


本文由 Tony 创作,采用 知识共享署名 3.0,可自由转载、引用,但需署名作者且注明文章出处。

如果对您有用,您的支持将鼓励我继续创作!