Java中的垃圾回收机制（GC）研究！

原创已于 2025-08-04 09:16:38 修改 · 780 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#java #开发语言

于 2025-08-04 09:16:30 首次发布

Java从入门到放弃专栏收录该内容

119 篇文章

订阅专栏

👋 你好，欢迎来到我的博客！我是【菜鸟不学编程】
我是一个正在奋斗中的职场码农，步入职场多年，正在从“小码农”慢慢成长为有深度、有思考的技术人。在这条不断进阶的路上，我决定记录下自己的学习与成长过程，也希望通过博客结识更多志同道合的朋友。

🛠️ 主要方向包括 Java 基础、Spring 全家桶、数据库优化、项目实战等，也会分享一些踩坑经历与面试复盘，希望能为还在迷茫中的你提供一些参考。
💡 我相信：写作是一种思考的过程，分享是一种进步的方式。

如果你和我一样热爱技术、热爱成长，欢迎关注我，一起交流进步！

前言

在 Java 开发中，垃圾回收（Garbage Collection, GC）是 JVM 管理内存的重要机制。GC 通过自动回收不再使用的对象，避免了开发者手动管理内存的复杂性。然而，GC 也可能会影响程序的性能，特别是在高并发和低延迟的应用中。为了更好地理解 GC 的运作方式、调优和优化垃圾回收，本文将探讨 JVM 内存模型、各种 GC 算法、GC 日志分析与调优工具、Stop-the-world 问题及其解决方案，最后给出一个性能调优案例实战。

JVM内存模型回顾

在深入研究 Java 的垃圾回收机制前，我们首先回顾一下 JVM 内存模型的基本结构。JVM 内存模型分为几个不同的区域，它们分别负责不同的内存管理任务：

堆内存（Heap）：用于存储对象实例，是垃圾回收的主要区域。堆内存被划分为不同的区域，如年轻代（Young Generation）、老年代（Old Generation）和持久代（PermGen/Metaspace）。
栈内存（Stack）：每个线程都有自己的栈，用于存储局部变量和方法调用信息。栈内存中的数据不会被 GC 管理。
方法区（Method Area）：存储类的信息、常量、静态变量等。JVM 在 JDK 8 后将 PermGen 区域替换为 Metaspace。
程序计数器（Program Counter）：每个线程都有一个程序计数器，存储当前线程执行的字节码的地址。

其中，堆内存 是垃圾回收机制最为关注的区域，JVM 中的垃圾回收算法大多针对堆内存中的对象进行回收。

各种GC算法（Serial、CMS、G1、ZGC）

在 JVM 中，不同的垃圾回收算法适用于不同的场景。下面我们详细介绍几种常见的垃圾回收算法。

1. Serial GC

Serial GC 是最简单的垃圾回收算法，它采用单线程进行垃圾回收，适用于内存较小且没有并发需求的应用。

特点：
- 使用单线程进行所有的垃圾回收工作。
- 对所有的垃圾回收操作（包括年轻代和老年代）都采用串行方式。
- 在进行 GC 时，会暂停所有应用线程（即 Stop-the-world）。
适用场景：适用于内存小、CPU 性能不高的单线程应用。通常在客户端应用或嵌入式系统中使用。

2. CMS（Concurrent Mark-Sweep）GC

CMS GC 是一种低延迟的垃圾回收算法，旨在减少 Stop-the-world 事件的时间。它通过并发标记和清除垃圾，尽量避免停顿时间过长。

特点：
- 使用多线程进行标记和清除工作。
- 标记阶段与应用程序线程并发执行，减少停顿时间。
- 但是，CMS 并不保证完全消除停顿时间，且有可能发生 Full GC。
适用场景：适用于对响应时间要求较高的服务器应用，尤其是对于低延迟和较高吞吐量的应用。

3. G1（Garbage First）GC

G1 GC 是为多核处理器和大堆内存设计的垃圾回收算法，它将堆划分为多个区域，通过并行和增量回收来优化垃圾回收的效率。G1 GC 提供了较好的可预测性，适合处理大规模数据的系统。

特点：
- 分代式回收：堆被划分为多个区域，G1 GC 选择回收那些垃圾最多的区域。
- 在增量式回收过程中，G1 GC 尽量避免全堆回收，降低 Stop-the-world 事件的影响。
- 提供了较为细致的回收调优。
适用场景：适用于大内存、高并发的应用，特别是在需要较长时间运行的服务中。

4. ZGC（Z Garbage Collector）

ZGC 是一种低延迟的垃圾回收器，设计目标是减少 GC 停顿时间，即使在大内存的情况下也能够保持低延迟。ZGC 采用了并行回收的方式，支持大规模的内存管理，最大支持的堆内存可以达到数百 GB。

