经典垃圾收集器
Serial收集
使用一个处理器或一条收集线程去完成垃圾收集工作，更重要的是强调在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。
ParNew收集器
ParNew
收集器除了支持多线程并行收集之外，其他与
Serial
收集器相比并没有太多创新之处，但它
却是不少运行在服务端模式下的
HotSpot
虚拟机，尤其是
JDK 7
之前的遗留系统中首选的新生代收集器，其中有一个与功能、性能无关但其实很重要的原因是：除了Serial
收集器外，目前只有它能与
CMS收集器配合工作。
Parallel Scavenge收集器
同样是基于标记-复制算法实现的收集器，也是能够并行收集的多线程收集器，Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能 地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值
Serial Old收集器
Serial Old
是
Serial
收集器的老年代版本，它同样是一个单线程收集器，使用标记
-
整理算法。
Parallel Old收集器
Parallel Old
是
Parallel Scavenge
收集器的老年代版本，支持多线程并发收集，基于标记
-
整理算法实现
CMS收集器(重点1)
CMS
（
Concurrent Mark Sweep
）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很
大一部分的
Java
应用集中在互联网网站或者基于浏览器的
B/S
系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。CMS
收集器就非常符合这类应用的需求。
从名字（包含
“Mark Sweep”
）上就可以看出
CMS
收集器是基于标记
-
清除算法实现的，它的运作
过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤:
由于在整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一
起工作，所以从总体上来说，
CMS
收集器的内存回收过程是与用户线程一起并发执行的
其中初始标记、重新标记这两个步骤仍然需要
“Stop The World”
。初始标记仅仅只是标记一下
GC
Roots能直接关联到的对象，速度很快；并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。
CMS
是一款优秀的收集器，它最主要的优点在名字上已经体现出来：并发收集、低停顿，一些官
方公开文档里面也称之为
“
并发低停顿收集器
”
（
Concurrent Low Pause Collector
）。
三个缺点：
1.
CMS
收集器对处理器资源非常敏感
2.由于
CMS
收集器无法处理
“
浮动垃圾
”
（
Floating Garbage
）
3.CMS
是一款基于
“
标记
-
清除
”算法实现的收集器,会有大量空间碎片产生。
G1收集器（重点2）
它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。
G1是一款主要面向服务端应用的垃圾收集器。
G1
开创的基于
Region
的堆内存布局是它能够实现这个目标的关键。虽然
G1
也仍是遵循分代收集理
论设计的，但其堆内存的布局与其他收集器有非常明显的差异：
G1
不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java
堆划分为多个大小相等的独立区域（
Region
），每一个
Region
都可以
根据需要，扮演新生代的
Eden
空间、
Survivor
空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。
