【技术揭秘】一文读懂Java所有垃圾回收器，从入门到精通！

【技术揭秘】一文读懂Java所有垃圾回收器，从入门到精通！

内存溢出？频繁Full GC导致应用卡顿？本文通过生动对话形式，深入浅出地解析Java各代垃圾回收器的工作原理和区别，助你彻底掌握JVM垃圾回收机制！

目录

• 前言：为什么要了解垃圾回收器？
• 小明和老李的对话：垃圾回收基础知识
• 第一代垃圾回收器：Serial和ParNew
• 并行时代：Parallel Scavenge和Parallel Old
• 低延迟革命：CMS收集器
• 统一垃圾回收：G1收集器
• 新一代垃圾回收器：ZGC和Shenandoah
• 总结：如何选择合适的垃圾回收器

前言：为什么要了解垃圾回收器？

在Java开发中，内存管理是一个核心话题。与C/C++等需要手动管理内存的语言不同，Java通过垃圾回收（Garbage Collection，简称GC）机制自动管理内存，大大简化了开发人员的工作。但当应用出现性能问题时，了解并正确配置垃圾回收器就显得尤为重要。本文将通过对话形式，带你全面了解Java中的各种垃圾回收器。

小明和老李的对话：垃圾回收基础知识

小明：老李，最近我们的Java应用经常出现"Stop-the-world"暂停，用户体验很差。听说这跟垃圾回收有关，但我对Java垃圾回收知之甚少，能给我普及一下吗？

老李：没问题。首先，我们得了解JVM的内存模型。Java的堆内存主要分为年轻代（Young Generation）和老年代（Old Generation）。

小明：年轻代和老年代是什么意思？

老李：我来画个简图给你解释：

老李：简单来说，新创建的对象首先被分配在Eden区。当Eden区满了，就会触发Minor GC，将存活的对象复制到Survivor区。对象在Survivor区域之间复制，当达到一定年龄（默认为15）后，就会被晋升到老年代。

小明：那为什么会有"Stop-the-world"暂停呢？

老李：垃圾回收器在回收垃圾时，通常需要暂停应用线程，这就是所谓的"Stop-the-world"（STW）。暂停时间长短取决于垃圾回收器的类型和堆内存大小。

小明：原来如此。那Java中有哪些垃圾回收器呢？

老李：Java垃圾回收器经历了多代演进，从最早的Serial收集器，到现在的ZGC和Shenandoah，每一代都有不同的特点和适用场景。我们可以从时间线上来看：

timeline
    title Java垃圾回收器演进历程
    section 第一代
        Serial/Serial Old : 单线程收集器
        ParNew : Serial的多线程版本
    section 并行时代
        Parallel Scavenge : 高吞吐量收集器
        Parallel Old : 老年代并行收集器
    section 并发时代
        CMS : 并发标记清除收集器
        G1 : 区域化分代收集器
    section 新一代
        ZGC : 低延迟可伸缩收集器
        Shenandoah : 低延迟并发收集器

小明：哇，这么多！让我们一个一个地了解它们吧。

第一代垃圾回收器：Serial和ParNew

老李：最早的垃圾回收器是Serial收集器，它是一个单线程收集器，工作时必须暂停所有应用线程。

小明：单线程？那在多核CPU环境下不是很浪费资源吗？

老李：是的，所以后来有了ParNew收集器，它是Serial收集器的多线程版本，可以充分利用多核CPU的优势。来看看它们的工作流程：

小明：我明白了，ParNew就是多线程版的Serial收集器。那它们主要应用在年轻代还是老年代？

老李：Serial和ParNew主要用于年轻代，而它们对应的老年代收集器是Serial Old。

小明：这些收集器现在还有人用吗？

老李：在资源受限的环境（如嵌入式设备）或客户端应用中，Serial收集器仍然是一个不错的选择。对于服务器应用，ParNew常与CMS收集器搭配使用。

并行时代：Parallel Scavenge和Parallel Old

小明：刚才提到的ParNew已经是多线程的了，那Parallel Scavenge又是什么？

老李：虽然ParNew和Parallel Scavenge都是并行收集器，但它们的关注点不同。ParNew是为了配合CMS收集器而设计的，而Parallel Scavenge的目标是达到一个可控的吞吐量。

小明：吞吐量是什么意思？

老李：吞吐量指的是CPU用于运行用户代码的时间与CPU总消耗时间的比值。例如，程序运行100分钟，垃圾收集花了1分钟，吞吐量就是99%。

小明：那Parallel Old呢？

老李：Parallel Old是Parallel Scavenge的老年代版本，也是一个并行收集器。Parallel Scavenge + Parallel Old的组合在注重吞吐量的场景下非常有用，比如批处理、科学计算等。

小明：这两个收集器是怎么工作的？

老李：它们的工作原理如下：

小明：这个过程中应用还是会暂停的，对吧？

老李：是的，Parallel系列收集器在垃圾收集过程中仍然会暂停应用线程。它们的优势是高吞吐量，缺点是可能产生较长的停顿时间。

低延迟革命：CMS收集器

小明：刚才说到的收集器在GC时都会导致应用暂停。有没有能降低暂停时间的收集器？

老李：这就是CMS（Concurrent Mark Sweep）收集器的设计目标。CMS收集器是一种以获取最短回收停顿时间为目标的收集器，适合对响应时间有高要求的应用。

小明：CMS是怎么降低暂停时间的？

老李：CMS通过将大部分垃圾收集工作与应用线程并发执行来减少停顿时间。它的工作流程如下：

