JVM吞吐量垃圾收集器

注：本文摘抄自周志明老师的《深入理解Java虚拟机》片段，在此表示感谢。

Parallel Scavenge收集器也是一款新生代收集器， 它同样是基于标记-复制算法实现的收集器， 也是
能够并行收集的多线程收集器……Parallel Scavenge的诸多特性从表面上看和ParNew非常相似， 那它有什么特别之处呢？

Parallel Scavenge收集器的特点是它的关注点与其他收集器不同， CMS等收集器的关注点是尽可能
地缩短垃圾收集时用户线程的停顿时间， 而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput） 。 所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值，即：

如果虚拟机完成某个任务， 用户代码加上垃圾收集总共耗费了100分钟， 其中垃圾收集花掉1分
钟， 那吞吐量就是99%。 停顿时间越短就越适合需要与用户交互或需要保证服务响应质量的程序， 良好的响应速度能提升用户体验； 而高吞吐量则可以最高效率地利用处理器资源， 尽快完成程序的运算任务， 主要适合在后台运算而不需要太多交互的分析任务。

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量， 分别是控制最大垃圾收集停顿时间
的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。

-XX:MaxGCPauseMillis参数允许的值是一个大于0的毫秒数， 收集器将尽力保证内存回收花费的
时间不超过用户设定值。 不过大家不要异想天开地认为如果把这个参数的值设置得更小一点就能使得
系统的垃圾收集速度变得更快， 垃圾收集停顿时间缩短是以牺牲吞吐量和新生代空间为代价换取的：
系统把新生代调得小一些， 收集300MB新生代肯定比收集500MB快， 但这也直接导致垃圾收集发生得更频繁， 原来10秒收集一次、 每次停顿100毫秒， 现在变成5秒收集一次、 每次停顿70毫秒。 停顿时间的确在下降， 但吞吐量也降下来了。

-XX:GCTimeRatio参数的值则应当是一个大于0小于100的整数， 也就是垃圾收集时间占总时间的比率， 相当于吞吐量的倒数。 譬如把此参数设置为19， 那允许的最大垃圾收集时间就占总时间的5%（即1/(1+19)）,默认值为99， 即允许最大1%（即1/(1+99)） 的垃圾收集时间。

由于与吞吐量关系密切， Parallel Scavenge收集器也经常被称作“吞吐量优先收集器”。

除上述两个参数之外， Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得我们关注。 这是一个开关参数， 当这个参数被激活之后， 就不需要人工指定新生代的大小（-Xmn） Eden与Survivor区的比例（-XX:SurvivorRatio） 、 晋升老年代对象大小（-XX:PretenureSizeThreshold） 等细节参数了， 虚拟机会根据当前系统的运行情况收集性能监控信息， 动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。 这种调节方式称为垃圾收集的自适应的调节策略（GC Ergonomics） [1]。 如果读者对于收集器运作不太了解， 手工优化存在困难的话， 使用Parallel Scavenge收集器配合自适应调节策略， 把内存管理的调优任务交给虚拟机去完成也许是一个很不错的选择。 只需要把基本的内存数据设置好（如-Xmx设置最大堆） ， 然后使用-XX： MaxGCPauseMillis参数（更关注最大停顿时间） 或-XX:GCTimeRatio（更关注吞吐量） 参数给虚拟机设立一个优化目标， 那具体细节参数的调节工作就由虚拟机完成了。 自适应调节策略也是Parallel Scavenge收集器区别于ParNew收集器的一个重要特性。