NFC宣传册数字化实战：基于ST25系列从标签选型到数据追踪
2026/8/29 1:39:12
1. 引言
Full GC（Full Garbage Collection，全量垃圾回收）是 JVM 垃圾回收中最令人头疼的话题之一。在 Java 应用运行过程中，Full GC 一旦频繁发生，往往伴随着明显的停顿（Stop-The-World，STW）、CPU 飙升、接口超时等问题，严重时甚至会导致线上事故。
本文将从 Full GC 的基本概念入手，逐步深入其触发机制、常见原因，并给出系统化的排查思路与实战方案，帮助你在遇到 Full GC 问题时能够快速定位、从容应对。
2. 什么是 Full GC
2.1 垃圾回收的基本概念
JVM 的内存被划分为多个区域，其中堆内存（Heap）是垃圾回收的主要战场。堆内存又细分为：
- 新生代（Young Generation）：存放新创建的对象，进一步分为 Eden 区和两个 Survivor 区（S0、S1）。
- 老年代（Old Generation）：存放存活时间较长的对象，或从新生代晋升过来的大对象。
垃圾回收器会定期扫描堆内存，回收不再被引用的对象，释放内存空间。
2.2 Full GC 的定义
Full GC 是指对整个堆内存（新生代 + 老年代 + 元空间/Metaspace）进行的一次完整垃圾回收。与 Minor GC（只回收新生代）和 Major GC（只回收老年代）不同，Full GC 涉及范围最广，耗时也最长。
2.3 Full GC 与 Minor GC 的区别
| 对比项 | Minor GC | Full GC |
|---|---|---|
| 回收范围 | 仅新生代 | 整个堆（新生代 + 老年代 + 元空间） |
| 触发频率 | 高 | 低 |
| 停顿时间 | 短（毫秒级） | 长（秒级甚至分钟级） |
| 对业务影响 | 较小 | 极大，可能导致接口超时 |
2.4 Full GC 的停顿（STW）
Full GC 期间，JVM 会暂停所有应用线程，进入 Stop-The-World 状态。这意味着在这段时间内，业务请求无法被处理，所有线程都处于阻塞状态。停顿时间的长短取决于堆内存的大小、存活对象的数量以及所使用的垃圾回收器。
3. Full GC 的触发机制
了解 Full GC 的触发条件，是排查问题的第一步。以下是 Full GC 常见的触发场景：
3.1 老年代空间不足
这是最常见的触发原因。当老年代被占满，无法容纳新晋升的对象时，JVM 会触发 Full GC。具体场景包括：
- 大对象直接进入老年代，导致老年代空间快速耗尽。
- 长期存活的对象过多，新生代晋升频繁。
- 内存泄漏导致老年代对象只增不减。
3.2 元空间（Metaspace）不足
JDK 8 之后，方法区被元空间取代。当加载的类过多、动态生成代理类过多时，元空间可能被占满，从而触发 Full GC。
3.3 晋升失败（Promotion Failure）
当新生代进行 Minor GC 时，如果存活对象无法放入 Survivor 区，需要晋升到老年代，但此时老年代空间不足，就会发生晋升失败，进而触发 Full GC。
3.4 大对象直接分配
当创建的对象大小超过-XX:PretenureSizeThreshold阈值时，对象会直接进入老年代。如果短时间内大量创建大对象，老年代空间会迅速耗尽，触发 Full GC。
3.5 显式调用 System.gc()
代码中显式调用System.gc()会触发 Full GC（尽管只是建议，但大多数垃圾回收器都会响应）。一些框架（如 RMI、NIO）在特定场景下也会触发显式 GC。
3.6 CMS 并发模式失败
使用 CMS 垃圾回收器时，如果并发回收期间老年代被占满，会触发 Concurrent Mode Failure，退化为 Serial Old 进行 Full GC。
4. Full GC 的常见原因分析
4.1 内存泄漏
内存泄漏是 Full GC 频繁发生的头号元凶。对象被无意中持有引用，无法被回收，导致老年代持续增长。常见的内存泄漏场景包括：
- 静态集合类持有对象引用，未及时清理。
- 连接（数据库、HTTP、Redis）未关闭。
- 监听器、回调未注销。
- ThreadLocal 使用不当导致内存泄漏。
4.2 对象分配速率过高
如果应用在短时间内大量创建对象，新生代频繁触发 Minor GC，存活对象不断晋升到老年代，最终导致老年代空间不足，触发 Full GC。
4.3 堆内存配置不合理
- 堆内存设置过小，无法满足应用的实际需求。
- 新生代与老年代比例不当，导致对象过早晋升。
- 大对象阈值设置不合理。
4.4 元空间配置不足
动态生成大量类（如 CGLIB 代理、反射、热部署）时，如果元空间上限设置过小，会频繁触发 Full GC。
4.5 代码中显式调用 System.gc()
某些第三方框架或业务代码中调用了System.gc()，导致 Full GC 频繁发生。
5. Full GC 的排查方案
5.1 排查前的准备工作
在开始排查之前，需要确保以下几点：
- 开启 GC 日志：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log - 开启堆转储：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof - 监控 CPU、内存、磁盘 IO 等系统指标。
5.2 查看 GC 日志
GC 日志是排查 Full GC 的第一手资料。通过分析 GC 日志，可以了解：
- Full GC 发生的频率和时间点。
- Full GC 前后的堆内存使用情况。
- Full GC 的停顿时间。
# 查看 GC 日志中 Full GC 的记录grep"Full GC"gc.log|head-205.3 使用 jstat 实时监控
jstat是 JDK 自带的监控工具，可以实时查看 JVM 的内存使用和 GC 情况。
# 每 1 秒输出一次 GC 统计信息，共输出 10 次jstat-gcutil<pid>100010重点关注FGC（Full GC 次数）和FGCT（Full GC 累计耗时）两列。
5.4 使用 jmap 分析堆内存
当怀疑内存泄漏时，可以使用jmap生成堆转储文件，再用 MAT（Memory Analyzer Tool）或 VisualVM 分析。
# 生成堆转储文件jmap-dump:format=b,file=heap.hprof<pid>5.5 使用 jvisualvm 可视化分析
jvisualvm是 JDK 自带的图形化监控工具，可以直观地查看堆内存使用趋势、GC 情况以及线程状态。
5.6 使用 Arthas 在线诊断
Arthas 是阿里巴巴开源的 Java 诊断工具，可以在不重启应用的情况下进行在线诊断。
# 查看 GC 情况dashboard# 查看类加载情况classloader# 查看内存使用memory5.7 排查步骤总结
- 确认 Full GC 频率：通过 GC 日志或 jstat 确认 Full GC 发生的频率和规律。
- 分析 GC 日志：查看 Full GC 前后的内存变化，判断是哪个区域空间不足。
- 定位内存增长点：使用 jmap 生成堆转储，用 MAT 分析大对象和引用链。
- 检查代码：排查内存泄漏、大对象创建、System.gc() 调用等问题。
- 调整 JVM 参数：根据分析结果调整堆大小、GC 策略等参数。
- 验证效果：调整后持续观察，确认 Full GC 频率恢复正常。
6. 实战案例
6.1 案例一：内存泄漏导致 Full GC 频繁
现象：某订单系统每天下午 Full GC 频繁，接口响应变慢。
排查过程：
- 查看 GC 日志，发现 Full GC 频率从每小时 1 次增加到每 10 分钟 1 次。
- 使用
jmap生成堆转储，用 MAT 分析，发现HashMap中持有大量订单对象引用。 - 定位到代码，发现一个静态缓存 Map 在订单完成后未移除订单对象。
解决方案：在订单完成后主动从缓存中移除对象，并使用弱引用替代强引用。
6.2 案例二：大对象导致老年代空间不足
现象：某报表系统每次生成报表时都会触发 Full GC。
排查过程：
- 通过 GC 日志发现，Full GC 发生在报表生成期间。
- 使用 Arthas 的
memory命令，发现老年代空间在报表生成时迅速增长。 - 定位到代码，发现报表数据一次性加载到内存中，生成了大量大对象。
解决方案：将报表数据改为分批加载，并调大-XX:PretenureSizeThreshold阈值，避免大对象直接进入老年代。
7. JVM 参数调优建议
7.1 堆内存设置
# 设置堆内存大小-Xms4g-Xmx4g# 设置新生代大小-Xmn2g# 设置新生代与老年代比例-XX:NewRatio=27.2 垃圾回收器选择
# JDK 8 使用 G1-XX:+UseG1GC# JDK 11+ 使用 ZGC-XX:+UseZGC7.3 其他常用参数
# 设置大对象直接进入老年代的阈值-XX:PretenureSizeThreshold=1m# 设置元空间大小-XX:MetaspaceSize=256m-XX:MaxMetaspaceSize=512m# 禁用显式 GC-XX:+DisableExplicitGC8. 总结
Full GC 是 Java 应用运行中不可避免的现象，但频繁的 Full GC 往往意味着代码或配置存在问题。排查 Full GC 的核心思路是：
- 先看日志：通过 GC 日志确认 Full GC 的频率和内存变化。
- 再抓堆转储：用 MAT 分析内存中的大对象和引用链。
- 后查代码：定位内存泄漏、大对象创建等根因。
- 最后调参：根据分析结果合理调整 JVM 参数。
掌握 Full GC 的原理和排查方法，是每个 Java 开发者进阶的必修课。希望本文能帮助你在面对 Full GC 问题时，不再手足无措，而是能够从容应对、快速解决。