面试官：说一下JVM常用垃圾回收器的特点、优劣势、使用场景和参数设置
新生代回收器：Serial、ParNew、parallel
老年代回收器：Serial Old、CMS、Parallel Old
新生代和老年代回收器：G1
Serial
特点
JDK1.3.1前，Serial是HotSpot新生代收集的唯一选择。
有如下特点：
-
针对新生代； -
采用复制算法； -
单线程收集； -
进行垃圾收集时，必须暂停所有工作线程，直到完成；
优势
简单高效，由于采用的是单线程的方法，因此与其他类型的收集器相比，对单个cpu来说没有了上下文之间的的切换，效率比较高。
劣势
会在用户不知道的情况下停止所有工作线程。
使用场景
- Client 模式(桌面应用)
在用户的桌面应用场景中，可用内存一般不大，可以在较短时间内完成垃圾收集，只要不频繁发生，这是可以接受的
- 单核服务器
对于限定单个CPU的环境来说，Serial收集器没有线程切换开销，可以获得最高的单线程收集效率
参数设置
- -XX:+UseSerialGC：添加该参数来显式的使用串行垃圾收集器
ParNew
特点
ParNew收集器是Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余均和Serial 收集器一致。
优势
多线程版本的Serial，可以更加有效的利用系统资源。
劣势
同Serial，会在用户不知道的情况下停止所有工作线程。
使用场景
Server模式下使用，亮点是除Serial外，目前只有它能与CMS收集器配合工作，是一个非常重要的垃圾回收器。
参数配置
-
-XX:+UseConcMarkSweepGC：指定使用CMS后，会默认使用ParNew作为新生代收集器； -
-XX:+UseParNewGC：强制指定使用ParNew； -
-XX:ParallelGCThreads：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同；
parallel
特点
Parallel Scavenge也是一款用于新生代的多线程收集器，也是采用复制算法。与ParNew的不同之处在于Parallel Scavenge收集器的目的是达到一个可控制的吞吐量，而ParNew收集器关注点在于尽可能的缩短垃圾收集时用户线程的停顿时间。
有如下特点：
-
新生代收集器； -
采用复制算法； -
多线程收集； -
关注点与其他收集器不同： -
CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间； -
Parallel Scavenge收集器的目标是达一个可控制的吞吐量；
关于吞吐量和暂停时间的区别参考 GC的性能衡量指标：吞吐量 VS 暂停时间
优势
追求高吞吐量，高效利用CPU，是吞吐量优先，且能进行精确控制。
劣势
应该说是特点，追求高吞吐量必然要牺牲一些其他方面的优势。例如单个GC周期的停顿时间会变得更长。
使用场景
根据相关特性，我们很容易想到它的使用场景，即：当应用程序运行在具有多个CPU上，对暂停时间没有特别高的要求时，程序主要在后台进行计算，而不需要与用户进行太多交互等就特别适合parallel收集器。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序等。
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
参数设置
-
-XX:MaxGCPauseMillis：控制最大垃圾收集停顿时间，大于0的毫秒数； -
-XX:GCTimeRatio：设置垃圾收集时间占总时间的比率，0<n<100的整数；
MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。
GCTimeRatio参数的值应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1 /（1+19）），默认值为99，就是允许最大1%（即1 /（1+99））的垃圾收集时间。
Serial Old
特点
Serial Old是Serial收集器的老年代版本，同样是一个单线程收集器，使用标记-整理算法。
有如下特点：
-
针对老年代； -
采用"标记-整理"算法（还有压缩，Mark-Sweep-Compact）； -
单线程收集；
优劣势基本和Serial无异，它是和Serial收集器配合使用的老年代收集器。
使用场景
-
Client模式； -
单核服务器； -
与Parallel Scavenge收集器搭配； -
作为CMS收集器的后备方案，在并发收集发生Concurrent Mode Failure时使用
CMS
特点
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。采用的算法是“标记-清除”，运作过程分为四个步骤：
-
初始标记，标记GC Roots 能够直接关联到达对象 -
并发标记，进行GC Roots Tracing 的过程 -
重新标记，修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录 -
并发清除，用标记清除算法清除对象。
有如下特点：
-
针对老年代； -
基于"标记-清除"算法(不进行压缩操作，产生内存碎片)； -
以获取最短回收停顿时间为目标； -
并发收集、低停顿； -
需要更多的内存（看后面的缺点）；
优势
-
停顿时间短； -
吞吐量大； -
并发收集
劣势
-
对CPU资源非常敏感 -
无法收集浮动垃圾 -
容易产生大量内存碎片
使用场景
-
与用户交互较多的场景； -
希望系统停顿时间最短，注重服务的响应速度； -
以给用户带来较好的体验；
如常见WEB、B/S系统的服务器上的应用。
参数设置
- -XX:+UseConcMarkSweepGC：指定使用CMS收集器
Parallel Old
特点
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法，可以充分利用多核CPU的计算能力。
有如下特点：
-
针对老年代； -
采用"标记-整理"算法； -
多线程收集；
优劣势参考Parallel Scavenge收集器。
使用场景
-
JDK1.6及之后用来代替老年代的Serial Old收集器； -
特别是在Server模式，多CPU的情况下；
这样在注重吞吐量以及CPU资源敏感的场景，就有了Parallel Scavenge（新生代）加Parallel Old（老年代）收集器的"给力"应用组合；
参数设置
- -XX:+UseParallelOldGC：指定使用Parallel Old收集器
G1
G1（Garbage-First）是JDK7-u4才推出商用的收集器
-
并行与并发：G1能充分利用多CPU，多核环境下的硬件优势。 -
分代收集：能够采用不同的方式去处理新创建的对象和已经存活了一段时间的对象，不需要与其他收集器进行合作。 -
空间整合：G1从整体上来看基于“标记-整理”算法实现的收集器，从局部上看是基于复制算法实现的，因此G1运行期间不会产生空间碎片。 -
可预测的停顿：G1能建立可预测的时间停顿模型，能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
有如下特点：
-
并行与并发 -
分代收集，收集范围包括新生代和老年代 -
结合多种垃圾收集算法，空间整合，不产生碎片 -
可预测的停顿：低停顿的同时实现高吞吐量 -
面向服务端应用，将来替换CMS
优势
-
能充分利用多CPU、多核环境下的硬件优势； -
能独立管理整个GC堆（新生代和老年代），而不需要与其他收集器搭配； -
不会产生内存碎片，有利于长时间运行； -
除了追求低停顿处，还能建立可预测的停顿时间模型；
G1收集器是当今收集器技术发展的最前沿成果。
劣势
G1 需要记忆集 (具体来说是卡表)来记录新生代和老年代之间的引用关系，这种数据结构在 G1 中需要占用大量的内存，可能达到整个堆内存容量的 20% 甚至更多。而且 G1 中维护记忆集的成本较高，带来了更高的执行负载，影响效率。
按照《深入理解Java虚拟机》作者的说法，CMS 在小内存应用上的表现要优于 G1，而大内存应用上 G1 更有优势，大小内存的界限是6GB到8GB。
使用场景
个人以为G1已经基本全面压制cms、parallel等回收器，缺点见上面的劣势。但如果不是追求极致的性能，基本可以无脑G1。
参数设置
-
-XX:+UseG1GC：指定使用G1收集器； -
-XX:InitiatingHeapOccupancyPercent：当整个Java堆的占用率达到参数值时，开始并发标记阶段；默认为45； -
-XX:MaxGCPauseMillis：为G1设置暂停时间目标，默认值为200毫秒； -
-XX:G1HeapRegionSize：设置每个Region大小，范围1MB到32MB；目标是在最小Java堆时可以拥有约2048个Region；
