线上问题——频繁 Full GC 问题的排查思路

一、查看 GC 日志

1. 启用 GC 日志

   • 在 Java 应用中，需要在启动参数中添加适当的参数来启用 GC 日志记录。可以使用-XX:+PrintGCDetails、-XX:+PrintGCDateStamps、-Xloggc:<log - path>参数。其中 -XX:+PrintGCDetails 会打印详细的 GC 信息，-XX:+PrintGCDateStamps会打印 GC 发生的时间戳，-Xloggc:<log - path>指定了 GC 日志的输出路径。

2. 分析 GC 日志内容

   • Full GC 频率：查看 GC 日志中 Full GC 发生的频率。如果 Full GC 过于频繁（例如，每分钟多次），则需要深入分析。
   • Full GC 原因：
     • 内存不足（Heap Space）：如果日志中显示java.lang.OutOfMemoryError: Java heap space，说明应用程序创建的对象太多，导致堆内存不够用，从而触发 Full GC。
     • 永久代 / 元空间（Permanent Generation / Metaspace）溢出：在旧版本的 Java 中，可能会出现java.lang.OutOfMemoryError: PermGen space，在 Java 8 及以后可能会出现java.lang.OutOfMemoryError: Metaspace。这表示类加载过多或者存在类加载器泄漏等问题，导致永久代或元空间被耗尽。
     • System.gc () 调用：如果在日志中发现有Full GC(System)，说明应用程序中显式调用了System.gc()方法。虽然在现代 JVM 中，System.gc()的调用不一定会立即触发 Full GC，但如果频繁调用，可能会导致 Full GC 频繁发生。

二、分析内存泄漏

1. 使用内存分析工具
   • Heap Dump 工具：例如，使用jmap -dump:format=b,file=<dump - file - path>命令可以生成堆快照（Heap Dump）文件。在生成堆快照时，要选择在 Full GC 发生后或者内存使用量较高时进行，这样能更准确地捕获问题。它可以打开堆快照文件，分析对象的引用关系、内存占用情况等。通过 MAT，可以查找那些占用大量内存且不应该存在的对象，例如：
     • 大对象（Large Objects）：MAT 可以帮助找到那些占用大量堆内存的单个对象。如果存在一些本应被回收但却一直存在的大对象，可能是内存泄漏的迹象。
     • 对象引用链（Reference Chains）：通过分析对象的引用链，可以发现那些意外被长引用链所保持的对象。例如，一个不再使用的对象可能通过一系列的强引用被保存在内存中，导致无法被垃圾回收。
2. 长期运行监控
   • Java Flight Recorder（JFR）：这是 JDK 自带的一个性能监控和事件记录工具。它可以在应用程序运行过程中持续监控内存使用情况、对象分配和回收情况等。通过 JFR，可以发现随着时间的推移，内存中对象数量和大小的异常增长情况，从而判断是否存在内存泄漏。

三、检查对象生命周期

1. 审查代码中的对象引用
   • 局部变量和方法参数：检查方法中的局部变量和参数，确保在不需要使用对象时，对象的引用能够及时超出作用域。例如，在方法结束后，方法内创建的局部对象应该能够被垃圾回收。
   • 静态变量和单例对象：静态变量和单例对象的生命周期通常与应用程序的生命周期相同。因此，要特别注意这些对象所引用的其他对象。如果单例对象持有大量其他对象的引用，并且这些引用在不需要时没有被正确清理，可能会导致内存问题。
2. 缓存管理
   • 缓存策略审查：如果应用程序中使用了缓存机制，例如使用HashMap或其他缓存库来缓存数据，需要检查缓存的清除策略。如果缓存没有设置合理的过期时间或者最大容量限制，可能会导致缓存对象不断累积，最终引发 Full GC。
   • 弱引用和软引用的使用：考虑在合适的场景下使用弱引用（WeakReference）或软引用（SoftReference）。弱引用的对象在下次垃圾回收时会被回收，软引用的对象在内存不足时会被回收。例如，对于一些可以重新加载或者重新创建的数据，可以使用弱引用或软引用进行缓存，以避免长期占用内存。

