本章主要整理JDK7update 4之后 Jdk11之前，OracleJdk中的HotSpot虚拟机所包含的全部可用的垃圾收集器。
| 收集器名称 | 可配合使用收集器 | 简介 | 特点 |
|---|---|---|---|
| Serial | CMS | JDK1.3.1之前HotSpot的唯一选择。在进行垃圾收集的时候，必须暂停其他所有的工作线程，知道它收集结束。"单线程"工作收集器。只会使用一个处理器或者一条收集线程去完成垃圾回收工作 | 使用于允许在客户端模式下的虚拟机 |
| ParNew | CMS 、Serial Old | 实际上是Serial 收集器的多现车给版本，除了同时使用多条线程 进行垃圾收集之外，其余的行为包括Serial所用参数都和Serial收集器完全一致。在JDK5发布的垃圾收集器CMS巩固了ParNew收集器。因为CMS作为老年代收集器无法与JDK1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作。所以在JDK5中使用CMS来收集老年代的时候，新生代只能选择Serial或者ParNew收集器 中的一个。 | 对于垃圾收集时系统资源的高效利用非常有好处，因为它默认开的收集现车给与处理器核心数量相同。 |
| Parallel Scavenge | Serial Old、Parallel Old | 一款新生代收集器，同样是基于标记-复制算法实现的收集器,能够并行收集的多线程收集器。Parallel Scavenge收集器的关注点在于 目标达到一个可控制的吞吐量。吞吐量就是 :吞吐量=运行用户代码时间/(运行用户代码时间+运行垃圾收集时间)
|
|
| CMS | Serial Old 、 ParNew 、Serial | 获取最短回收停顿时间为目标的收集器。 | 希望系统停顿时间尽可能段，以给用户带来良好的体验。可以采用CMS收集器 |
| Parallel Old | Parallel Scavenge | Parallel Scanven ge收集器的老年代版本，支持多线程并发收。基于标记-整理算法。在此之前比较尴尬。因为新生代选择了 Parallel Scavenge收集器，老年代除了Serial Old 收集器别无选择，CMS无法与它配合工作 |
出生在JDK1.6，在此之前，新生代收集器Parallel Scavenge收集器，除了Serial Old收集器以外别无选择，其他表现良好的收集器无法与他工作。Parallel Old收集器出现后，吞吐量优先收集器有了比较名副其实的搭配组合。再注重吞吐量或者处理器资源较为稀缺的场合，都可以考虑这个收集器组合 |
| Serial Old | CMS 、 Serial 、 ParNew、 Parallel Scavenge | Serial 的老年代版本，同样是一个单线程收集器，使用标记-整理算法 | 用途，再JDK5以及之前的版本中与Parallel Scavenge收集器的搭配使用，另外一种就是作为CMS收集器发生失败后的后备预案。在并发收集发生Concurrent Mode Failure时使用。 |
| G1 | G1收集器是垃圾收集器技术发展历史上的里程碑式的成果它开创了收集器面向局部收集的涉及思路何基于Region的内存布局形式 | G1是一款主要面向服务端应用的垃圾收集器。HotSpot开发团队最初赋予它未来可用替换掉JDK5中发布的CMS收集器。JDK9发之日，G1宣告取代Parallel Scavenge加Parallel Old组合，成为服务端模式下的默认垃圾收集器。而CMS则沦落至被声明为不推荐的收集器。 | |
| 低延迟垃圾收集器 | |||
| Shenandoah | Shenandoah是由ReadHat公司独立发展的新型项收集项目，在2014年贡献给了OpenJdk。目标实现是一种能在堆内存大小都可以把垃圾收集的停顿时间限制在十毫秒的垃圾收集器。Shenandoah不仅要进行并发的垃圾标记，还要进行对象清理后的这个理动作。 | Shenandoah也是使用基于Region的堆内存布局，在管理堆内存方面，它与G1至少有三个明显的不通地方，最重要的是支持并发的而整理算法，G1的回收阶段是可以线程并行的，但是不能与用户线程并发。 | |
| ZGC | ZGC和Shenandoah目标hi高度相似的，都希望在尽可能对吞吐量影响不大的情况下，实现任意堆内存大小都可以把垃圾收集器的停顿时间限制在10毫秒以内的低延迟。 |
网友评论