不知不觉，JVM系列已经到回收算法的实现了。算法
本文主要内容服务器
先普及三个概念：多线程
并行收集：指多条垃圾收集线程并行工做，但此时用户线程仍处于等待状态。并发
并发收集：指用户线程与垃圾收集线程同时工做（不必定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另外一个CPU上。布局
吞吐量：即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )）。性能
例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%。优化
新生代
Serialspa
Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK1.3.1以前）是虚拟机新生代收集的惟一选择。线程
它是一种单线程收集器，不只仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工做，更重要的是其在进行垃圾收集的时候须要暂停其余线程。3d
优势：简单高效，拥有很高的单线程收集效率
缺点：收集过程须要暂停全部线程
算法：复制算法
应用：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上。而对于某些定时任务，使用并行收集器，是一个比较好的选择。
总结
回顾文章前面的目录
这几点你学会了吗？