四、优化代码

1. 对象创建模式优化
   • 减少不必要的对象创建：例如，在循环中频繁创建字符串对象（如String s = new String(“constant - value”);）是一种低效的做法。可以使用字符串常量或者StringBuilder来优化这种情况。
   • 对象池（Object Pooling）技术：对于一些创建成本高且可复用的对象，如数据库连接、线程等，可以考虑使用对象池技术。通过对象池，可以重复利用已经创建的对象，减少对象创建和销毁的频率。
2. 优化数据结构和算法
   • 选择合适的数据结构：根据应用程序的需求选择合适的数据结构。例如，如果需要频繁地在集合中查找元素，使用HashSet或HashMap可能比ArrayList更高效。如果需要按照顺序访问元素，ArrayList可能更合适。
   • 算法复杂度分析：对代码中的算法进行复杂度分析。如果存在时间复杂度或空间复杂度较高的算法（如嵌套的多层循环、递归调用深度过深等），可能会导致大量对象的创建和内存占用。优化这些算法可以减少内存压力。

五、调整垃圾回收策略

1. 选择合适的垃圾回收器

   • Serial GC：适合单核 CPU 且内存较小的环境，简单且暂停时间较长。
   • Parallel GC（Throughput Collector）：适合对吞吐量要求较高的应用，能够充分利用多核 CPU 并行进行垃圾回收，但暂停时间可能较长。
   • CMS（Concurrent Mark - Sweep）GC：适合对响应时间敏感的应用，它在垃圾回收过程中尽量减少应用程序的暂停时间，但可能会有更高的 CPU 使用率和内存碎片问题。
   • G1（Garbage - First）GC：适用于大容量内存的服务器，它将堆内存划分为多个大小相等的区域（Region），在垃圾回收时可以优先回收垃圾最多的区域，兼具高吞吐量和低暂停时间的特点。

2. 调整垃圾回收器参数

   • 堆大小参数：-Xms和-Xmx分别用于设置初始堆大小和最大堆大小。合理设置这两个参数可以避免因堆空间过小导致频繁 Full GC，同时也避免因堆空间过大而浪费内存资源。
   • 新生代和老年代比例：例如，-XX:NewRatio参数可以设置新生代和老年代的比例。调整这个比例可以影响对象在新生代和老年代之间的分配，进而影响垃圾回收的频率和效率。
   • Survivor 区比例：-XX:SurvivorRatio参数用于设置 Eden 区和 Survivor 区的比例。合理的 Survivor 区比例可以确保在新生代中对象的复制和回收能够高效进行。

六、使用监控工具

1. 实时监控内存使用情况

   • VisualVM：这是一个免费的 Java 性能监控和分析工具。它可以连接到本地或远程的 Java 应用程序，实时监控堆内存、非堆内存、线程等的使用情况。通过 VisualVM，可以直观地看到内存使用量的变化趋势，以及 Full GC 发生的时间点和频率。
   • JConsole：JDK 自带的监控工具，可以监控 Java 应用程序的运行时性能，包括内存使用、线程、类加载等。JConsole 可以帮助发现内存使用的异常情况，例如内存使用量突然急剧上升等。

2. 分析监控数据

   • 内存使用趋势分析：通过长期监控内存使用情况，分析内存使用量的增长趋势。如果发现内存使用量呈线性或指数增长，可能存在内存泄漏或其他内存相关问题。
   • Full GC 与应用程序行为关联分析：将 Full GC 的发生时间与应用程序的业务操作进行关联分析。例如，如果每次执行某个特定的业务操作后都会引发 Full GC，那么很可能这个业务操作存在内存问题，如创建了大量对象或者持有了不必要的对象引用等。