JVM真香系列：图解垃圾回收器
回复“000”获取大量电子书
不知不觉，JVM系列已经到回收算法的实现了。
本文主要内容
先普及三个概念：
并行收集：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。
吞吐量：即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )）。
例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%。
新生代
Serial
Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK1.3.1之前）是虚拟机新生代收集的唯一选择。
它是一种单线程收集器，不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作，更重要的是其在进行垃圾收集的时候需要暂停其他线程。
优点：简单高效，拥有很高的单线程收集效率
缺点：收集过程需要暂停所有线程
算法：复制算法
应用：Client模式下的默认新生代收集器
收集过程：
ParNew
可以把这个收集器理解为Serial收集器的多线程版本。
优点：在多CPU时，比Serial效率高。
缺点：收集过程暂停所有应用程序线程，单CPU时比Serial效率差。
算法：复制算法
应用：运行在Server模式下的虚拟机中首选的新生代收集器
收集过程：
Parallel Scanvenge
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew一样，但是Parallel Scanvenge更关注系统的吞吐量 。
吞吐量 = 运行用户代码的时间 / (运行用户代码的时间 + 垃圾收集时间)
比如虚拟机总共运行了120秒，垃圾收集时间用了1秒，吞吐量=(120-1)/120=99.167%。
若吞吐量越大，意味着垃圾收集的时间越短，则用户代码可以充分利用CPU资源，尽快完成程序的运算任务。
可设置参数：
-XX:MaxGCPauseMillis控制最大的垃圾收集停顿时间，
-XX:GC Time Ratio直接设置吞吐量的大小。
老年代
CMS=Concurrent Mark Sweep
特点：最短回收停顿时间，
回收算法：标记-清除
回收步骤：
初始标记：标记
GC Roots直接关联的对象，速度快并发标记：
GC Roots Tracing过程，耗时长，与用户进程并发工作重新标记：修正并发标记期间用户进程运行而产生变化的标记，好事比初始标记长，但是远远小于并发标记
表发清除：清除标记的对象
缺点：
对CPU资源非常敏感，CPU少于4个时，CMS岁用户程序的影响可能变得很大，由此虚拟机提供了“增量式并发收集器”；无法回收浮动垃圾；采用标记清除算法会产生内存碎片，不过可以通过参数开启内存碎片的合并整理。
收集过程：
serial old
Serial Old收集器是Serial收集器的老年代版本，也是一个单线程收集器，不同的是采用"标记-整理算法"，运行过程和Serial收集器一样。
适用场景：
JDK1.5前与Parallel Scanvenge配合使用，作为CMS的后备预案。
收集过程：
Parallel old
Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和"标记-整理算法"进行垃圾回收，吞吐量优先。
回收算法：标记-整理
适用场景：
为了替代serial old与Parallel Scanvenge配合使用。
收集过程：
G1=Garbage first
从 JDK 9 开始，JVM 的默认垃圾回收器就从 Parallel GC 调整为 G1，并且开始全面废除 CMS 。
限制或者减少 GC 停顿时间相比系统吞吐量而言更加重要，从 PGC 切换至低延迟的 G1 能够为大部分用户带来更好的体验。G1 的性能在 JDK 8 以及后续的 release 版本都得到了极大的优化，G1 是一个具备所有 GC 特性的垃圾回收器，因此将 G1 设置为 JVM 默认的 GC。
根据 JEP-291 中的说明，为了减轻 GC 代码的维护负担以及加速新功能开发，决定在 JDK 9 中废弃 CMS GC。
从 Java 9 开始，如果您使用
-XX:+UseConcMarkSweepGC
（激活 CMS GC 算法的参数）参数启动应用程序，则会在下面显示警告消息：
Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
如果你想知道当前应用对应的 JVM 版本，你可以使用以下命令进行查询：
G1将整个JVM堆划分成多个大小相等的独立区域regin，跟踪各个regin里面的垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收最大的regin，当然还保留有新生代和老年代的概念，但新生代和老年代不在是物理隔离了，他们都是一部分regin集合。
内存“化整为零”的思路：在GC根节点的枚举范围汇总加入remembered set 即可保证不对全堆扫面也不会遗漏。
回收步骤：
初始标记：标记
GC Roots直接关联的对象并发标记：对堆中对象进行可达性分析，找出存活对象，耗时长，与用户进程并发工作
最终标记：修正并发标记期间用户进程继续运行而产生变化的标记
筛选回收：对各个
regin的回收价值进行排序，然后根据期望的GC停顿时间制定回收计划
G1收集器优势
并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间。部分收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续运行。
分代收集：G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
空间整合：G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。
可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。
收集过程：
G1的回收过程主要分为 3 类：
（1）G1“年轻代”的垃圾回收，同样叫 Minor G1，这个过程和我们前面描述的类似，发生时机就是 Eden 区满的时候。
（2）老年代的垃圾收集，严格上来说其实不算是收集，它是一个“并发标记”的过程，顺便清理了一点点对象。
（3）真正的清理，发生在“混合模式”，它不止清理年轻代，还会将老年代的一部分区域进行清理。
ZGC
ZGC（Z Garbage Collector）是一款由Oracle公司研发的，以低延迟为首要目标的一款垃圾收集器。它是基于动态Region内存布局，（暂时）不设年龄分代，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的收集器。
在JDK 11新加入，还在实验阶段，主要特点是：回收TB级内存（最大4T），停顿时间不超过10ms。
优点：低停顿，高吞吐量，ZGC收集过程中额外耗费的内存小
缺点：浮动垃圾
目前使用的非常少，真正普及还是需要写时间的。
垃圾收集器搭配关系
新生代收集器：Serial、ParNew、Parallel Scavenge
老年代收集器：CMS、Serial Old、Parallel Old
整堆收集器：G1，ZGC(因为不涉年代不在图中)
如何选择垃圾收集器？
前面我们已经介绍完八种垃圾收集器。那么我在真实场景中应该如何去选择呢，下面给出几种建议，希望对你有帮助：
如果你的堆大小不是很大（比如
100MB），选择串行收集器一般是效率最高的。参数：
-XX:+UseSerialGC。如果你的应用运行在单核的机器上，或者你的虚拟机核数只有单核，选择串行收集器依然是合适的，这时候启用一些并行收集器没有任何收益。
参数：
-XX:+UseSerialGC。如果你的应用是“吞吐量”优先的，并且对较长时间的停顿没有什么特别的要求。选择并行收集器是比较好的。
参数：
-XX:+UseParallelGC。如果你的应用对响应时间要求较高，想要较少的停顿。甚至 1 秒的停顿都会引起大量的请求失败，那么选择
G1、ZGC、CMS都是合理的。虽然这些收集器的 GC 停顿通常都比较短，但它需要一些额外的资源去处理这些工作，通常吞吐量会低一些。参数：
-XX:+UseConcMarkSweepGC、-XX:+UseG1GC、-XX:+UseZGC等。
从上面这些出发点来看，我们平常的 Web 服务器，都是对响应性要求非常高的。选择性其实就集中在 CMS、G1、ZGC上。而对于某些定时任务，使用并行收集器，是一个比较好的选择。
总结
回顾文章前面的目录
这几点你学会了吗？