经典的垃圾收集器

serial收集器

    serial收集器：最基础历史最悠久的，Hotspot新生代的唯一选择，单线程工作的收集器。它不仅仅只使用一个处理器或者收集线程去完成垃圾回收，而且最主要强调是的垃圾回收时他会暂停其他工作线程，直至它结束。（迄今为止它仍是Hotspot客户端模式下的默认新生代收集器）
  特点：内存消耗最小，单核处理器或者处理器核心数较少时具有最高的单线程收集效率。

ParNew收集器

   ParNew收集器：实质上是serial收集器多线程并行版，其中参数，算法，stop the word ，对象分配规则，回收策略跟serial一样。是JDK7之前系统的首选新生代收集器。而且最主要的原因是他能跟CMS收集器配合使用。

Parallel Scavenge收集器

   Parallel Scavenge收集器（吞吐量优先收集器）：新生代收集器，同样使用了标记-复制算法实现。也是能够进行并行收集的多线程收集器。Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值：

   Parallel Scavenge收集器还有一个参数-XX：+UseAdaptiveSizePolicy：虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。这种调节方式称为垃圾收集的自适应的调节策略（GC Ergonomics）。自适应调节策略也是Parallel Scavenge收集器区别于ParNew收集器的一个重要特性。

serial old

   serial old：是serial收集器的老年代版本，也是单线程收集器，使用的是标记-整理算法。

Parallel Old收集器

   Parallel Old收集器：是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-整理法。

CMS（并发低停顿收集器）

   CMS收集器：是Hotspot虚拟机第一款真正意义上支持并发的垃圾收集器，首次实现了让垃圾收集线程与用户线程基本上的同时工作。
  自JDK 9开始，ParNew加CMS收集器的组合就不再是官方推荐的服务端模式下的收集器解决方案了。官方希望它能完全被G1所取代，甚至还取消了ParNew加Serial Old以及Serial加CMS这两组收集器组合的支持（其实原本也很少人这样使用），并直接取消了-XX：+UseParNewGC参数，这意味着ParNew和CMS从此只能互相搭配使用，再也没有其他收集器能够和它们配合了。读者也可以理解为从此以后，ParNew合并入CMS，成为它专门处理新生代的组成部分。ParNew可以说是HotSpot虚拟机中第一款退出历史舞台的垃圾收集器。

   CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。基于标记-清除算法，其中过程分为四个步骤：1.初始标记（CMS initial mark）2.并发标记（CMS concurrent mark）3.重新标记（CMS remark）4.并发清除（CMS concurrent sweep）。
   其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录（详见3.4.6节中关于增量更新的讲解），这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

   缺点：

 1. CMS收集器对处理器资源非常敏感。并发阶段不会导致用户线程停顿，会占用部分线程导致应用程序变慢，降低总吞吐量。
  2. CMS无法处理“浮动垃圾”（Floating Garbage），有可能出现“Con-current Mode Failure”失败进而导致另一次完全“Stop The World”的Full GC的产生。在CMS的并发标记和并发清理阶段，用户线程是还在继续运行的，程序在运行自然就还会伴随有新的垃圾对象不断产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS无法在当次收集中处理掉它们，只好留待下一次垃圾收集时再清理掉。这一部分垃圾就称为“浮动垃圾”。
  3. CMS是一款基于“标记-清除”算法实现的收集器这意味着收集结束时会有大量空间碎片产生。

7. Garbage First收集器（G1）

  G1是一个面向全堆的收集器，不需要其他新生代收集器配合。
  开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。G1是一款主要面向服务端应用的垃圾收集器，它可以面向堆内存任何部分来组成回收集（Collection Set，一般简称CSet）进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的Mixed GC模式。
  G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。
  Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1的大多数行为都把Humongous Region作为老年代的一部分来进行看待。虽然G1仍然保留新生代和老年代的概念，但新生代和老年代不再是固定的了，它们都是一系列区域（不需要连续）的动态集合。G1收集器之所以能建立可预测的停顿时间模型，是因为它将Region作为单次回收的最小单元，即每次收集到的内存空间都是Region大小的整数倍，这样可以有计划地避免在整个Java堆中进行全区域的垃圾收集。更具体的处理思路是让G1收集器去跟踪各个Region里面的垃圾堆积的“价值”大小，价值即回收所获得的空间大小以及回收所需时间的经验值，然后在后台维护一个优先级列表，每次根据用户设定允许的收集停顿时间（使用参数-XX：MaxGCPauseMillis指定，默认值是200毫秒），优先处理回收价值收益最大的那些Region，这也就是“Garbage First”名字的由来。这种使用Region划分内存空间，以及具有优先级的区域回收方式，保证了G1收集器在有限的时间内获取尽可能高的收集效率。
  在CMS和G1之前的全部收集器，其工作的所有步骤都会产生“Stop The World”式的停顿；CMS和G1分别使用增量更新和原始快照技术，实现了标记阶段的并发，不会因管理的堆内存变大，要标记的对象变多而导致停顿时间随之增长。CMS使用标记-清除算法，虽然避免了整理阶段收集器带来的停顿，但是清除算法不论如何优化改进，在设计原理上避免不了空间碎片的产生，随着空间碎片不断淤积最终依然逃不过“Stop The World”的命运。G1虽然可以按更小的粒度进行回收，从而抑制整理阶段出现时间过长的停顿，但毕竟也还是要暂停的。