小胖在写完这篇文章后，问自己的几个问题。我想，看完这篇文章，你可能就会有自己的答案了。
- 1次10msGC和10次1ms的GC你会选择哪种？
- CMS收集器缺陷是什么?
- 提高CMS的启动阈值一定能提高性能吗？为什么？
- G1收集器为什么可以设置停顿时间？
- GC如何确定对象是否可被回收？
- 针对你说的“可达性分析法”，Minor GC时会扫描整个堆吗？
- JDK8默认的垃圾收集器是什么？
JVM那点事-垃圾收集算法讲了GC垃圾回收算法，即（
分代收集算法[复制算法——标记清除/标记整理]）。我们接下来讲一下垃圾回收器。下图展示了不同分代的收集器，如果两个收集器之间存在连线，说明他们可以搭配使用。虚拟机所在的区域，则表示它是属于新生代收集器还是老年代收集器。
1. Serial收集器（单线程收集器）
标签：新生代收集器 复制算法 单线程收集器
Serial收集器[ˈsɪriəl]是单线程新生代收集器，进行垃圾回收的时候，Stop the World暂停其他所有的工作线程。对于单个CPU的环境来说，简单而高效。（虚拟机运行在Client模式下的默认新生代收集器。）
2. ParNew收集器（并行收集器）
标签：新生代收集器 复制算法 多线程收集器 CMS默认收集器
ParNew（[ˈpær]）收集器其实就是Serial收集器的多线程版本。ParNew是许多运行在Server模式下虚拟机中首选的新生代收集器。一个重要原因是：目前除了Serial收集器外，只有它与CMS收集器配合工作。ParNew收集器也是使用-XX:UseConcMarkSweepGC选项的默认收集器，也可以使用-XX:+UseParNewGC选项强制指定。
ParNew收集器在单个CPU环境中绝对不会有比Serial收集器更好的效果。默认开启的收集器线程数与CPU的数量相同。可以使用-XX:ParallelGCThreads参数限制垃圾收集器的线程数[ˈpærəlel]。
并行（Parallel）：指多条垃圾收集器线程并行工作，但此时用户线程仍处于等待状态。
并发（Concurrent）：指用户线程与垃圾回收器同时执行（但不一定是并行的，可能会交替运行），用户程序在继续运行，而垃圾手机程序运行在另一个CPU上。
3. Parallel Scavenge收集器（并行收集器）
标签：新生代收集器 复制算法 多线程收集器 吞吐量优先
[ˈpærəlel][ˈskævɪndʒ] 并发清扫；Parallel Scavenge目标是达到一个可控制的吞吐量。（吞吐量=用户代码运行时间/虚拟机运行时间，例如程序运行了100分钟，GC占用1分钟，那么吞吐量就是99%）
（敲黑板，画重点：面试官问道：“小胖同学，1次10ms的GC和10次1ms的GC，你会选哪种？”）
- 停顿时间短：适合与 用户交互的程序，良好的响应速度提升用户体验。
- 高吞吐量：适合后台运算而不需要太多交互的任务，可以高效率利用CPU时间，尽快完成程序的运行任务.
（小胖内心OS：停顿时间1ms，这么快，一定是垃圾少，那就是牺牲了新生代空间，频繁GC会导致吞吐量的下降，但是适合用户交互程序，反之，吞吐量大的话，可以高效利用CPU，适合后台运算的程序。）
Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量。控制垃圾回收器停顿时间的-XX:MaxGCPauseMills
[pɔ:z]['mɪlz]。以及设置吞吐量大小的-XX:GCTimeRatio
不要以为把MaxGCPauseMills参数设置小就能使系统垃圾收集速度变快。GC停顿时间缩短是牺牲吞吐量和新生代空间来换取的。（比如将新生代调小，原来10s收集一次，每次100ms，；现在5s收集一次，每次70ms；停顿时间的确下降，但吞吐量也下降了）
GCTimeRatio参数的值应当是[0,100]的整数。如果把参数设置为19，允许最大的GC时间(1/(1+19))占用总时间的5%
4. Parallel Old收集器（并行收集器）
标签：老生代收集器 标记-整理算法 多线程收集器 吞吐量优先
注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。
5. CMS收集器（并发收集器）
标签： 老年代收集器 标记-清除算法 低停顿时间 并发收集器 CPU资源敏感 浮动垃圾 内存碎片
CMS（Concurrent Mark Sweep）收集器是一种获取最短回收停顿时间为目标的收集器。目前很大一部分的java应用集中在互联网或者B/S系统的服务端上。重视响应速度，希望系统停顿时间最短。
- 初始标记：标记GC Roots 直接关联的对象（Stop the World）。
-
并发标记：获取
初始标记的节点做为根节点，并发标记对象。 -
重新标记：修正
并发标记过程中变动的对象。如何修改？就是将并发标记阶段变化的对象记录在线程Remembered Set Logs线程，在重新标记阶段，将数据合并到Remember Set中。（PS：详见G1收集器描述）（Stop the World） -
并发清除：
并发清除对象
（原理简单明了）
其中初始标记、重新标记两个步骤仍然需要Stop The World。
缺点是：
对CPU资源敏感：在并发阶段，虽然不会导致用户线程停顿，但是占用线程（CPU资源）导致应用程序变慢。CMS默认启动的线程数
(CPU+3)/4，也就是当CPU在4个以上时，并发回收垃圾线程不少于25%的CPU资源。浮动垃圾：
并发清理阶段用户线程还在运行，只能下次GC回收，这些就称为“浮动垃圾”。垃圾收集阶段用户线程还在运行，所以不能等到老年代几乎填满在进行收集。要设置老年代预留空间，可以设置-XX：CMSInitiatingOccupancyFranction音标：[ɪ'nɪʃɪeɪtɪŋ]初始 [ˈɒkjəpənsi] 居住 [ˈfrækʃn] 一小部分，提高触发百分比。在JDK1.6，CMS收集器的启动阙值92%。要是CMS运行期间预留的内存无法满足程序需要，就会触发Concurrent Mode Failure失败，虚拟机启动后备方案，临时启动Serial Old收集器来重新进行老年代的垃圾回收。所以说，参数-XX:CMSInitiatingOccupancyFranction设置的太高，容易触发Concurrent Mode Failure失败，性能反而降低。内存碎片：“标记-清除”算法会产生大量空间碎片！空间碎片过多时，大对象分配带来麻烦，导致对象有很大剩余，但是无法找到连续空间分配对象，提前触发full GC。
可以设置-XX:UseCMSCompactAtFullCollectionCMS默认开启。在Full GC的时候采用合并整理过程，但是内存整理无法并发会导致停顿时间变长。还有一个参数-XX:CMSFullGCsBeforeCompaction，这个参数是用于执行多少次不压缩的Full GC跟着来一次压缩的。
总结来说：CMS并发收集，低停顿。
- 抢占CPU资源；
- 浮动垃圾，并且要为
应用程序预留空间，我们可以设置预留比例，但是预留比例无法满足应用程序需求时，会启动Serial Old收集器。性能可能下降;- 内存碎片，可以开启在
清除后合并压缩，但是整理阶段，无法并发。导致停顿时间变长，也可以设置多次Full GC后压缩碎片；
5. G1收集器（并发收集器）
标签： 分代收集 空间整合 并发收集 可预测停顿 内存化整为零
G1之前的其他收集器收集的范围都是新生代或者老年代。G1将整个Java堆划分为大小相等的独立区域·（region [ˈri:dʒən]）。新生代和老年代不再是物理隔离的了。他们都是一部分的region（不需要连续）的集合。
G1收集器之所以能建立可预测的停顿时间模型。是因为G1可以跟踪各个region里面垃圾堆价值大小（回收所获得的空间以及回收所需的时间经验值），在后台维护了优先列表。根据允许的收集时间，优先回收价值最大的Region。（划分空间以及有优先级的区域回收。PS：G1执行的第四步，筛选阶段，就是根据用户期望GC时间，制定回收计划！）
一个对象被分配到
region中，他并非只能被region中的其他对象引用，而是可以与整个java堆任意对象发生引用，那么可达性分析法判定对象是否存活时，岂不是还要扫描整个堆？在以前的分代收集中，新生代中的对象也面临着相同的问题，Minor GC时若是同时扫描老年代的话，那么Minor GC效率可能下降不少。
G1垃圾回收是否扫描整个堆，或者minor gc是否扫描整个堆？
在G1收集器中，Region之间的对象引用以及其他收集器新生代和老年代之间的对象引用。（敲黑板，划重点）虚拟机都是使用Remembered Set来避免全堆扫描的。
G1中每个region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂停暂时中断写操作，检查Reference引用对象是否处于不同的Region之中（分代中就是检查是否老年代中的对象引用新生代的对象）。如果是，便通过CardTable把相关的引用对象所属的Region的Remembered Set之中，当进行垃圾回收时，在GC Roots中的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。
小胖有话说：虚拟机对引用
类型数据进行写操作时，判断引用的对象是否处于不同的Rigion区，或者是否是老年代对象引用新生代对象，若是的话，则写入Remembered Set中，GC Roots会在枚举范围加入Remembered Set保证不进行全表扫描的情况下不会遗漏对象。
（嘻嘻，以后面试官问G1执行步骤时，将维护 Remembered Set操作也可以描述一下呀）
G1收集器运作大致可划分为以下几个步骤：
初始标记（Initial Marking）：暂停线程，标记
GC Roots能直接关联到的对象。并发阶段（Concurrent Marking）：对堆中的对象进行可达性分析，耗时较长，可并发执行；
最终阶段（Final Marking）：修正
并发阶段期间用户程序运行导致标记产生变化的记录；* （敲黑板，继续划重点）*虚拟机将这段时间对象变化在线程Remembered Set Logs中，最终阶段需要把Remembered Set Logs数据合并到Remembered Set中，需要停顿线程，但可并行执行。筛选阶段（Live Data Counting and Evacuation）：根据用户期望的GC停顿时间制定回收计划。也可做到与用户程序
并行执行。
