代码如诗，你我皆为诗人。大家好，我是水哥，一个在软件开发领域深耕多年的资深工程师。

今天水哥想聊聊 JVM 的垃圾收集器（Garbage Collector，GC）。

如果大家有写 C 或者 C++ 的经验的话，就知道内存的分配和释放都是要靠开发自己写代码去管理的。万一忘记把内存释放回去，就容易出现内存泄漏的问题。Java 提供了一种方便的内存管理方式，使得开发者可以更加专注于业务逻辑的实现，而不必过多关注内存管理的细节。这就是今天的主角——JVM 的垃圾收集器。

垃圾收集器定期扫描堆内存中的对象，找出不再被引用的对象，并释放其占用的内存空间。垃圾收集器的目标是尽可能减少程序中的内存泄漏问题，提高程序的性能和稳定性。

JVM 规范没有规定 GC 的具体算法和实现细节，而是要靠具体的 JVM 的实现者去实现。目前最被广泛使用的 JVM 应该就是 HotSpot VM 了，它也是 OpenJDK 和 Oracle JDK 的 JVM 实现。

HotSpot VM 提供了以下几种不同的 GC 实现：

• Serial Collector（串行收集器）

• Parallel Collector（并行收集器）

• Garbage-First (G1) Garbage Collector

• The Z Garbage Collector

下面分别简单介绍一下这四种收集器：

串行收集器

使用单个线程执行所有垃圾收集工作，因此相对高效，没有线程间通信开销。

适合单处理器机器，尽管在多处理器硬件上不能充分利用硬件优势，但对于数据集较小（约100MB）的应用程序仍然有用。

可通过 -XX:+UseSerialGC 启用。

并行收集器

也称为吞吐量收集器，是一种代际收集器，与串行收集器类似。

主要区别在于并行收集器使用多个线程加速垃圾收集。

适用于在多处理器或多线程硬件上运行的中等至大型数据集的应用程序。

可通过 -XX:+UseParallelGC 启用。

Garbage-First（G1）Garbage Collector

主要是一个并发收集器，执行一些与应用程序并发进行的昂贵工作。

设计用于从小机器扩展到具有大量内存的大型多处理器机器。

提供以高概率满足暂停时间目标的能力，同时实现高吞吐量。

可通过 -XX:+UseG1GC 启用。

Z Garbage Collector（ZGC）

提供毫秒级的最长暂停时间，但会牺牲一些吞吐量。

适用于需要低延迟的应用程序，暂停时间与使用的堆大小无关。

适用于从几百兆到16TB的堆大小。

通过 -XX:+UseZGC 和 -XX:+ZGenerational 启用。

举个生活中的例子解释下这四种 GC 的区别

我们办公室会有清洁工帮忙清理垃圾桶里的垃圾，就像 Full GC 一样。

串行收集器就好像只有一个清洁工，她工作的时候我们都得停下来，等她收拾完了之后才能继续敲 bug。

并行收集器就好像是多个清洁工同时干活，但是他们工作的时候我们还是要停下来等。

G1 和 ZGC 也是多个清洁工同时干活，但是在她们工作的时候，我们可以继续疯狂输出 bug。虽然偶尔会被打断一下下，但不用长时间停下来等她做完所有事情。

既然这四种 GC 各有特色，我们该如何选择呢？

如果应用程序没有严格的暂停时间要求，首先运行应用程序并允许虚拟机选择收集器。

如果性能仍不符合目标，根据以下指南作为选择收集器的起点：

• 小数据集（约100MB）：使用串行收集器 -XX:+UseSerialGC。

• 单处理器且无暂停时间要求：使用串行收集器 -XX:+UseSerialGC。

• 峰值性能优先且无暂停时间要求或可接受一秒以上暂停：让虚拟机选择收集器或使用并行收集器 -XX:+UseParallelGC。

• 响应时间比吞吐量更重要且必须保持较短的垃圾收集暂停：使用大多数并发收集器 -XX:+UseG1GC。

• 响应时间是高优先级：使用完全并发收集器 -XX:UseZGC -XX:+ZGenerational。

今天简单介绍了几种垃圾收集器的特点和适用场景。每种收集器有自己的工作原理和调优方法，今天篇幅有限未能细讲，下次让我们逐个击破，敬请期待~

参考资料：

https://docs.oracle.com/en/java/javase/21/gctuning/available-collectors.html

如果您在技术探索的旅途中偶遇了这篇文章，水哥感到十分荣幸。感谢您抽出宝贵时间阅读至此。

若您觉得有所收获，不妨点赞、分享，让更多人一同受益。您的支持是我前进的动力。

想了解精粹的软件开发技术、前沿的云计算实践、高效的敏捷管理策略，敬请关注我的公众号（码农水哥：manongshuige），一起探索技术深度，享受敏捷之美。