目录

一、Serial收集器

二、ParNew收集器

三、Paralle Scavenge

四、Serial Old

五、Parallel Old

六、CMS收集器 

        6.1 CMS对处理器资源非常敏感

        6.2 CMS容易出现浮动垃圾

        6.3 产生内存碎片        

七、G1 收集器

八、如何选择合适的垃圾收集器

---

        JVM 垃圾收集器是Java虚拟机（JVM）中至关重要的组件，负责自动管理程序运行时产生的内存分配与回收。垃圾收集器通过检测并回收堆内存中不再使用的对象，从而保证了 Java 应用程序在持续运行过程中拥有足够的内存空间。

        如果说收集算法是内存回收的方法论，那垃圾收集器就是内存回收的实践者。各款经典的收集器之间的关系如下图，如果两个收集器之间存在连线，就说明他们可以搭配使用，收集器所处的区域，则表示它是属于新生代还是老年代。

一、Serial收集器

        Serial 收集器是最基础、历史最悠久的收集器，这个收集器是单线程工作的收集器，他的“单线程”意义并不仅仅是说明它只会是有一个处理器或一条收集器线程去完成垃圾收集工作，更重要的是强调它在垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。

        Serial 收集器依然是 HotSpot 虚拟机运行在客户端模式下的默认新生代收集器，有着优于其他收集器的地方，那就是简单而高效，对于内存资源受限的环境，他是所有收集器里额外内存消耗最小的。

        对于单核处理器或处理器核心数较少的环境来说，Serial 收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高单线程收集效率。近年来流行的微服务应用中，分配给虚拟机的内存一般来说并不大，收集十兆甚至几百兆的新生代，垃圾收集的停顿时间完全可以控制在十几、几十毫秒内，只要不是频繁发生收集，是可以接受的。

二、ParNew收集器

        ParNew 收集器实质上是 Serial 收集器多线程的并行版本，除了同时使用多线程进行垃圾收集外，其余的行为包括 Serial 收集器可用的所有控制参数都与 Serial 完全一致。

        ParNew 除了支持多线程并行收集外，其他与 Serial 收集器相比没有太多创新，除了 Serial收集器外，目前只有它能与 CMS 收集器配合工作。

        CMS 收集器是 HotSpot 虚拟机中第一款真正意义上支持并发的垃圾收集器，他首次实现了让垃圾收集线程和用户线程同时工作。

三、Paralle Scavenge

        Paralle Scavenge 收集器也是一款新生代收集器，它同样是基于标记-复制算法实现的收集器，也是能够并行收集的多线程收集器。

        Paralle Scavenge 收集器的特点是它的关注点与其他收集器不同，CMS 等收集器关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而 Paralle Scavenge 收集器的目标则是达到一个可控的吞吐量。所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值，即：

        Paralle Scavenge 提供了参数来用于精确控制吞吐量，被称为是吞吐量优先处理器。默认吞吐量的值为 99，即允许最大 1% 的垃圾回收时间。

四、Serial Old

        Serial Old 是 Serial 收集器老年代版本，他同样是一款单线程收集器，使用标记-整理算法。

五、Parallel Old

        Parallel Old 是 Parallel Scavenge 收集器的老年代版本，支持多线程并发收集，基于标记-整理算法。

六、CMS收集器 

        CMS（Concurrent Mark Sweep）收集器是一种以获取最短停顿时间为目标的收集器。从名字可以看出 CMS 是基于标记清除算法实现的。整个过程分为四个步骤：

1. 初始标记：初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快。
2. 并发标记：并发标记阶段就是从 GC Roots 的直接关联对象开始遍历整个对象的过程，这个过程耗时较长但不需要停顿用户线程，可以与垃圾收集线程一起并发运行。
3. 重新标记：是为了修正并发标记期间，因为用户继续运作而导致标记产生变动的那一部分对象的标记记录。
4. 并发清除：清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以整个阶段也是可以与用户线程同时并发。

        由于整个过程中耗时最长的并发标记与并发清除中，垃圾收集线程都可以与用户线程一起工作，所以从整体上看，CMS 收集器的内存回收过程与用户线程一起并发执行。

        但是 CMS 也有一些明显的缺点：

        6.1 CMS对处理器资源非常敏感

        事实上面向并发设计的程序都对处理器资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程而导致应用程序变慢，降低吞吐量。CMS 默认启动的回收线程数是（处理器核心数量 + 3）/ 4。也就是说如果处理器核心数在4个以上，并发回收时垃圾回收线程只占用不超过 25% 的处理器运算资源。但是如果处理器核心不足4个时，CMS对用户程序的影响就可能变得很大。如果应用的负载本来很高，还要分出一半的运算能力去执行垃圾回收，可能导致用户程序的执行速度大幅降低。为了缓解这种情况，虚拟机提出了“增量式并发收集器 i-CMS”，在并发标记、清理的时候让收集器线程、用户线程抢占式交替运行，尽量减少收集线程的独占资源时间，虽然垃圾收集时间会变成长，但对用户影响小一些。实践证明这种方式效果很一般，在jdk7开始，i-CMS标记为过时，不提倡使用。

        6.2 CMS容易出现浮动垃圾

        有可能出现“Concurrent Mode Dailure”失败而导致另一次完全“stop the word”的 Full GC 的产生。在 CMS 的并发标记和并发清理阶段，用户线程还在继续进行，程序在运行自然就还会伴随着垃圾对象的不断产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS 无法清理掉它们，之后等到下一次清理，这部分垃圾被称为浮动垃圾。

        同样也是由于在垃圾收集期间用户线程还需要持续运行，那就还需要预留足够内存空间提供给用户线程，因此 CMS 收集器不能像其他收集器那样，等待老年代几乎快被填满了在进行垃圾收集，必须预留一部分空间供并行收集时程序运行使用。在JDK5的默认配置下，CMS收集器老年代使用68%的空间后会被激活。到JDK6，提升到92%。

        6.3 产生内存碎片        

        基于标记清除算法实现，会产生大量内存碎片。往往会出现老年代还有很多空间，但就是无法找到连续空间分配给当前对象，而不得不提前触发一次 Full GC。