特点：
- 低延迟：ZGC 旨在将 GC 停顿时间控制在 10ms 以内。
- 并行回收：采用并行标记、并行清除的方式，且不需要对应用程序线程进行大量的 Stop-the-world。
- 不适合吞吐量要求高的场景，但对延迟非常敏感的场景效果好。
适用场景：适用于需要极低延迟、高并发的大型数据处理应用。

GC日志分析与调优工具（jstat、jmap、VisualVM）

为了优化垃圾回收，开发者需要使用合适的工具对 GC 日志进行分析，从而识别潜在的性能瓶颈。下面介绍几种常用的 GC 日志分析和调优工具。

1. jstat（JVM Statistics Monitoring Tool）

jstat 是一个命令行工具，用于监控 JVM 的运行状态，包括垃圾回收的统计信息。它可以帮助我们分析垃圾回收的各项指标，如每次 GC 的时间、回收的内存量等。

# 查看 GC 统计信息
jstat -gcutil <pid> 1000

-gcutil：显示各个内存区域的 GC 使用情况。
pid：JVM 进程的进程 ID。
1000：每隔 1000 毫秒输出一次。

2. jmap（Memory Map）

jmap 是另一个常用的工具，用于生成堆内存的快照，并分析内存的分配情况。它常用于生成堆转储文件，以便在后续的分析中使用。

# 生成堆的转储文件
jmap -dump:format=b,file=heapdump.hprof <pid>

通过分析生成的 .hprof 文件，开发者可以了解堆内存的使用情况和潜在的内存泄漏问题。

3. VisualVM

VisualVM 是一个图形化的监控工具，能够实时监控 JVM 的性能，并提供内存、线程和 CPU 的详细统计信息。它可以与多个 JVM 实例连接，支持堆转储分析、垃圾回收统计、线程分析等。

通过 VisualVM，开发者可以查看不同垃圾回收器的运行效果、内存使用情况，并进行性能调优。

Stop-the-world 问题与解决方案

Stop-the-world 是指在进行垃圾回收时，JVM 会暂停所有应用线程，以便完成内存的清理和回收。这会导致应用响应时间的延迟，影响系统性能，尤其是在高并发和低延迟的应用中。

解决方案

使用低延迟的垃圾回收器：例如 ZGC 和 G1 GC，这些回收器通过并行回收、增量回收等方式，减少了 Stop-the-world 时间。
减少 Full GC 的发生：通过合理调节堆内存的大小、优化内存分配，尽量避免发生 Full GC，因为 Full GC 会导致较长时间的 Stop-the-world。
调整垃圾回收参数：根据应用的特点和需求，合理调整 JVM 的垃圾回收参数，如调整新生代和老年代的比例、设置 GC 暂停的时间阈值等。

性能调优案例实战

假设我们有一个 Web 应用，运行在生产环境中，发现该应用的响应时间较长，且 GC 停顿时间较高。通过以下步骤进行调优：

步骤 1: GC 日志分析

我们使用 jstat 和 VisualVM 分析应用的垃圾回收日志，发现频繁发生 Full GC，且每次 Full GC 的停顿时间较长。

步骤 2: 调整垃圾回收器

根据分析结果，我们发现应用的内存较大且对响应时间要求较高，因此我们决定将垃圾回收器从默认的 Parallel GC 调整为 G1 GC，以减少 GC 停顿时间。

# 设置 G1 GC
-Xmx4g -Xms4g -XX:+UseG1GC

步骤 3: 调整堆内存配置

通过进一步分析，我们发现 JVM 堆内存配置过小，导致频繁的垃圾回收。于是我们增大了堆内存大小，同时调整了年轻代和老年代的大小比例。

# 设置堆内存和新生代比例
-Xmx8g -Xms8g -XX:NewRatio=3

步骤 4: 使用 ZGC

在需要极低延迟的场景下，我们最终将垃圾回收器切换为 ZGC，通过它来进一步减少停顿时间，并保证低延迟。

# 设置 ZGC
-Xmx8g -Xms8g -XX:+UseZGC

通过这些步骤，我们成功减少了 GC 停顿时间，提升了系统的响应性能。

总结

Java 的垃圾回收机制是 JVM 中的关键组件，它通过自动管理内存，避免了开发者手动管理内存的复杂性。理解和掌握不同的垃圾回收算法，如 Serial、CMS、G1 和 ZGC，能够帮助开发者根据应用的实际需求选择合适的算法，提高应用的性能。通过 GC 日志分析工具、性能调优工具以及合理的参数配置，开发者可以有效识别和优化垃圾回收过程中的性能瓶颈，确保系统高效运行。在高性能应用中，解决 Stop-the-world 问题、优化 GC 停顿时间是至关重要的。通过本文的分析，您应该能够掌握 MyBatis 的 GC 工作原理，并有效地进行调优。