垃圾收集器

新生代：Serial收集器、ParNew收集器、Parallel Scavenge收集器，一般是复制算法

老年代：Serial Old收集器、Parallel Old收集器、CMS收集器，一般是标记-整理算法

新生代、老年代同时适用：G1收集器

垃圾收集算法主要有：标记-清除、复制、标记-整理。

在新生代，每次垃圾回收时都发现有大批对象死去，只有少量存活，就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。

在老年代，由于对象存活率高、没有额外空间对它进行分配担保，就必须使用标记-清除或者标记-整理算法进行回收。

Serial收集器

• 单线程的新生代收集器，在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。
• 采用复制算法
• 简单而高效（与其他收集器的单线程比），对于限定的单个CPU的环境下，没有线程交互的开销，专心做垃圾回收操作。
• 是虚拟机运行在Client模式下的默认新生代收集器。

ParNew收集器

• 其实就是Serial收集器的多线程版本，其他与Serial收集器完全一样（比如控制参数、收集算法、Stop The World、对象分配规则、回收策略） 。默认开启的收集线程与CPU数量相同，在CPU非常多的环境下，可使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
• 是很多运行在Server模式下的虚拟机中首选的新生代收集器：除了Serial收集器，只有它能与CMS收集器配合工作。它也是使用CMS收集器时默认的新生代收集器。

Parallel Scavenge收集器

• 新生代收集器，使用复制算法，并行的多线程收集器。
• 该收集器的目标是达到一个可控制的吞吐量（CPU用于运行用户代码的时间与CPU总消耗时间的比值），吞吐量=运行用户代码时间/（运行用户代码时间 + 垃圾收集时间），被称为吞吐量优先的收集器。
• 高吞吐量可以高效率地利用CPU时间，尽快完成程序的运算任务，适合在后台运算而不需要太多交互的任务。
• 设定两个参数来控制吞吐量：最大垃圾收集停顿时间-XX:MaxGCPauseMills和吞吐量大小-XX:GCTimeRatio。
• 自适应调节策略：通过参数-XX:+UseAdaptiveSizePolicy，开启之后，就不需要手工指定新生代大小、Eden与Survivor区的比例、晋升老年代对象的大小等细节参数，虚拟机会根据当前系统运行情况进行GC自适应调节。

Serial Old收集器

• Serial收集器的老年代版本，单线程，使用标记-整理算法。
• 主要意义是在给定Client模式下的虚拟机使用。在Server模式下，有两种用途：①在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；②作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

Parallel Old收集器

• Parallel Scavenge收集器的老年代版本，多线程，使用标记-整理算法。
• JDK1.6中才开始提供该收集器。在此之前，新生代如果选择了Parallel Scavenge收集器，老年代只能选择Serial Old收集器。Parallel Old收集器的出现，使得“吞吐量优先收集器”有了比较名副其实的组合：Parallel Scavenge + Parallel Old。

CMS收集器（重点）

• 老年代收集器
• CMS（Concurrent Mark Sweep）收集器是一种获取最短回收停顿时间为目标的收集器。优点是并发、低停顿。在互联网网站或者B/S系统的服务端上的Java应用，注重服务的响应时间，希望系统停顿时间最短，以带给用户较好的体验，CMS收集器非常适合这类应用的需求。
• 基于标记-清除算法，运作过程分为4个步骤： a.初始标记：需要Stop The World，标记GC Roots能直接关联到的对象，速度很快。 b.并发标记：与用户程序一起运行，进行GC Roots Tracing的过程。 c.重新标记：需要Stop The World，修正并发标记阶段因用户程序继续运作而导致标记产生变化的那一部分对象的标记记录。该阶段的停顿时间比初始阶段稍长，但远小于并发标记的停顿时间。 d.并发清除：与用户程序一起运行，进行清除工作。
• CMS远达不到完美的程度，它有4个明显的缺点： a.对CPU非常敏感：因占用CPU资源导致应用程序变慢，总吞吐量降低。CMS默认的垃圾收集线程数为（CPU数量 + 3）/4。当CPU在4个以上时，垃圾回收线程会至少占用25%的CPU资源，并会随着CPU数量增加而下降。当CPU不足4个时，CMS对用户程序的影响可能就非常大。 b.CMS无法处理浮动垃圾。由于CMS并发清理阶段用户线程还在运行，可能会出现新的垃圾，CMS无法在本次收集时处理它们，只能等下一次GC再清理。这部分垃圾就是浮动垃圾。 c.由于并发收集，在收集时还要预留内存空间供用户程序使用，因此CMS收集器无法像其他收集器一样等到老年代几乎被完全填充时再进行收集。在JDK1.5的默认设置下，当老年代使用了68%的时候，就会进行垃圾收集。如果应用中老年代增长不快，可适当提高该值。JDK1.6将该值提升到92%。但不能设置的太高：如果在CMS运行期间预留的内存空间无法满足程序需要，就会出现Concurrent Mode Failure，这时虚拟机将会启动后备预案：临时启用Serial Old收集器重新进行老年代的垃圾收集，导致停顿时间很长。可以通过参数-XX:CMSInitiatingOccupancyFraction设置该值。 d.基于标记-清除算法，容易造成内存碎片，往往出现老年代还有很大空间剩余，但无法找到足够大的连续空间来分配当前对象，不得不出发一次Full GC。可以通过参数-XX:UseCMSCompactAtFullCollection（默认开启），用于在CMS顶不住要进行一次FullGC时开启内存碎片整理过程（该过程无法并发，需要停顿）。还可以使用参数-XX:CMSFullGCsBeforeCompaction设定执行多少次不压缩的FullGC后，跟着来一次带压缩的（默认为0，即每次进入FullGC时都进行碎片压缩）。

G1收集器

• Garbage-First是当今收集器技术发展的最前沿成果之一。
• G1是一款面向服务器端应用的垃圾收集器，相比于CMS，优点是： ①并行与并发：缩短Stop The World的时间； ②分代收集：将堆划分为多个大小相等的独立区域Region，虽然还保留新生代和老年代的概念，但新生代和老年代不再是物理隔离了，他们都是一部分Region的集合（不需要连续）； ③空间整合：从整体上看基于标记-整理算法，从局部（两个Region）看是基于复制算法，不会产生内存碎片； ④可预测的停顿：可以指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。