老李：CMS只有"初始标记"和"重新标记"两个阶段需要暂停应用，其余阶段与应用并发执行。

小明：听起来CMS很好啊，有什么缺点吗？

老李：CMS有几个显著的缺点：

1. 对CPU资源非常敏感，因为它与应用并发执行，会抢占应用线程的CPU资源
2. 无法处理"浮动垃圾"，可能导致并发失败
3. 使用"标记-清除"算法，会产生大量空间碎片

小明：什么是"浮动垃圾"？

老李：浮动垃圾是指并发标记阶段结束后，应用程序在运行过程中新产生的垃圾，这部分垃圾出现在标记过程结束后，所以无法在当次收集中处理掉。

小明：空间碎片会有什么影响？

老李：空间碎片过多会导致大对象无法分配足够的连续内存空间，从而提前触发Full GC。

统一垃圾回收：G1收集器

小明：听说现在的默认垃圾回收器是G1，它有什么特别之处？

老李：G1（Garbage-First）收集器是一款面向服务端应用的垃圾收集器，它的设计目标是取代CMS收集器。G1的特点是将堆内存划分为多个大小相等的独立区域（Region），不再严格区分年轻代和老年代。

小明：这种设计有什么好处？

老李：这种设计使G1能够对堆内存进行灵活的管理。看这个图：

老李：G1收集器的回收过程分为以下几个阶段：

小明：G1是怎么决定先回收哪些区域的？

老李：G1会优先回收价值最大的Region，所谓价值最大，就是指回收所获得的空间大小以及回收所需时间的经济效益最大化。这也是"Garbage-First"名称的由来。

小明：G1有什么优势？

老李：G1的主要优势包括：

1. 可预测的停顿时间模型
2. 避免了全堆扫描
3. 基于Region的内存布局更灵活
4. 空间整合能力强，降低了碎片产生的可能性

新一代垃圾回收器：ZGC和Shenandoah

小明：除了G1，听说还有更新的垃圾回收器ZGC和Shenandoah？

老李：是的，这两款收集器是目前最先进的垃圾收集器，主要目标都是超低延迟。

小明：它们是怎么做到超低延迟的？

老李：ZGC和Shenandoah都采用了"读屏障"技术，可以在垃圾回收的同时移动对象，实现了真正的并发移动。这意味着它们的STW暂停时间极短，通常在10ms以下，甚至可以达到1ms以内。

小明：它们之间有什么区别？

老李：ZGC是由Oracle开发的，而Shenandoah是由Red Hat开发的。它们的实现细节有所不同，但目标都是相似的。我们来看一下ZGC的工作流程：

小明：这两个收集器现在可以在生产环境中使用吗？

老李：ZGC在JDK 11中被引入为实验性特性，并在JDK 15中正式发布。Shenandoah在JDK 12中被引入，并在JDK 15中正式发布。它们都已经可以在生产环境中使用，特别是对延迟敏感的应用。

小明：它们是怎么做到并发移动对象的？这不会影响到应用线程对对象的访问吗？

老李：这是通过所谓的"着色指针"（Colored Pointers）技术实现的。ZGC利用64位指针中的一些未使用的比特位来存储对象的状态信息。当对象被移动时，应用线程通过指针访问对象会被读屏障拦截，并被引导到对象的新位置。

小明：听起来很神奇！那它们有什么局限性吗？

老李：ZGC和Shenandoah的主要局限性在于：

1. 额外的CPU开销
2. 目前主要针对64位系统优化
3. 与某些JIT优化可能存在冲突
4. 相对较新，在极端场景下的稳定性还在验证中

总结：如何选择合适的垃圾回收器

小明：了解了这么多垃圾回收器，我该如何为我的应用选择合适的垃圾回收器呢？

老李：选择垃圾回收器需要考虑以下几个因素：

1. 应用的特性（响应时间敏感 vs 吞吐量敏感）
2. 堆内存大小
3. CPU资源
4. 可接受的停顿时间

我给你准备了一个简单的选择指南：

老李：简单来说：

• 如果你的应用注重吞吐量而不是响应时间，选择Parallel GC
• 如果你的应用对响应时间有要求，但堆内存较小，选择G1
• 如果你的应用对响应时间非常敏感，并且使用JDK 11以上版本，可以尝试ZGC或Shenandoah
• 如果你使用的是老版本JDK，并且关注响应时间，可以使用CMS或G1

小明：那在实际使用中，我该如何指定垃圾回收器？

老李：你可以通过JVM参数来指定垃圾回收器，例如：

# 使用G1收集器
java -XX:+UseG1GC YourApplication

# 使用ZGC收集器
java -XX:+UseZGC YourApplication

# 使用Shenandoah收集器
java -XX:+UseShenandoahGC YourApplication

# 使用Parallel收集器
java -XX:+UseParallelGC YourApplication

小明：有没有办法监控垃圾回收的情况？

老李：当然有，你可以使用以下参数开启GC日志：

# JDK 9之前
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log

# JDK 9及以后
-Xlog:gc*:file=gc.log:time,uptime,level,tags

然后可以使用GCViewer等工具分析GC日志。另外，你还可以使用JVisualVM、Java Mission Control等工具进行实时监控。

小明：了解了，感谢老李的详细解答！我对Java垃圾回收器有了全面的认识。

老李：不客气！记住，选择垃圾回收器没有一劳永逸的方案，需要根据应用特点和实际测试结果来调整。有问题随时问我！

---

本文内容基于JDK 17版本，涵盖了Java主流垃圾回收器的工作原理和选择依据。如果您在实际应用中遇到GC相关问题，欢迎在评论区留言讨论。