共计 960 个字符，预计需要花费 3 分钟才能阅读完成。
原文链接
上图列举了七种作用于不同分代的垃圾收集器，如果两个收集器存在连线就阐明能够搭配应用。收集器所处的区域示意它所属的年老代还是老年代
属于年老代的回收器
Serial 收集器
简略高效且内存耗费小，实用于客户端模式下的虚拟机
该收集器是一个单线程工作的。意思是当它在进行垃圾回收时，必须暂停其余所有工作线程，直至它收集完结。Serial 和 Serial Old 收集器的运行过程如图所示：
ParNew 收集器
Serial 收集器的的多线程版本，除了同时应用多个线程进行垃圾回收之外其余行为与 Serial 收集器统一。在 JDK1.7 之前是除了 Serial 收集器之外，只有它能与 CMS 收集器配合工作
Parallel Scavenge 收集器
以吞吐量为指标的收集器，与 ParNew 收集器一样反对并行收集。应用两个参数用于准确管制吞吐量，也反对自适应调节策略
-XX:MAXGCPauseMillis：管制最大垃圾回收进展工夫。容许设置一个大于 0 的数，收集器将尽力保障内存回收的工夫不超过设定值-XX:GCTimeRatio：配置吞吐量大小。参数的值是一个大于 0 小于 100 的整数。
属于老年代的收集器
Serial Old 收集器
Serial 收集器的老年代版本，是一个单线程收集器，应用标记 - 压缩算法。在服务器端模式下，存在两种用处：
- 在 JDK5 以及之前的版本中与 Parallel Scavenge 收集器搭配应用
- 作为 CMS 收集器产生失败之后的后备计划
Parellel Old 收集器
Parellel Scavenge 收集器的老年代版本，反对多线程并发收集，基于标记 - 压缩算法实现。
CMS 收集器（Concurrent Mark Sweep）
是一种以获取最短回收进展工夫为指标的收集器，基于标记 - 革除算法实现。整个过程分为四个步骤：
- 初始标记：标记 GC Roots 能间接关联到的对象
- 并发标记：从 GC Roots 的间接关联对象开始遍历整个对象图
- 从新标记：批改并发标记期间因用户线程持续运作而导致标记产生变动的那局部对象
- 并发革除：清理删除标记阶段断定曾经死亡的对象
毛病：
- 因为应用标记 - 革除算法，在实现收集之后会产生碎片。碎片过多将会给大对象调配带来很大的麻烦，因为存在很多残余的空间然而无奈找到足够大的间断空间来调配对象，而不得不提前触发 Full GC
G1 收集器（Garbage First）
正文完