文章目录
ParNew收集器（Serial收集器的多线程版本-使用多条线程进行GC）
4.筛选回收（Live Data Counting and Evacuation）
概述
如果说前面介绍的收集算法（JVM之垃圾回收-垃圾收集算法）是内存回收的抽象策略，那么垃圾收集器就是内存回收的具体实现。
JVM规范对于垃圾收集器的应该如何实现没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器差别较大，这里只看HotSpot虚拟机。
就像没有最好的算法一样，垃圾收集器也没有最好，只有最合适。我们能做的就是根据具体的应用场景选择最合适的垃圾收集器。
Serial收集器
Serial（串行）收集器收集器是最基本、历史最悠久的垃圾收集器了（新生代采用复制算法，老生代采用标志整理算法）。大家看名字就知道这个收集器是一个单线程收集器了。
它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ “Stop The World” ：将用户正常工作的线程全部暂停掉），直到它收集结束。
看图理解：
上图中：
- 新生代采用复制算法，Stop-The-World
- 老年代采用标记-整理算法，Stop-The-World
当它进行GC工作的时候，虽然会造成Stop-The-World，正如每种算法都有存在的原因，该串行收集器也有存在的原因：因为简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，没有线程交互的开销，专心做GC，自然可以获得最高的单线程效率。所以Serial收集器对于运行在client模式下的应用是一个很好的选择（到目前为止，它依然是虚拟机运行在client模式下的默认新生代收集器）
串行收集器的缺点很明显，虚拟机的开发者当然也是知道这个缺点的，所以一直都在缩减Stop The World的时间。
在后续的垃圾收集器设计中停顿时间在不断缩短（但是仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续）
整理一下前面关于Serial收集器的知识
特点
- 针对新生代的收集器；
- 采用复制算法；
- 单线程收集；
- 进行垃圾收集时，必须暂停所有工作线程，直到完成；
- 即会"Stop The World"；
应用场景
- 依然是HotSpot在Client模式下默认的新生代收集器；
- 也有优于其他收集器的地方：
- 简单高效（与其他收集器的单线程相比）；
- 对于限定单个CPU的环境来说，Serial收集器没有线程交互（切换）开销，可以获得最高的单线程收集效率；
- 在用户的桌面应用场景中，可用内存一般不大（几十M至一两百M），可以在较短时间内完成垃圾收集（几十MS至一百多MS）,只要不频繁发生，这是可以接受的
设置参数
添加该参数来显式的使用串行垃圾收集器: "-XX:+UseSerialGC"
ParNew收集器（Serial收集器的多线程版本-使用多条线程进行GC）
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和Serial收集器完全一样。
它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，目前只有它能与CMS收集器配合工作。
CMS收集器是一个被认为具有划时代意义的并发收集器，因此如果有一个垃圾收集器能和它一起搭配使用让其更加完美，那这个收集器必然也是一个不可或缺的部分了。
收集器的运行过程如下图所示：
特点
除了多线程外，其余的行为、特点和Serial收集器一样；
如Serial收集器可用控制参数、收集算法、Stop The World、内存分配规则、回收策略等；
Serial收集器共用了不少代码；
应用场景
在Server模式下，ParNew收集器是一个非常重要的收集器，因为除Serial外，目前只有它能与CMS收集器配合工作；
但在单个CPU环境中，不会比Serail收集器有更好的效果，因为存在线程交互开销。
设置参数
指定使用CMS后，会默认使用ParNew作为新生代收集: "-XX:+UseConcMarkSweepGC" 强制指定使用ParNew: "-XX:+UseParNewGC" 指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相: "-XX:ParallelGCThreads"
为什么只有ParNew能与CMS收集器配合
- CMS是HotSpot在JDK1.5推出的第一款真正意义上的并发（Concurrent）收集器，第一次实现了让垃圾收集线程与用户线程（基本上）同时工作；
- CMS作为老年代收集器，但却无法与JDK1.4已经存在的新生代收集器Parallel Scavenge配合工作；
- 因为Parallel Scavenge（以及G1）都没有使用传统的GC收集器代码框架，而另外独立实现；而其余几种收集器则共用了部分的框架代码；
Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。
Parallel Scavenge收集器关注点是吞吐量（如何高效率的利用CPU）。
CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。
所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。（吞吐量：CPU用于用户代码的时间/CPU总消耗时间的比值，即=运行用户代码的时间/(运行用户代码时间+垃圾收集时间)。比如，虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。）
运行示意图：
Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，不进行手工优化，可以选择把内存管理优化交给虚拟机去完成。
特点
新生代收集器；
采用复制算法；
多线程收集；
CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间；而Parallel Scavenge收集器的目标则是达一个可控制的吞吐量（Throughput）；
应用场景
高吞吐量为目标，即减少垃圾收集时间，让用户代码获得更长的运行时间；
当应用程序运行在具有多个CPU上，对暂停时间没有特别高的要求时，即程序主要在后台进行计算，而不需要与用户进行太多交互；
例如，那些执行批量处理、订单处理（对账等）、工资支付、科学计算的应用程序；
设置参数
Parallel Scavenge收集器提供两个参数用于精确控制吞吐量：
控制最大垃圾收集停顿时间
"-XX:MaxGCPauseMillis"
- 控制最大垃圾收集停顿时间，大于0的毫秒数；
- MaxGCPauseMillis设置得稍小，停顿时间可能会缩短，但也可能会使得吞吐量下降；因为可能导致垃圾收集发生得更频繁；
设置垃圾收集时间占总时间的比率
"-XX:GCTimeRatio"
设置垃圾收集时间占总时间的比率，0 < n < 100的整数；
GCTimeRatio相当于设置吞吐量大小；
垃圾收集执行时间占应用程序执行时间的比例的计算方法是： 1 / (1 + n) 。
例如，选项-XX:GCTimeRatio=19，设置了垃圾收集时间占总时间的5% = 1/(1+19)；默认值是1% = 1/(1+99)，即n=99；
垃圾收集所花费的时间是年轻一代和老年代收集的总时间；
如果没有满足吞吐量目标，则增加代的内存大小以尽量增加用户程序运行的时间；
