☕【JVM 技术之旅】深入 JVM 回收器之 Parallel Scavenge（上篇）

Parallel Scavenge 收集器

Parallel Scavenge 收集器是一个新生代收集器，它也是使用【标记-复制】算法的收集器，又是并行的多线程收集，看上去和 ParNew 差不多，那它有什么特别之处呢？总体而言就是 Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同。

• CMS 收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，

• 停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。

• Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量（Throughput）。

• 吞吐量是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间），虚拟机总共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是 99%。

• 高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

• ---

  
  

Parallel Scavenge：收集器提供了几个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的

-XX:MaxGCPauseMillis：参数允许的值是一个大于 0 的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。

• 不过不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC 停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集 300MB 新生代肯定比收集 500MB 快吧，这也直接导致垃圾收集发生得更频繁一些，原来 10 秒收集一次、每次停顿 100 毫秒，现在变成 5 秒收集一次、每次停顿 70 毫秒。停顿时间的确在下降，但吞吐量也降下来了。(因为回收的频率升高了)。

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

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

-XX:+UseAdaptiveSizePolicy：一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden 与 Survivor 区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为 GC 自适应的调节策略（GC Ergonomics）。

如果读者对于收集器运作原来不太了解，手工优化存在困难的时候，使用 Parallel Scavenge 收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。

只需要把基本的内存数据设置好（如-Xmx 设置最大堆），然后使用 MaxGCPauseMillis 参数（更关注最大停顿时间）或 GCTimeRatio（更关注吞吐量）参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是 Parallel Scavenge 收集器与 ParNew 收集器的一个重要区别。