记录通过jstat查看JVM内存垃圾回收状态

记录JVM内存状态查看

我们在部署java项目的时候，一般都会指定-xms -xmx，以此来限制内存的占用，那么具体设置多大的值最适合当前项目呢？

这个最开始只能大概估计一下，比如128M，256M， 1024M，如果项目里有很多bean，那可能就需要比较大的内存。我这里有个很小的项目，pom文件主要只引入了spring-boot-starter-web和spring-boot-starter-webflux，代码里controller和service也都只有一个。大概估计一下128M应该够用了，于是就设定为128M，但是怎样才能知道这128M是大了还是小了呢，带着这个问题，我们去问一下AI智能助手。

首先，贴上的我的Dockerfile：

FROM openjdk:21-jdk-alpine

ENV TZ=Asia/Shanghai \
    APP_PATH=/data \
    JAVA_OPTS="-Xms128m -Xmx128m"

WORKDIR $APP_PATH

COPY sse-1.0-SNAPSHOT.jar app.jar

EXPOSE 8080

ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -jar app.jar" ]

这里设置堆内存的初始内存=最大内存, 这样可以避免JVM堆内存频繁扩展或收缩带来的性能损耗和内存碎片。

然后开始问问题：

问： 解释一下这个命令：jstat -gc <pid> 1000 10

答：

jstat 是Java虚拟机（JVM）提供的一个命令行工具，它用于监视JVM中的类加载、内存、垃圾收集、JIT编译等运行时数据。

命令 jstat -gc <pid> 1000 10 的作用是：

• -gc 选项: 表示要报告关于垃圾收集（Garbage Collection, GC）的统计信息。
• <pid>: 是你要监控的Java进程的进程ID。你需要替换<pid>为实际的Java进程ID。
• 1000: 表示监控工具的输出间隔，单位是毫秒。这里设置为1000毫秒，即每秒输出一次信息。
• 10: 表示输出次数。这里设置为10，即这个命令会运行10秒，每秒输出一次垃圾收集情况。

使用这个命令，你可以获取关于Java进程垃圾收集情况的实时信息，包括年轻代（Young Generation）、老年代（Old Generation）、永久代（PermGen，在JDK 8中被Metaspace取代）的当前使用情况和垃圾收集情况等。这对于调优JVM性能和分析内存问题非常有用。

问： 输出结果如下，帮我分析一下：

S0C  S1C     S0U   S1U      EC       EU       OC       OU        MC       MU       CCSC    CCSU    YGC   YGCT    FGC   FGCT    CGC  CGCT    GCT
0.0  5120.0  0.0   5114.1   76800.0  65536.0  49152.0  38495.2   57920.0  57204.2  6912.0  6577.0  24    0.387   0     0.000   4    0.013   0.401

答：
该输出显示了JVM的垃圾收集（GC）的一些关键统计数据。每一列代表不同的信息：

• S0C: 年轻代中第一个幸存区（Survivor Space 0）的当前容量（Capacity）（以KB为单位）。
• S1C: 年轻代中第二个幸存区（Survivor Space 1）的当前容量（以KB为单位）。
• S0U: 年轻代中第一个幸存区当前已使用空间（Usage）（以KB为单位）。
• S1U: 年轻代中第二个幸存区当前已使用空间（以KB为单位）。
• EC: 年轻代中伊甸园区（Eden Space）的当前容量（以KB为单位）。
• EU: 年轻代中伊甸园区当前已使用空间（以KB为单位）。
• OC: 老年代（Old Generation）的当前容量（以KB为单位）。
• OU: 老年代当前已使用空间（以KB为单位）。
• MC: 方法区（Metaspace，如果是JDK 8及以上版本）的当前容量（以KB为单位）。
• MU: 方法区当前已使用空间（以KB为单位）。
• CCSC: 压缩类空间（Compressed Class Space）的当前容量（以KB为单位）。
• CCSU: 压缩类空间当前已使用空间（以KB为单位）。
• YGC: 自JVM启动以来发生的年轻代垃圾收集事件的次数。
• YGCT: 年轻代垃圾收集所花费的总时间（以秒为单位）。
• FGC: 自JVM启动以来发生的老年代（Full GC）垃圾收集事件的次数。
• FGCT: 老年代垃圾收集所花费的总时间（以秒为单位）。
• CGC: 自JVM启动以来发生的并发垃圾回收的次数。
• CGCT: 并发垃圾回收所花费的总时间（以秒为单位）。
• GCT: 所有垃圾收集所花费的总时间，包括年轻代和老年代，以及并发垃圾收集的时间。

