当前位置：首页 > news >正文

如何分析 jstat 统计来定位 GC？

news 2025/7/13 8:23:07

全文目录：

- 开篇语
- 前言
- 摘要
- 概述
- jstat 的核心命令与参数详解
- - 基本命令格式
  - 示例
- jstat 输出解读
- - 主要字段含义
- 典型 GC 问题分析案例
- - 案例 1：年轻代 GC 过于频繁
  - 案例 2：老年代发生频繁 Full GC
  - 案例 3：元空间（Metaspace）不足
- 实战案例分享
- - 场景：线上服务响应变慢
- 优缺点分析
- - `jstat` 的优点
  - `jstat` 的缺点
- 核心命令总结
- 小结
- 总结
- 文末

开篇语

哈喽，各位小伙伴们，你们好呀，我是喵手。运营社区：C站/掘金/腾讯云/阿里云/华为云/51CTO；欢迎大家常来逛逛

今天我要给大家分享一些自己日常学习到的一些知识点，并以文字的形式跟大家一起交流，互相学习，一个人虽可以走的更快，但一群人可以走的更远。

我是一名后端开发爱好者，工作日常接触到最多的就是Java语言啦，所以我都尽量抽业余时间把自己所学到所会的，通过文章的形式进行输出，希望以这种方式帮助到更多的初学者或者想入门的小伙伴们，同时也能对自己的技术进行沉淀，加以复盘，查缺补漏。

小伙伴们在批阅的过程中，如果觉得文章不错，欢迎点赞、收藏、关注哦。三连即是对作者我写作道路上最好的鼓励与支持！

前言

在上期文章中，我们深入探讨了 JVM 的垃圾回收器原理，了解了不同 GC 策略（如 Serial、Parallel、G1、ZGC 等）如何通过回收机制提升内存管理的效率。然而，当我们真正面对线上问题时，了解 GC 原理只是第一步，更多的挑战在于如何通过实际工具定位问题。

本期，我们将聚焦于 JVM 性能分析工具之一的 jstat。通过 jstat 工具，我们可以实时监控 JVM 的垃圾回收行为，并结合实际数据深入分析 GC 对性能的影响，进而快速定位问题。

摘要

本文通过理论结合实际的方式，详细解析了如何使用 jstat 工具分析 JVM 垃圾回收行为。我们将讲解 jstat 的核心命令与输出含义，提供多个 GC 场景下的典型案例，并介绍如何通过 jstat 数据解读 JVM 内存使用与 GC 问题。最后，通过实际案例分享，帮助开发者掌握在生产环境中定位 GC 问题的实战技能。

概述

jstat 是 JVM 提供的一款轻量级命令行工具，可用于实时监控 JVM 的内存使用和垃圾回收行为。它可以帮助开发者快速了解以下几个方面：

Heap 内存的分布和使用情况。
GC 的频率、持续时间和停顿时间。
各代内存（年轻代、老年代）的垃圾回收情况。

通过分析 jstat 输出的数据，我们可以有效识别如下问题：

GC 是否频繁触发？
GC 是否导致了较长时间的停顿？
是否存在内存泄漏或内存溢出的风险？

jstat 的核心命令与参数详解

在使用 jstat 工具时，最常用的参数包括以下几类：

参数名	功能描述
`jstat -gc`	监控 GC 的相关统计信息（如各代内存使用情况）。
`jstat -gccapacity`	查看各代内存的容量和分配变化。
`jstat -gcutil`	监控 GC 使用情况百分比（如 Eden、Old、Meta 的使用率）。
`jstat -gccause`	查看最近一次 GC 的触发原因及 GC 类型（如 Minor GC 或 Full GC）。
`jstat -class`	查看 ClassLoader 的加载、卸载统计信息。
`jstat -printcompilation`	查看 JIT 编译的实时信息。

基本命令格式

jstat [option] <pid> [interval] [count]

[option]：指定要显示的统计信息类型（如 -gc）。
<pid>：目标 JVM 进程 ID，可以通过 jps 获取。
[interval]：采样的时间间隔，单位为毫秒。
[count]：采样次数。

示例

查看 JVM 的 GC 情况（每隔 1 秒打印一次，共 10 次）：
```
jstat -gc 12345 1000 10
```
查看内存使用率：
```
jstat -gcutil 12345 1000 5
```

jstat 输出解读

以下是 jstat -gc 的典型输出及其字段解释：