七、G1 收集器

        Garbage First 简称 G1 收集器，是一款主要面向服务端的垃圾收集器，最初赋予他的期望是未来可以替换掉 JDK5 中发布的 CMS 收集器。JDK9 发布之日，G1 宣告取代 Parrallel Scavenge和 Parrallel Old 组合，成为服务端模式下默认垃圾收集器。而 CMS 沦落为不被推荐使用的收集器。

        它开创了收集器面向局部收集的设计思路和基于 Region 的内存布局形式。在 G1 收集器出现之前的所有收集器，包括 CMS 在内，垃圾收集器的目标范围要么是整个新生代(Minor GC)，要么就是整个老年代(Major GC)，要么就是整个 Java 堆(Full GC)。而 G1 跳出了这个樊笼，它可以面向堆内存任何部分来组成回收集进行回收，衡量的标准不再是它属于哪个分代而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是 G1 收集器的 Mixed GC 模式。

        G1 不在坚持固定大小以及固定数量的分代区域划分，而是把连续的 Java 堆划分为多个大小相等的独立区域（Region），每个 Region 都可以根据需要，扮演新生代的 Eden 空间、Survior空间，或者老年代空间。收集器能够扮演不同角色的 Region 采用不同的策略去处理。Region 中还有一类 Hunongous 区域，专门用来存储大对象。G1 认为只有大小超过了一个 Region 容量一半的对象即可判定为大对象。每个 Region 的大小可以通过参数设定。

        虽然 G1 仍然保留新生代和老年代的概念，但新生代和老年代不再是固定的，他们都是一系列区域的动态集合。G1 之所以能够建立可预测的停顿时间模型，是因为它将 Region 作为最小的回收单元，即每次收集到的内存空间都是 Region 大小的整数倍。更具体的处理思路是让 G1 去跟踪各个 Region 里面垃圾堆积的“价值”大小，价值即回收所获得的空间大小以及回收所需的时间的经验值，然后在后台维护一个优先级列表，每次根据用户设定的停顿时间，优先处理回收价值最大的那些 Region，这也是 Garbage First 名字的由来。

        G1 主要划分为以下四个步骤：

1. 初始标记：仅仅只是标记一下 GC Roots 能直接关联到的对象
2. 并发标记：从 GC Roots 开始对堆中对象进行可达性分析，递归整个堆里的对象图，找出要回收的对象
3. 最终标记：对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的数据。
4. 筛选回收：负责更新 Region 的统计数据，对各个 Region 的回收价值和成本进行排序，根据用户所期望的停顿时间来指定回收计划。因为涉及到存活对象的移动，所以是必须要暂停用户线程的。

        G1 从整体看使用了标记-整理算法，避免了 CMS 标记清除产生的内存空间碎片，垃圾收集完成后能提供规整的可用内存。不过，G1 相比 CMS 也有缺点，G1 无论是为了垃圾收集产生的内存占用还是程序运行时额外执行负载都比 CMS 要高。

        就内存而言，虽然 G1 和 CMS 都使用卡表来处理跨代指针，但 G1 的卡表实现更为复杂，而且堆中每个 Region，无论扮演的是新生代还是老年代角色，都必须有一份卡表，这导致 G1 的记忆集占用更多的内存。

八、如何选择合适的垃圾收集器

        衡量垃圾收集器的三项重要指标是：内存占用、吞吐量和延迟。

        除了以上介绍的垃圾收集器，还有些比较新的垃圾收集器，如ZGC、Epsilon收集器，有十多种收集器，那么该如何选择呢？主要从这3点考虑：

• 应用程序的主要关注点是什么？如果是数据分析、科学计算类的任务，目标是能尽快算出结果，那吞吐量就是主要的关注点；如果是 SLA 应用，那停顿时间直接影响服务质量，严重的甚至导致事务超时，这样延迟就是主要关注点；而如果是客户端或者嵌入式应用，那垃圾收集的内存占用则是不可忽视的。
• 运行应用的基础设施如何？譬如硬件规格，要设计系统架构；处理器的数量是多少，分配内存大小；选择的操作系统是 Linux、Solaris 还是 Windows 等。
• 使用JDK的发行商是什么版本号是多少？

        选择垃圾收集器时，还需要进行基准测试和监控，以确定哪种收集器在实际运行环境中性能最佳。可以根据应用程序的实际内存分配和回收情况、CPU 利用率、响应时间和吞吐量指标等进行评估和调整。在生产环境中，还可以通过 JMX 或者其他监控工具实时监控垃圾收集器的表现，以便进行调优。

往期经典推荐

JVM 垃圾回收机制：探秘对象生死判定与高效回收算法-CSDN博客

JVM内存模型深度解读-CSDN博客

Spring循环依赖的成因与破局-CSDN博客

Spring Cloud + Nacos 引领服务治理新航向-CSDN博客

揭秘Redis中AOF与RDB的协同作战，确保数据万无一失-CSDN博客