下面给出基于JDK 1.7 Update 14之后的HotSpot虚拟机的所有收集器如下图所示：
1.Serial收集器：
使用一个CPU或一条收集线程去完成垃圾收集工作，在进行垃圾收集的时候必须暂停其它所有的工作线程，直到它收集结束。
特点：单线程，简单高效，没有多线程交互的开销。
年代：新生；
算法：复制算法。
2.ParNew收集器：
Serial收集器的多线程版本。
除了Serial收集器，目前只有ParNew收集器能与CMS收集器配合工作。
特点：多线程；
年代：新生、老年；
算法：新生代-复制算法；老年代-标记-整理算法。
3.Parallel Scavenge收集器：
拥有自适应调节策略；
特点：并行，目标是达到一个可控制的吞吐量
年代：新生；
算法：复制算法。
4.Serial Old收集器：
Serial收集器的老年代版本；
特点：单线程；
年代：老年代；
算法：标记-整理；
5.Parallel Old收集器：
Parallel Scavenge收集器的老年代版本；
特点：多线程；
年代：老年代；
算法：标记-整理算法。
6.CMS收集器：
以获取最短回收停顿时间为目标；
特点：并发收集、低停顿；
年代：老年代；
算法：标记-清除算法；
运作过程：
（1）初始标记：（需要stop the world）标记GC Roots能直接关联到的对象；
（2）并发标记：进行GC Roots Tracing的过程，耗时长；
（3）重新标记：（需要stop the world）修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录；
（4）并发清除：耗时长；
缺点：
（1）对CPU资源非常敏感；
（2）无法处理浮动垃圾；（并发处理阶段产生的垃圾）
（3）大量碎片产生；
7.G1收集器：
特点：
（1）并发与并行；
（2）分代收集；
（3）空间整合；
（4）可预测的停顿；
年代：新生，老年；
算法：从整体来看是基于“标记-整理”算法，从局部（两个Region之间）是基于“复制”算法实现；G1运作期间不会产生内存碎片。
G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。
步骤：
（1）初始标记：标记GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Next Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新的对象；需要停顿线程，但耗时短；
（2）并发标记：从GC Roots开始对堆中对象进行可达性分析，找出存活对象；耗时长，可并发执行；
（3）最终标记：修正上一阶段因用户线程运作而导致标记产生变动的那一部分的记录，记录在线程Remembered Set Log里面，最终把数据整合到Remembered Set中；需要停顿线程，但可并行执行；
（4）筛选回收：首先对各个Region中的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划；并发执行。
