垃圾收集器你知道多少？

完整文章在下面，取自大佬JavaGuide

• 标记-清除算法

  • 标记-清除（Mark-and-Sweep）算法分为“标记（Mark）”和“清除（Sweep）”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。
    •  它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会带来两个明显的问题：
      • 效率问题：标记和清除两个过程效率都不高。
      • 空间问题：标记清除后会产生大量不连续的内存碎片。

• 复制算法

  • 为了解决标记-清除算法的效率和内存碎片问题，复制（Copying）收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。
    •  虽然改进了标记-清除算法，但依然存在下面这些问题：
      • 可用内存变小：可用内存缩小为原来的一半。
      • 不适合老年代：如果存活对象数量比较大，复制性能会变得很差。

• 标记-整理算法

  • 标记-整理（Mark-and-Compact）算法是根据老年代的特点提出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。
    • 由于多了整理这一步，因此效率也不高，适合老年代这种垃圾回收频率不是很高的场景。

• 分代收集算法

  • 当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 Java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
  • 比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记-复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

• Serial 收集器

  • Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ "Stop The World" ），直到它收集结束。
  • 新生代采用标记-复制算法，老年代采用标记-整理算法。

• ParNew 收集器

  • ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。
  • 新生代采用标记-复制算法，老年代采用标记-整理算法。
  • 并行和并发概念补充：
    • 并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
    • 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行，可能会交替执行），用户程序在继续运行，而垃圾收集器运行在另一个 CPU 上。

• Parallel Scavenge 收集器 （JDK8 默认收集器）

  • Parallel Scavenge 收集器也是使用标记-复制算法的多线程收集器
  • Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。 Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解，手工优化存在困难的时候，使用 Parallel Scavenge 收集器配合自适应调节策略，把内存管理优化交给虚拟机去完成也是一个不错的选择。
  • 新生代采用标记-复制算法，老年代采用标记-整理算法。

• Serial Old 收集器

  • Serial 收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。

• ParNew Old 收集器

  • Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。

• CMS 收集器

  • CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。
  • CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
  • 从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：
    • 对 CPU 资源敏感；
    • 无法处理浮动垃圾；
    • 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。

    从 JDK9 开始，CMS 收集器已被弃用。

• G1 收集器 （JDK9——JDK20 默认收集器）

  • G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征.
  • 从 JDK9 开始，G1 垃圾收集器成为了默认的垃圾收集器。

• ZGC 收集器 （JDK21 默认收集器）

  • 与 CMS 中的 ParNew 和 G1 类似，ZGC 也采用标记-复制算法，不过 ZGC 对该算法做了重大改进。
  • ZGC 可以将暂停时间控制在几毫秒以内，且暂停时间不受堆内存大小的影响，出现 Stop The World 的情况会更少，但代价是牺牲了一些吞吐量。ZGC 最大支持 16TB 的堆内存。
  • ZGC 在 Java11 中引入，处于试验阶段。经过多个版本的迭代，不断的完善和修复问题，ZGC 在 Java15 已经可以正式使用了。
  • 在 Java21 中，引入了分代 ZGC，暂停时间可以缩短到1毫秒以内。

让我们来总结一下：

• 在JDK8（基本上这已经是最低版本了）中，默认的垃圾收集器是Parallel Scavenge（新生代）+ Parallel Old（老年代）
• 在JDK9——JDK20中，默认垃圾收集器是G1 收集器
• 在JDK21中，默认垃圾收集器是ZGC 收集器