JAVA 服务频繁 Full GC？堆外内存与 DirectBuffer 泄漏排查

JAVA 服务频繁 Full GC？堆外内存与 DirectBuffer 泄漏排查

大家好，今天我们来聊聊一个比较棘手的问题：JAVA 服务频繁 Full GC，并深入探讨堆外内存与 DirectBuffer 泄漏的排查思路和方法。 Full GC 频繁发生会严重影响服务的性能和稳定性，甚至导致服务崩溃。 而堆外内存泄漏，尤其 DirectBuffer 的泄漏，往往隐藏更深，更难定位。

一、Full GC 的成因与影响

首先，我们需要了解 Full GC 到底是什么，以及为什么它会影响性能。

1. 什么是 Full GC？

垃圾回收（GC）是 JVM 自动进行内存管理的关键机制。 Full GC 是指 JVM 对整个堆内存（包括年轻代和老年代）进行垃圾回收。 相对而言，Minor GC 只回收年轻代。

2. Full GC 的成因

Full GC 触发的原因有很多，常见的包括：

• 老年代空间不足： 这是最常见的原因。当老年代无法容纳新的对象时，就会触发 Full GC。
• System.gc() 的调用： 尽管不建议手动调用 System.gc()，但它仍然会被开发者使用，强制触发 Full GC。
• 永久代/元空间（PermGen/Metaspace）空间不足： 在 JDK 8 之前，永久代存储类的元数据；JDK 8 之后，元数据存储在元空间。如果这些空间不足，也会触发 Full GC。
• CMS GC 晋升失败： 使用 CMS 垃圾回收器时，如果在并发回收过程中，老年代空间不足以容纳晋升的对象，会触发 Concurrent Mode Failure，进而导致 Full GC。
• 统计数据不准确导致的提前触发： JVM 基于历史 GC 数据预测老年代的使用情况，如果预测不准确，可能会提前触发 Full GC。
• 堆外内存压力： 堆外内存的过度使用，例如 DirectBuffer 的泄漏，可能会间接导致 Full GC。
• GC 参数配置不合理： GC 参数配置不当会导致堆空间划分不合理，从而更容易触发 Full GC。

3. Full GC 的影响

Full GC 会暂停整个应用程序的执行（Stop-The-World，STW），造成明显的延迟。 频繁的 Full GC 会导致：

• 响应时间变长： 用户请求处理时间大幅增加。
• 吞吐量下降： 单位时间内处理的请求数量减少。
• 系统不稳定： 在极端情况下，Full GC 过于频繁会导致服务崩溃。

二、排查 Full GC 频繁问题的常用工具和方法

排查 Full GC 问题需要综合利用各种工具和方法，从多个角度分析问题。

1. 监控与日志分析

• GC 日志： 这是最重要的信息来源。开启 GC 日志可以记录每次 GC 的详细信息，包括 GC 类型、耗时、堆内存使用情况等。

  • 开启 GC 日志： 在 JVM 启动参数中添加以下参数：

    -verbose:gc
    -Xloggc:/path/to/gc.log
    -XX:+PrintGCDetails
    -XX:+PrintGCTimeStamps
    -XX:+PrintGCDateStamps
    -XX:+PrintHeapAtGC
    -XX:+UseGCLogFileRotation
    -XX:NumberOfGCLogFiles=10
    -XX:GCLogFileSize=100M

  • GC 日志分析工具： 可以使用 GCeasy、GCViewer 等工具分析 GC 日志，生成图表和报告，帮助我们快速定位问题。

• JVM 监控工具：

  • VisualVM： JDK 自带的可视化监控工具，可以查看堆内存使用情况、线程信息、CPU 使用率等。
  • JConsole： 也是 JDK 自带的监控工具，功能与 VisualVM 类似。
  • JProfiler、YourKit： 商业的 JVM 监控工具，功能更强大，可以进行更深入的分析，例如内存泄漏分析、CPU 性能分析等。
  • Prometheus + Grafana： 常用的监控组合，可以监控 JVM 的各种指标，例如堆内存使用情况、GC 耗时等。 可以使用 Micrometer 等库将 JVM 指标暴露给 Prometheus。

• 操作系统监控工具： 例如 top、vmstat、iostat 等，可以监控 CPU 使用率、内存使用情况、磁盘 I/O 等。

• 应用日志： 记录应用程序的运行状态和错误信息，可以帮助我们发现潜在的问题。

