标签:用途 fancybox detail 第一个 收集 cloud class 也有 出现
JVM里面的Throughtput收集器是一款关注吞吐量的垃圾收集器。该收集器是唯一一个实现了UseAdaptiveSizePolicy策略的收集器,允许用户通过指定最大暂停时间和垃圾收集时间占总时间的百分比,然后自适应调整JVM的参数来达到配置的目标。
先上一张经典的垃圾收集器的图:
这张图相信很多人都看过,展示了各个垃圾收集器之间的搭配。平时我们说的Throughtput收集器就是图中红线框起来的几个收集器。下面会分别来介绍一些这几个收集器的特点和作用。
ParallelScavenge收集器收集的是新生代,使用的是Scavenge GC(Copying GC的另外一种叫法)。该收集器是并行的,可以同时多个线程一起执行copying阶段,在多处理器的场景下可以尽最大可能的提高minor gc的效率。ParallelScavenge收集器的目的是达到一个可控制的吞吐量,吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集的时间),虚拟机总共运行100分钟,其中垃圾收集器运行了1分钟,那么吞吐量就是99%。
关于ParallelScavenge收集器有个有趣的来历。HotSpot VM的开发者在开发垃圾收集器的时候都是在分代式框架中开发,并且希望第三方的开发者也是在这个框架中开发自定义的收集器,这样可以和其他收集器很好的配合在一起使用。后来有个开发者不想使用这个框架,于是靠一己之力实现了没有用框架的并行GC,并且这个并行GC的性能还是相当不错的,于是这个并行的GC就被放到了HotSpot VM里,这就是我们看到的ParallelScavenge收集器。这也是为什么这个收集器没法跟CMS配合使用,因为他们根本就不在一个框架内。
在使用ParallelScavenge收集器的时候,需要关于关注以下两个配置参数:
1、MaxGCPauseMills,这个参数控制允许GC最长的暂停时间,参数允许的值是一个大于0的毫秒数。设置该参数之后,VM会通过控制新生代的大小来达到暂停时间长短的控制的。不要认为把这个参数设置的越小越好,参数越小意味着新生代的空间越小,导致新生代执行垃圾收集的次数增加。举个例子,原来10秒钟执行一次minor gc,每次暂停100毫秒,现在把允许的暂停时间调低成80毫秒,可能导致每5秒钟就会执行一次minor gc,停顿时间降低了,但是吞吐量也下降了。
2、GCTimeRatio,垃圾收集时间占总时间的比率。该参数的值应该是一个大于0小于100的整数。如果把此参数设置为19,那允许的最大GC时间就占总时间的5% (即1 /(1 + 19)),默认值为99,就是允许最大1% (即1 /(1+99))的垃圾收集时间。
通过调整这两个参数就可以实现对吞吐量和暂停时间的控制,用户不用去关心新生代该设置多少,老年代该设置多少,只需要设置好这两个值,剩下的就交给虚拟机吧,它会帮你调整好对应的大小。新生代可以通过这种方式实现,那么老年代是否也有类似的方式来实现呢,答案是有的,就是图中的Parralled Old。
Parralled Old收集器是ParallelScavenge的老年代版本。使用的算法是Mark-Compact。Parralled Old收集器是在JDK1.6之后才出现的,在此之前如果新生代选择使用ParallelScavenge,那么老年代只能选择使用Serial Old,也就是说只能使用单线程收集,为了弥补这个不足,于是开发了Parallel Old收集器。有了Parallel Old收集器之后,Throughtput收集器才真正显示出它的强大之处,在吞吐量和CPU敏感的情况下,都可以考虑使用Parallel Scavenge+Parallel Old的组合。
Paralled Old收集器的运行示意图如下:
Serial Old收集器是一款传统的单线程垃圾收集器,使用Mark-Sweep-Compact算法。这个收集器主要是在Client模式下使用。该收集器的用途有两个:一个是在JDK1.5之前与ParallelScavenge收集器配合使用;第二个用途是作为CMS收集器的后备预案,在CMS发生并发模式失效的时候使用Serial Old收集器进行一次完整的STW的垃圾回收。
Serial Old收集器的运行示意图如下:
在JDK1.8下,使用Throughtput收集器有两种配置:
1、-XX:+UseParallelGC或者-XX:+UseParallelOldGC,这两个配置下任选一个使用的收集器都是ParallelScavenge+Parralled Old。这与网上大多数说介绍是不一样的,网上大多数介绍是说UseParallelGC配置下使用的是ParallelScavenge+Serial Old,JDK1.8下已经进行了统一,Serial Old已经不再是默认的选择。
2、如果想使用Serial Old作为老年代的垃圾收集器可以这样配置:-XX:+UseParallelGC -XX:-UseParallelOldGC。
-XX:+UseParallelGC或者-XX:+UseParallelOldGC参数下的日志:
-XX:+UseParallelGC -XX:-UseParallelOldGC参数下的日志:
我使用了System.gc()分别在两种配置下触发GC,通过对比可以发现只有在老年代的收集下是不一样的,第一个用的是ParOldGen,对应的是Parralled Old收集器;第二个用的是PSOldGen,对应的是Serial Old收集器。新生代收集日志PSYoungGen对应的就是Parallel Scavenge收集器。
在使用Throughtput收集器的时候强烈不建议手动指定新生代大小和老年代大小,因为这将废弃虚拟机的自适应调整策略。也就意味着你配置的MaxGCPauseMills和GCTimeRatio参数很难真正起作用。用户只需要指定最大最小堆内存,以及MaxGCPauseMills和GCTimeRatio参数即可,剩下的交给VM去处理吧,它会帮你调整到最佳状态,这也是非常人性化的。VM具体的调整包含调整新生代和老年代的大小,以及调整新生代晋升到老年代的年龄等。
以上设置的参数,MaxGCPauseMills优先级最高,如果设置了这个值,新生代和老年代会随之进行调整,直到满足对应的停顿时间的目标。一旦这个目标达成,堆的总容量开始增大,直到运行时间达到比率GCTimeRatio设定值。这两个目标达成后,JVM尝试缩小堆大小,尽可能以最小堆来满足这两个目标。
ParNew也是一个新生代的并行GC,ParNew的存在主要是为了配合CMS使用,如果没有ParNew,CMS只能搭配单线程垃圾回收。ParNew与Parallel Scavenge对比有以下几种不同:
1、ParNew使用的是广度优先来遍历对象图,Parallel Scavenge使用的是深度优先来遍历对象图
2、ParNew没有实现UseAdaptiveSizePolicy策略,而Parallel Scavenge实现了这个策略
3、ParNew可以和CMS搭配使用,而Parallel Scavenge不能与CMS搭配使用
通过-XX:ParallelGCThreads=X来设置并行GC的线程数量,默认情况下跟处理器个数一致。
1、Throughtput收集器有两种参数,Minor GC和Full GC
2、通过Throughtput收集器的动态调整策略是垃圾回收调优的很好切入点,能有效的减少JVM内存使用
3、当需要追求吞吐量的时候,Throughtput总是一个不错的选择
标签:用途 fancybox detail 第一个 收集 cloud class 也有 出现
原文地址:https://www.cnblogs.com/yunxitalk/p/8974485.html