从给定的输出数据中可以分析得出：

• 幸存区（S0和S1）的容量差异，S0C为0.0，表明该空间当前未被分配，而S1C有分配，且几乎已满（S1U接近S1C）。
• 伊甸园区（EC）有较大容量，且目前EU（使用量）接近EC（容量），表明伊甸园区几乎被填满。
• 老年代（OC）的使用量（OU）也接近其总容量的80%，表明可能需要进行老年代的垃圾收集。
• 方法区（MC和MU）及压缩类空间（CCSC和CCSU）的使用率也相对较高，可能需要关注类加载和元数据的使用。
• 年轻代垃圾收集（YGC）发生了24次，总共耗时约0.387秒，平均每次GC耗时非常短，这是正常的。
• 还没有发生过老年代垃圾收集（FGC），这通常是好事，因为全面垃圾收集（Full GC）会更耗时。
• 并发垃圾回收（CGC和CGCT）发生了4次，总耗时0.013秒，影响很小。
• 所有垃圾收集的总耗时（GCT）为0.401秒，这个时间相对于运行时间来说，如果不是特别长的运行时间，是可以接受的。

这些数据可以用于监控JVM性能和进行调优。如果出现性能问题，可能需要考虑增加堆内存、调整垃圾收集策略或优化应用程序以减少内存使用。

问：我的jvm参数是：-Xms128m -Xmx128m， 根据上述结果，目前程序内存是否够用，需要扩大还是缩小这个参数

答：

根据您提供的垃圾回收统计数据和JVM参数（-Xms128m -Xmx128m，设置了初始堆大小和最大堆大小均为128MB），我们可以进行一些分析：

1. 老年代（OU）接近其容量的80%，这是一个提示内存可能不足的迹象。一旦老年代被填满，会触发Full GC，这会影响应用程序的性能。
2. 伊甸园区（EU）几乎填满，虽然频繁的Young GC是正常的，但如果伊甸园区持续接近满载，可能导致频繁GC，这样会增加GC开销，影响应用性能。
3. 年轻代发生了24次垃圾回收，而老年代尚未发生Full GC，这表示目前的应用内存还没有达到极限，但是已经很接近了。
4. 方法区（MU）和压缩类空间（CCSU）的使用量也相对高，这可能表明类和元数据的内存使用量较大。

基于这些信息，目前的内存设置对于应用程序来说可能是勉强足夠的或不够用的。如果您注意到应用程序的性能不稳定，或者存在延迟和内存溢出的威胁，您应该考虑增加堆内存大小。

在决定是否需要调整JVM参数之前，您还需要考虑以下几点：

• 应用的性能要求：如果性能要求高，您可能需要更多的内存来减少垃圾收集的影响。
• 应用的负载：如果预计负载会增加，或者已经观察到内存使用接近上限，应考虑增加内存。
• 监控数据：长时间的监控数据会提供更准确的内存使用模式，而不是某一个时间点的快照。

如果没有出现性能问题，同时监控数据显示内存使用稳定，在老年代和方法区没有接近极限，那么当前的内存设置可能是合适的。但如果内存经常接近最大值，或者应用经常进行垃圾收集，那么可能需要增加最大堆大小以改善性能。在调整内存之前，确保分析足够的性能监控数据来做出决策。

---

从上面的对话大致可以得出结论，目前128M的内存设置还是稍微小了点，可以考虑扩大一下内存，但是由于目前还没有发生过Full GC，所以可以后续继续观察一段时间，如果频繁发生FULL GC，就需要扩大一下内存的限制了。

下面贴一张JVM内存模型方便对照上面GC数据参考：