2. 常用命令

• jstat： JDK 自带的命令行工具，可以查看 JVM 的各种统计信息，例如堆内存使用情况、GC 次数和耗时等。

  jstat -gc <pid> <interval> <count>

  • <pid>：JVM 进程 ID。
  • <interval>：采样间隔（毫秒）。
  • <count>：采样次数。

  jstat -gc 输出的关键字段：

  字段	含义
  S0C	Survivor 0 区的容量（KB）
  S1C	Survivor 1 区的容量（KB）
  S0U	Survivor 0 区已使用的空间（KB）
  S1U	Survivor 1 区已使用的空间（KB）
  EC	Eden 区的容量（KB）
  EU	Eden 区已使用的空间（KB）
  OC	老年代的容量（KB）
  OU	老年代已使用的空间（KB）
  MC	元空间的容量（KB）
  MU	元空间已使用的空间（KB）
  CCSC	压缩类空间的容量（KB）
  CCSU	压缩类空间已使用的空间（KB）
  YGC	Young GC 的次数
  YGCT	Young GC 的总耗时（秒）
  FGC	Full GC 的次数
  FGCT	Full GC 的总耗时（秒）
  GCT	GC 的总耗时（秒）

• jmap： JDK 自带的命令行工具，可以生成堆转储快照（heap dump），用于分析内存泄漏问题。

  jmap -dump:format=b,file=<filename>.hprof <pid>

  • <filename>.hprof：堆转储快照的文件名。

• jstack： JDK 自带的命令行工具，可以打印线程堆栈信息，用于分析死锁、CPU 占用过高等问题。

  jstack <pid>

• pmap： Linux 命令，可以查看进程的内存映射，用于分析堆外内存使用情况。

  pmap <pid>

3. 内存泄漏分析

如果怀疑存在内存泄漏，可以使用以下工具进行分析：

• MAT (Memory Analyzer Tool)： Eclipse 基金会提供的免费内存分析工具，可以分析堆转储快照，找出内存泄漏的根源。
• VisualVM、JProfiler、YourKit： 这些 JVM 监控工具也提供了内存泄漏分析功能。

4. 代码审查

仔细审查代码，特别是以下几个方面：

• 集合类的使用： 检查集合类是否正确使用，例如是否忘记释放不再使用的对象。
• 缓存的使用： 检查缓存是否设置了合理的过期时间，避免缓存无限增长。
• 数据库连接、文件句柄、Socket 连接等资源的使用： 确保这些资源在使用完毕后及时关闭。
• 使用了 NIO 的 DirectBuffer: 这是堆外内存泄漏的常见来源，务必确保 DirectBuffer 被正确释放。
• 使用了 Unsafe 类: Unsafe 类的使用不当也可能导致堆外内存泄漏。

三、DirectBuffer 泄漏排查与解决

DirectBuffer 是 NIO 中用于直接操作内存的缓冲区，它分配在堆外内存中。 如果 DirectBuffer 使用不当，很容易导致堆外内存泄漏。

1. DirectBuffer 的分配与释放

DirectBuffer 的分配方式有两种：

• ByteBuffer.allocateDirect(int capacity)： 直接分配指定大小的 DirectBuffer。
• 通过 MappedByteBuffer： 将文件的一部分映射到内存中，返回一个 DirectBuffer。

DirectBuffer 的释放方式比较特殊，它依赖于 Cleaner 机制。 当 DirectBuffer 对象被垃圾回收时，Cleaner 会调用 unsafe.freeMemory() 方法释放堆外内存。 但是，Cleaner 的执行时机是不确定的，如果 DirectBuffer 对象一直没有被垃圾回收，那么对应的堆外内存就无法释放，从而导致泄漏。

2. DirectBuffer 泄漏的常见原因

• DirectBuffer 对象被长时间持有： 如果 DirectBuffer 对象被长时间持有，例如被静态变量引用，那么它就无法被垃圾回收，导致堆外内存泄漏。
• DirectBuffer 对象创建过多，超过堆外内存限制： 如果应用程序创建了大量的 DirectBuffer 对象，超过了 JVM 的堆外内存限制，也会导致 OutOfMemoryError。
• DirectBuffer 对象在使用完毕后没有及时释放： 尽管 DirectBuffer 依赖于 Cleaner 机制进行释放，但是为了避免堆外内存泄漏，我们应该尽量在使用完毕后手动释放 DirectBuffer。

3. 排查 DirectBuffer 泄漏的方法

• 监控堆外内存使用情况： 可以使用 pmap 命令或者 JVM 监控工具监控堆外内存使用情况。 如果发现堆外内存持续增长，那么很可能存在 DirectBuffer 泄漏。
• 使用 jmap 分析堆转储快照： 可以使用 jmap 命令生成堆转储快照，然后使用 MAT 或其他内存分析工具分析堆转储快照，查找 DirectBuffer 对象。 重点关注 java.nio.DirectByteBuffer 类的实例数量和大小。
• 使用 -XX:MaxDirectMemorySize 参数限制堆外内存大小： 可以通过设置 -XX:MaxDirectMemorySize 参数限制 JVM 可以使用的堆外内存大小。 如果应用程序尝试分配超过限制的堆外内存，JVM 会抛出 OutOfMemoryError，从而可以帮助我们发现 DirectBuffer 泄漏。
• 使用 sun.misc.Unsafe 类手动释放 DirectBuffer： 可以使用 sun.misc.Unsafe 类手动释放 DirectBuffer 占用的堆外内存。 但是，这种方法比较危险，需要谨慎使用。

4. DirectBuffer 泄漏的解决方案

• 尽量使用堆内内存： 如果可以使用堆内内存，尽量避免使用 DirectBuffer。

• 使用对象池： 对于频繁使用的 DirectBuffer，可以使用对象池来复用 DirectBuffer 对象，避免频繁创建和销毁 DirectBuffer 对象。

• 手动释放 DirectBuffer： 在使用完毕后，手动释放 DirectBuffer 对象。 可以通过反射获取 DirectBuffer 的 Cleaner 对象，然后调用 Cleaner.clean() 方法释放堆外内存。

  import sun.misc.Cleaner;
  import java.nio.ByteBuffer;
  import java.lang.reflect.Method;
  
  public class DirectBufferCleaner {
  
      public static void clean(ByteBuffer directBuffer) {
          if (directBuffer == null || !directBuffer.isDirect()) {
              return;
          }
          try {
              Method cleanerMethod = directBuffer.getClass().getMethod("cleaner");
              cleanerMethod.setAccessible(true);
              Cleaner cleaner = (Cleaner) cleanerMethod.invoke(directBuffer);
              if (cleaner != null) {
                  cleaner.clean();
              }
          } catch (Exception e) {
              // Handle exception appropriately, log it or rethrow
              e.printStackTrace(); // Replace with a proper logging mechanism
          }
      }
  
      public static void main(String[] args) {
          ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
          // Use the buffer
          System.out.println("Buffer allocated.");
          // Clean the buffer when done
          DirectBufferCleaner.clean(buffer);
          System.out.println("Buffer cleaned.");
      }
  }

  警告： 手动释放 DirectBuffer 可能会导致 JVM 崩溃，请谨慎使用。 只有在确定 DirectBuffer 对象不再使用时才能释放它。

• 使用 Netty 的 PooledByteBufAllocator： Netty 框架提供了 PooledByteBufAllocator，可以高效地管理 DirectBuffer 对象，避免堆外内存泄漏。

5. 代码示例：使用反射手动释放 DirectBuffer

以下代码示例演示了如何使用反射手动释放 DirectBuffer 占用的堆外内存。

import java.nio.ByteBuffer;
import sun.misc.Cleaner;

public class DirectBufferRelease {

    public static void releaseDirectBuffer(ByteBuffer buffer) {
        if (buffer.isDirect()) {
            try {
                Cleaner cleaner = ((sun.nio.ch.DirectBuffer) buffer).cleaner();
                if (cleaner != null) {
                    cleaner.clean();
                }
            } catch (Exception e) {
                e.printStackTrace();
                // Handle exception appropriately, log it or rethrow
            }
        }
    }

    public static void main(String[] args) {
        ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024); // 1MB
        System.out.println("DirectBuffer allocated: " + buffer);

        // Simulate some work with the buffer
        for (int i = 0; i < 1024; i++) {
            buffer.put(i % 128, (byte) i);
        }

        // Release the DirectBuffer
        releaseDirectBuffer(buffer);
        System.out.println("DirectBuffer released.");

        // Try to access the buffer after release (expecting an exception)
        try {
            buffer.get(0);
        } catch (IllegalStateException e) {
            System.out.println("Exception caught after releasing the buffer: " + e.getMessage());
        }
    }
}

注意： 运行上述代码需要添加 JVM 启动参数 --add-exports java.base/sun.nio.ch=ALL-UNNAMED 以允许访问 sun.nio.ch 包。

四、案例分析

假设我们有一个基于 Netty 的服务器应用程序，处理大量的网络请求。 经过一段时间的运行，我们发现 Full GC 变得越来越频繁，并且堆外内存使用量持续增长。

1. 监控与日志分析

我们首先开启 GC 日志，并使用 GCeasy 分析 GC 日志。 我们发现 Full GC 的频率很高，并且老年代的增长速度很快。 同时，我们使用 pmap 命令监控堆外内存使用情况，发现堆外内存持续增长，远超我们的预期。

2. 内存泄漏分析

我们使用 jmap 命令生成堆转储快照，并使用 MAT 分析堆转储快照。 我们发现存在大量的 java.nio.DirectByteBuffer 类的实例，并且这些实例被 Netty 的 ByteBuf 对象引用。

3. 代码审查

我们仔细审查 Netty 的代码，发现我们在处理网络请求时，使用了 PooledByteBufAllocator 分配 ByteBuf 对象。 但是，我们在某些情况下，忘记释放 ByteBuf 对象，导致 DirectBuffer 对象被长时间持有，从而导致堆外内存泄漏。

4. 解决方案

我们在代码中添加 ByteBuf.release() 方法，确保在使用完毕后及时释放 ByteBuf 对象。 同时，我们优化了 Netty 的配置，例如调整 PooledByteBufAllocator 的参数，以更好地管理 DirectBuffer 对象。

5. 验证

重新部署应用程序后，我们再次监控 GC 和堆外内存使用情况。 我们发现 Full GC 的频率明显降低，并且堆外内存使用量稳定在一个合理的水平。 问题得到解决。

五、优化 GC 参数

合理的 GC 参数配置可以减少 Full GC 的频率，提高应用程序的性能。

以下是一些常用的 GC 参数：

参数	描述
-Xms	初始堆大小
-Xmx	最大堆大小
-Xmn	年轻代大小
-XX:NewRatio	设置年轻代和老年代的比例。 例如，-XX:NewRatio=2 表示老年代是年轻代的 2 倍。
-XX:SurvivorRatio	设置 Eden 区和 Survivor 区的比例。 例如，-XX:SurvivorRatio=8 表示 Eden 区是 Survivor 区的 8 倍，即每个 Survivor 区占年轻代的 1/10。
-XX:MaxMetaspaceSize	设置元空间的最大大小。
-XX:+UseG1GC	启用 G1 垃圾回收器。
-XX:MaxGCPauseMillis	设置最大 GC 停顿时间。 G1 垃圾回收器会尽量满足这个目标。
-XX:InitiatingHeapOccupancyPercent	设置 G1 垃圾回收器启动并发 GC 的堆占用百分比。
-XX:+UseConcMarkSweepGC	启用 CMS 垃圾回收器。 (Deprecated in Java 9, removed in Java 14)
-XX:+CMSParallelRemarkEnabled	启用并行 Remark 阶段，可以减少 Remark 阶段的停顿时间。
-XX:CMSInitiatingOccupancyFraction	设置 CMS 垃圾回收器启动并发 GC 的堆占用百分比。
-XX:+UseParallelGC	启用 Parallel Scavenge + Parallel Old 垃圾回收器 (吞吐量优先)
-XX:ParallelGCThreads	设置并行 GC 的线程数。
-XX:+ExplicitGCInvokesConcurrent	使 System.gc() 调用触发并发 GC 而不是 Full GC。
-XX:+DisableExplicitGC	禁用 System.gc() 调用。 强烈建议禁用，除非你清楚 System.gc() 的影响。

选择合适的 GC 参数需要根据应用程序的特点和运行环境进行调整。 通常需要进行多次测试，才能找到最佳的 GC 参数配置。

六、一些总结性的话

今天我们深入探讨了 JAVA 服务频繁 Full GC 的问题，重点分析了堆外内存与 DirectBuffer 泄漏的排查和解决思路。 解决 Full GC 问题是一个复杂的过程，需要耐心和细致的分析。希望这次分享能帮助大家更好地理解 Full GC 的成因和排查方法，提升服务的稳定性和性能。记住，监控、分析和优化是解决问题的关键步骤。