S0C    S1C    S0U    S1U    EC     EU      OC      OU     MC     MU     CCSC   CCSU   YGC    YGCT   FGC    FGCT    GCT
512.0  512.0  256.0  0.0    2048.0 1024.0  8192.0  4096.0 1024.0 768.0  128.0  96.0   10     0.12   3      0.20    0.32

主要字段含义

字段名	含义
`S0C`	Survivor 0 区的容量（单位：KB）。
`S1C`	Survivor 1 区的容量（单位：KB）。
`S0U`	Survivor 0 区的使用量（单位：KB）。
`S1U`	Survivor 1 区的使用量（单位：KB）。
`EC`	Eden 区的容量（单位：KB）。
`EU`	Eden 区的使用量（单位：KB）。
`OC`	Old 区的容量（单位：KB）。
`OU`	Old 区的使用量（单位：KB）。
`MC`	元空间（Metaspace）的容量（单位：KB）。
`MU`	元空间的使用量（单位：KB）。
`CCSC`	压缩类空间（Compressed Class Space）的容量（单位：KB）。
`CCSU`	压缩类空间的使用量（单位：KB）。
`YGC`	Young GC 的次数。
`YGCT`	Young GC 的总时间（单位：秒）。
`FGC`	Full GC 的次数。
`FGCT`	Full GC 的总时间（单位：秒）。
`GCT`	GC 总时间（单位：秒）。

典型 GC 问题分析案例

案例 1：年轻代 GC 过于频繁

现象：
通过 jstat -gc 观察发现，YGC（Young GC 次数）每秒增长 10+ 次，且 YGCT（Young GC 时间）迅速累加。

原因：

Eden 区容量不足，导致对象频繁进入 Survivor 区甚至直接晋升到老年代。
新生对象过多，导致 GC 频率过高。

解决方案：

增加年轻代的容量：
```
-XX:NewSize=512m -XX:MaxNewSize=512m
```
调整 Survivor 区的比例：
```
-XX:SurvivorRatio=8
```

案例 2：老年代发生频繁 Full GC

现象：
通过 jstat -gcutil 观察，OU（Old 区使用率）经常接近 100%，FGC 次数增长迅速。

原因：

老年代的对象无法及时回收，触发 Full GC。
老年代空间分配不足。
存在内存泄漏，导致老年代的对象不断堆积。

解决方案：

增加老年代的容量：
```
-Xmx1024m
```
使用 G1 垃圾回收器，减少 Full GC 的停顿：
```
-XX:+UseG1GC
```

案例 3：元空间（Metaspace）不足

现象：
通过 jstat -gc 观察，MU（元空间使用量）接近 MC（元空间容量），导致 GC 停顿时间较长。

原因：

类加载过多，元空间不足。
内存泄漏导致类未能正确卸载。

解决方案：

增加元空间的大小：

-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m

检查是否存在动态类加载的内存泄漏问题。

实战案例分享

场景：线上服务响应变慢

背景：
某电商系统在促销高峰期，发现响应时间显著增加，部分请求出现超时。

分析步骤：

使用 jps 找到目标进程：
```
jps
```
输出：
```
12345 EcommerceApplication
```
通过 jstat -gc 查看 GC 统计数据：
```
jstat -gc 12345 1000 10
```
输出显示 YGC 每秒增长 15 次，YGCT 累积时间较长。
使用 jstat -gcutil 查看内存使用率：
```
jstat -gcutil 12345 1000 10
```
发现年轻代使用率接近 100%，Eden 区频繁触发 Minor GC。

解决方案：

增加年轻代的容量：
```
-XX:NewSize=1g -XX:MaxNewSize=1g
```
调整 JVM 参数，切换到 G1 回收器：
```
-XX:+UseG1GC
```

优缺点分析

`jstat` 的优点

轻量级：无需复杂的配置即可实时监控。
实时性强：可以直接观测 JVM 的内存和 GC 情况。
广泛适用：适用于几乎所有 JVM。

`jstat` 的缺点

数据颗粒度有限：无法直接分析对象级别的分布情况。
依赖命令行：对数据的可视化能力较弱。

核心命令总结

命令	功能描述
`jstat -gc`	查看 GC 的内存使用情况和 GC 次数。
`jstat -gcutil`	查看内存使用率（以百分比表示）。
`jstat -gccause`	查看最近一次 GC 的原因。
`jstat -gccapacity`	查看各代容量的变化情况。
`jstat -printcompilation`	查看 JIT 编译的实时情况。