前两篇文章分别介绍了JVM 运行时内存划分和堆上的内存分配机制，本文将对垃圾收集器进行介绍，先来看下面这幅图：
图中棕色方块指的是新生代可选的垃圾收集器，蓝色方块指的是老年代垃圾收集器，G1是可以用于新生代和老年代的垃圾收集器。棕色方块和蓝色方块之间的连线表示连线一端的新生代垃圾收集器和另一端的老年代垃圾收集器可以配置使用作为整个堆的垃圾收集器组合。下面对分代对各个垃圾收集器进行介绍
新生代垃圾收集器
Serial 收集器
- 是最基本、发展历史最悠久的收集器
- 是虚拟机在 Client 模式下默认的新生代收集器
- 使用 stop-and-copy（停止-复制）算法，该算法中：
- 新生代被分为三个区域：Eden区（简称E区），Survivor0区（简称S0区），Survivor1区（简称S1区），默认上，三个区的空间大小比例为
E区 : S0区 : S1区 = 8 : 1 : 1 - 绝大多数对象刚创建的时候会被分在 E 区，其中大多数对象很快消亡（IBM 的统计是98%）
- E 区是连续的空间，因此在其上分配空间极快
- 当 E 区第一次满的时候，执行 Minor GC，将消亡的对象清理掉，并将剩余存活的对象复制到 S0 区（此时，S1 区是空闲的）
- 下次 E 区满时，再执行一次 Minor GC，将 E 区和 S0 区消亡的对象清理掉，将存活的对象复制到 S1 区，然后清空 E 区和 S0 区
- 当两个 S 区切换了几次后（默认15次），仍然存活的对象，将被复制到老年代
- 新生代被分为三个区域：Eden区（简称E区），Survivor0区（简称S0区），Survivor1区（简称S1区），默认上，三个区的空间大小比例为
- 使用单线程来执行垃圾收集工作，在进行垃圾收集时，其他工作线程暂停
- 效率较低
ParNew 收集器
- 就是 Serial 的多线程版，除了使用多线程进行垃圾收集之外，其余行为与 Serial 收集器一致
Parallel Scavenge 收集器
- 使用 stop-and-copy（停止-复制）算法
- 使用多线程进行垃圾收集
- 吞吐量优先，目标是达到一个可控制的吞吐量
-
吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间），比如，虚拟机总共运行了 100 分钟，其中垃圾收集花掉一分钟，那么吞吐量就是 99%
-
- 具有 GC 自适应调节策略
- 通过 -XX:+UseAdaptiveSizePolicy 开启
- 当该参数打开后，就不需要指定新生代大小、Eden 区与Survivor 区大小比例、晋升老年代对象年龄等参数了，虚拟机会根据当前的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间和最大吞吐量
老年代收集器
Serial Old 收集器
- Serial 收集器的老年代版本，同样是一个单线程收集器，使用 “标记-整理” 算法，该算法分为两步：
- 标记：遍历标记出所有存活对象
- 整理：移动所有存活的对象，且按照内存地址次序一次排列，然后将末端内存地址以后的内存全部回收
- 可作为 CMS 收集器的老年代备用方案
Parallel Old 收集器
- 是 Parallel Scavenge 收集器的老年代版本，使用多线程进行垃圾收集并使用 “标记-整理” 算法
CMS 收集器
- 是一种以获取最短回收停顿时间为目标的收集器
- 使用 “标记-清除” 算法，该算法分为两步：
- 标记：遍历以标记出所有存活对象
- 清除：将没有标记为存活的对象全部清除
- 由于整个过程中耗时最长的多线程标记和清除都与工作线程一起工作，所以，从总体上来说，CMS 收集器的内存回收过程是与工作线程一起执行的
- 缺点：
- 会占用更多 CPU 资源：CMS 默认启动的回收线程数是
（CPU 数量 + 3）/4 - 基于 “标记-清理” 算法会产生大量内存碎片，内存碎片过多时，往往容易出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配大对象，不得不提前触发一次 Full GC
- 无法处理在 “标记-清理” 过程的同时产生的垃圾（因为此时工作线程还在运行，在持续产生垃圾），每次清理都不够彻底
- 会占用更多 CPU 资源：CMS 默认启动的回收线程数是
G1 收集器
- 多线程收集器，收集垃圾的线程和工作线程可同时进行
- 不容易产生内存碎片
- 收集后能提供规整的可用内存，有利于程序长时间运行
- 可预测的停顿：能让使用者明确指定一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒
