JAVA 程序频繁触发 Full GC？老年代调优与对象分配策略详解

大家好，今天我们来聊聊 Java 程序中一个常见的问题：频繁触发 Full GC (Full Garbage Collection)。 Full GC 的发生意味着 JVM 需要对整个堆内存（包括新生代和老年代）进行垃圾回收，这个过程通常会Stop-The-World (STW)，暂停所有应用程序线程，导致程序性能显著下降，甚至出现卡顿。

我们的目标是理解 Full GC 频繁发生的原因，并学会如何通过调整老年代配置和优化对象分配策略来减少 Full GC 的发生，提升 Java 程序的性能和稳定性。

1. 理解 Full GC 的触发条件

Full GC 的触发条件比 Minor GC 复杂一些。一般来说，以下情况会触发 Full GC：

老年代空间不足： 这是最常见的原因。当老年代空间不足以存放新晋升的对象时，JVM 会尝试进行 Full GC 来回收老年代空间。如果 Full GC 后仍然无法腾出足够的空间，就会抛出 OutOfMemoryError: Java heap space 异常。
System.gc() 的显式调用： 虽然不推荐，但开发者可以通过 System.gc() 方法显式地请求 JVM 进行垃圾回收。这只是一个建议，JVM 不一定会立即执行 Full GC，具体执行时机取决于 JVM 的内部策略。强烈建议避免在生产环境中使用 System.gc()，因为它会干扰 JVM 的自动垃圾回收机制，反而可能导致性能问题。
持久代（PermGen）/ 元空间（Metaspace）不足（针对老版本 JVM）： 在 JDK 7 及更早版本中，持久代用于存储类信息、常量池等数据。如果持久代空间不足，也会触发 Full GC。从 JDK 8 开始，持久代被元空间取代，元空间使用的是本地内存，默认情况下没有大小限制，但可以通过 MaxMetaspaceSize 参数进行限制。如果元空间达到限制，同样会触发 Full GC。
CMS GC 晋升失败： 如果使用的是 CMS 垃圾回收器，在进行并发垃圾回收的过程中，如果新生代的对象过大，无法直接放入老年代，或者老年代空间不足以存放新生代晋升的对象，就会导致晋升失败，从而触发 Full GC。
统计数据导致触发： JVM 内部会维护一些统计数据，例如老年代的使用率、空间分配速率等。如果这些数据超过了 JVM 内部的阈值，也可能触发 Full GC。
堆内存分配担保失败： 在 Minor GC 之前，JVM 会检查老年代是否有足够的连续空间来存放新生代所有对象在极端情况下都存活下来的情况。如果老年代空间不足，则会触发 Full GC。

2. 分析 Full GC 频繁发生的原因

要解决 Full GC 频繁发生的问题，首先需要找出根本原因。常见的导致 Full GC 频繁发生的原因包括：

老年代空间分配过小： 如果老年代空间太小，很容易被填满，从而频繁触发 Full GC。
长期存活的对象过多： 如果程序中存在大量的长期存活的对象，它们会一直占用老年代空间，导致老年代很快被填满。
对象创建速度过快： 如果程序中对象创建的速度过快，导致新生代很快被填满，大量对象晋升到老年代，也会导致老年代很快被填满。
内存泄漏： 内存泄漏是指程序中存在不再使用的对象，但由于某些原因，这些对象无法被垃圾回收器回收，导致它们一直占用堆内存。随着时间的推移，内存泄漏会导致堆内存被耗尽，从而频繁触发 Full GC，最终导致 OutOfMemoryError 异常。
不合理的垃圾回收器配置： 如果垃圾回收器的配置不合理，例如选择了不适合应用场景的垃圾回收器，或者配置了不合理的垃圾回收参数，也可能导致 Full GC 频繁发生。

3. 定位 Full GC 问题的工具和方法

在分析 Full GC 问题时，我们需要使用一些工具来帮助我们定位问题：

GC 日志： GC 日志是分析 GC 行为的重要依据。通过分析 GC 日志，我们可以了解 GC 的频率、持续时间、回收的内存大小等信息，从而判断是否存在 Full GC 频繁发生的问题，并找到可能的原因。
- 在 JVM 启动参数中添加 -verbose:gc 或 -Xlog:gc* 可以启用 GC 日志。
- 可以使用 jstat 命令实时监控 JVM 的 GC 状态。
- 可以使用 GC 日志分析工具，例如 GCeasy、GCViewer 等，来可视化 GC 日志，更方便地分析 GC 行为。
JConsole 和 JVisualVM： JConsole 和 JVisualVM 是 JDK 自带的图形化监控工具，可以用来监控 JVM 的内存使用情况、线程状态、GC 状态等。通过 JConsole 和 JVisualVM，我们可以实时观察堆内存的使用情况，判断是否存在内存泄漏，或者老年代是否很快被填满。
堆转储文件（Heap Dump）： 堆转储文件是 JVM 在某个时刻的堆内存快照。通过分析堆转储文件，我们可以了解堆内存中对象的分布情况，找到占用内存最多的对象，从而判断是否存在内存泄漏，或者哪些对象占用了大量的内存。
- 可以使用 jmap 命令生成堆转储文件。
- 可以使用 MAT (Memory Analyzer Tool) 或 Eclipse Memory Analyzer 等工具来分析堆转储文件。
代码审查： 代码审查是找出内存泄漏和不合理的对象分配策略的有效方法。通过仔细阅读代码，我们可以发现是否存在没有释放的资源、不合理的对象生命周期、过多的临时对象创建等问题。

4. 老年代调优策略

如果 Full GC 频繁发生的原因是老年代空间不足，我们可以通过调整老年代的大小来缓解问题。

增加老年代空间： 这是最直接的方法。可以通过 -Xms 和 -Xmx 参数设置堆内存的初始大小和最大大小，并通过 -XX:NewRatio 参数设置新生代和老年代的比例。例如，-Xms4g -Xmx4g -XX:NewRatio=2 表示堆内存的初始大小和最大大小都是 4GB，新生代和老年代的比例是 1:2，即新生代大小为 4GB / 3，老年代大小为 8GB / 3。
- 增加老年代空间可以减少 Full GC 的频率，但也会增加 Minor GC 的时间。因此，需要根据实际情况进行调整，找到一个合适的平衡点。
- 需要注意的是，增加堆内存大小可能会增加 GC 的总时间。

选择合适的垃圾回收器： 不同的垃圾回收器适用于不同的应用场景。

Serial GC： 单线程垃圾回收器，适用于单核 CPU 的环境，或者对停顿时间要求不高的应用。
Parallel GC： 多线程垃圾回收器，适用于多核 CPU 的环境，吞吐量较高，但停顿时间较长。可以通过 -XX:+UseParallelGC 和 -XX:+UseParallelOldGC 参数启用。
CMS GC： 并发垃圾回收器，停顿时间较短，但会占用一部分 CPU 资源。适用于对停顿时间要求较高的应用。可以通过 -XX:+UseConcMarkSweepGC 参数启用。
G1 GC： 新一代垃圾回收器，适用于大堆内存的应用，可以预测停顿时间，并尽量减少停顿时间。可以通过 -XX:+UseG1GC 参数启用。

垃圾回收器	优点	缺点	适用场景
Serial GC	简单，开销小	停顿时间长	单核 CPU，数据量小的应用
Parallel GC	吞吐量高	停顿时间相对较长	多核 CPU，对停顿时间要求不高
CMS GC	停顿时间短，并发回收	占用 CPU 资源，容易产生内存碎片	对停顿时间敏感，CPU资源充足
G1 GC	可预测的停顿时间，适用于大堆	复杂，需要更多的调优	大堆，需要控制停顿时间的应用

调整垃圾回收参数： 除了选择合适的垃圾回收器之外，还可以通过调整垃圾回收参数来优化 GC 行为。
- -XX:MaxTenuringThreshold：设置对象在新生代中存活的最大年龄。如果对象在新生代中存活的时间超过了这个值，就会晋升到老年代。适当调整这个值可以控制对象晋升到老年代的速度。
- -XX:CMSInitiatingOccupancyFraction：设置 CMS GC 在老年代使用率达到多少时启动。适当调整这个值可以避免老年代过早被填满，从而减少 Full GC 的频率。
- -XX:G1HeapWastePercent：设置 G1 GC 允许的堆浪费百分比。适当调整这个值可以控制 G1 GC 的回收效率。

5. 对象分配策略优化

除了调整老年代配置之外，还可以通过优化对象分配策略来减少 Full GC 的发生。

尽量使用对象池： 对于频繁创建和销毁的对象，可以使用对象池来重用对象，避免频繁的内存分配和回收。例如，可以使用 Apache Commons Pool 或 Caffeine 等对象池库。

import org.apache.commons.pool2.BasePooledObjectFactory;
import org.apache.commons.pool2.ObjectPool;
import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;

class MyObject {
    // ...
}

class MyObjectFactory extends BasePooledObjectFactory<MyObject> {
    @Override
    public MyObject create() throws Exception {
        return new MyObject();
    }

    @Override
    public PooledObject<MyObject> wrap(MyObject obj) {
        return new DefaultPooledObject<>(obj);
    }
}

public class ObjectPoolExample {
    public static void main(String[] args) throws Exception {
        MyObjectFactory factory = new MyObjectFactory();
        ObjectPool<MyObject> pool = new GenericObjectPool<>(factory);

        MyObject obj = pool.borrowObject();
        // ... 使用 obj ...
        pool.returnObject(obj);

        pool.close();
    }
}

避免创建过大的对象： 过大的对象会直接分配到老年代，容易导致老年代被填满。应该尽量将大对象拆分成多个小对象，或者使用流式处理来处理大对象。
尽量使用局部变量： 局部变量的生命周期较短，更容易被垃圾回收器回收。应该尽量将对象定义为局部变量，而不是成员变量。
及时释放资源： 对于需要手动释放的资源，例如文件流、数据库连接等，应该在使用完毕后及时释放，避免资源泄漏。可以使用 try-with-resources 语句来自动释放资源。
```
try (FileInputStream fis = new FileInputStream("file.txt")) {
    // ... 使用 fis ...
} catch (IOException e) {
    // ... 处理异常 ...
}
```
使用 StringBuilder 代替 String 进行字符串拼接： String 对象是不可变的，每次进行字符串拼接都会创建一个新的 String 对象。使用 StringBuilder 可以避免创建大量的临时 String 对象。
```
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    sb.append("hello");
}
String result = sb.toString();
```
慎用 finalize() 方法： finalize() 方法是在对象被垃圾回收之前调用的方法。由于 finalize() 方法的执行时机不确定，而且会影响垃圾回收的效率，因此应该尽量避免使用 finalize() 方法。可以使用 try-with-resources 语句或显式地释放资源来代替 finalize() 方法。

6. 内存泄漏的排查与解决

内存泄漏是导致 Full GC 频繁发生的常见原因。如果程序中存在内存泄漏，即使调整了老年代的大小和优化了对象分配策略，也无法彻底解决 Full GC 的问题。因此，我们需要学会排查和解决内存泄漏。

使用堆转储文件分析工具： 可以使用 MAT 或 Eclipse Memory Analyzer 等工具来分析堆转储文件，找到占用内存最多的对象，从而判断是否存在内存泄漏。这些工具可以帮助我们找到没有被引用的对象，或者被错误引用的对象。
代码审查： 通过仔细阅读代码，我们可以发现是否存在没有释放的资源、不合理的对象生命周期、错误的缓存使用等问题。
使用内存泄漏检测工具： 可以使用一些内存泄漏检测工具，例如 YourKit Java Profiler、JProfiler 等，来自动检测程序中的内存泄漏。

7. 代码示例：模拟 Full GC 频繁发生并进行调优

为了更好地理解 Full GC 的调优过程，我们来看一个简单的代码示例，模拟 Full GC 频繁发生的情况，并进行调优。

import java.util.ArrayList;
import java.util.List;

public class FullGCTest {

    private static final int SIZE = 1000000;

    public static void main(String[] args) throws InterruptedException {
        List<Object> list = new ArrayList<>();
        while (true) {
            for (int i = 0; i < SIZE; i++) {
                list.add(new byte[1024]); // 创建大量对象
            }
            System.out.println("List size: " + list.size());
            Thread.sleep(100); // 模拟程序运行
        }
    }
}

这段代码会不断地创建大量的 byte 数组，并将它们添加到 List 中。由于 List 持有这些对象的引用，导致这些对象无法被垃圾回收器回收，最终会导致堆内存被耗尽，从而频繁触发 Full GC。

调优步骤：

运行程序，并观察 GC 日志： 可以通过添加 -verbose:gc 参数来启用 GC 日志，并观察 GC 的频率和持续时间。可以看到 Full GC 频繁发生。
使用 JConsole 或 JVisualVM 监控内存使用情况： 可以看到老年代的内存使用率迅速上升，很快达到 100%。
生成堆转储文件，并使用 MAT 分析： 可以使用 jmap 命令生成堆转储文件，并使用 MAT 分析。可以看到 List 对象占用了大量的内存，并且 byte 数组是泄漏的根源。
修改代码，减少对象创建： 可以修改代码，减少对象的创建数量，或者使用对象池来重用对象。
调整老年代大小： 可以通过 -Xms 和 -Xmx 参数增加堆内存的大小，并通过 -XX:NewRatio 参数调整新生代和老年代的比例。
选择合适的垃圾回收器： 可以根据应用场景选择合适的垃圾回收器。如果对停顿时间要求较高，可以选择 CMS GC 或 G1 GC。
调整垃圾回收参数： 可以根据实际情况调整垃圾回收参数，例如 -XX:MaxTenuringThreshold、-XX:CMSInitiatingOccupancyFraction 等。

通过以上步骤，我们可以逐步优化程序，减少 Full GC 的发生，提高程序的性能和稳定性。例如，我们可以修改代码，限制 List 的大小，当达到一定大小时，清空 List，从而避免内存泄漏。

import java.util.ArrayList;
import java.util.List;

public class FullGCTestOptimized {

    private static final int SIZE = 1000000;
    private static final int MAX_LIST_SIZE = 10000000; // 限制List的大小

    public static void main(String[] args) throws InterruptedException {
        List<Object> list = new ArrayList<>();
        while (true) {
            for (int i = 0; i < SIZE; i++) {
                list.add(new byte[1024]); // 创建大量对象
            }
            System.out.println("List size: " + list.size());
            if (list.size() > MAX_LIST_SIZE) {
                list.clear(); // 清空List
                System.out.println("List cleared.");
            }
            Thread.sleep(100); // 模拟程序运行
        }
    }
}

8. 总结：理解原因，对症下药

今天的讲座我们深入探讨了 Java 程序中 Full GC 频繁发生的原因和解决方法。关键在于理解Full GC的触发条件，善用工具定位问题，并根据实际情况调整老年代配置和优化对象分配策略。此外，排查和解决内存泄漏是避免Full GC的根本方法。

9. 最后的建议：监控和预防

最后，我建议大家在生产环境中加强对 JVM 的监控，及时发现 Full GC 频繁发生的问题，并进行相应的调优。此外，在开发过程中，应该养成良好的编码习惯，避免内存泄漏和不合理的对象分配，从源头上预防 Full GC 问题的发生。

JAVA 程序频繁触发 Full GC？老年代调优与对象分配策略详解

发表回复 取消回复

发表回复取消回复