1.垃圾收集器
1.1 Serial收集器
这个收集器是一个单线程的收集器，它在进行垃圾收集时，必须暂停其他所有的工作线程。
它是虚拟机运行在Client模式下的默认新生代收集器，它简单而高效。
1.2 ParNew收集器
其实就是Serial收集器的多线程版本，目前只有它能与CMS收集器配合工作。
1.3 Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代的收集器，使用复制算法。
它经常被称为“吞吐量优先”的收集器，它的特点就是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而这个收集器的目标则是达到一个可控制的吞吐量。
高吞吐量可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需太多交互的任务。
它还有一个参数-XX：+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象大小（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式成为“GC自适应的调节策略（GC Ergonomics）”
1.4 Serial Old收集器
它是Serial的老年代版本，也是一个单线程收集器。使用“标记-整理”算法，在Client模式下的虚拟机使用。
1.5 Parallel Old 收集器
它是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。主要用于“吞吐量优先”以及CPU资源敏感场合，Parallel Scavenge加Parallel Old收集器可以优先考虑。
1.6 CMS收集器
CMS收集器是一种以获取最短回收停顿时间为目标的收集器。可以使系统停顿时间短，给用户带来较好的体验。
CMS收集器基于“标记-清除”算法实现：
- 初始标记
- 并发标记
- 重新标记
- 并发清除
其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。
- 初始标记仅仅只是标记一下FC Roots能直接关联到的对象，速度很快
- 并发标记阶段就是进行GC Roots Tracing的过程
- 重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。
- 并发清除与并发标记这两个耗时最长的操作，从总体上说CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS的缺点
- CMS收集器对CPU资源非常敏感：当CPU不足四个的时候，对用户程序的影响就很大。因为它要分出一半的运算能力去执行收集器线程。
- CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另外一次Full GC的产生。
- CMS是一款基于“标记-清除”算法实现的收集器，这就意味着收集结束时会有大量的空间碎片产生。将会给大对象分配带来很大麻烦。
1.7 G1收集器
G1是一款面向服务端应用的垃圾收集器。特点如下：
- 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短STP停顿时间。
- 分代收集：G1不需要其他收集器配合就能独立管理整个GC堆，但是它能够采用不同的方式去处理新创建的对象和已经存活的对象。
- 空间整理：G1从整体看是基于“标记-整理”算法实现的，从局部（两个Region之间）上看是基于“复制”算法实现的。保证G1运作期间不会产生内存空间碎片。
- 可预测的停顿：可以明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集器上时间不得超过N毫秒。
G1讲解：
G1收集器将Java堆的内存分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的，它们都是Regionde 的集合。G1在后台维护一个优先列表，每次根据允许收集的时间，优先回收最大的Region。
G1运作过程
- 初始标记：标记GC Roots能直接关联到的对象并且修改TAMS的值，让用户程序并发运行时还能在Region中创建对象，这个阶段需要停顿线程。（耗时较短）
- 并发标记：从GC Roots中对堆对象进行可达性分析，找出存活对象。但可与用户程序并发执行。（耗时长）
- 最终标记：修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录。
- 筛选回收：首先对各个Region的回收价值和成本进行排序，根据用户期望的GC停顿时间来制定回收计划。
