1. 为什么需要关注JVM的GC性能？
如果你负责的Java应用突然出现周期性卡顿，用户投诉页面加载变慢，而服务器CPU和内存看起来都正常，这时候很可能是垃圾回收（GC）出了问题。我遇到过不少这样的情况：明明堆内存还剩不少，但Full GC却频繁触发，导致应用响应时间从200ms飙升到5秒以上。
GC就像是个隐形的性能杀手，它会在你不注意的时候悄悄吃掉应用的吞吐量。而jstat就是JDK自带的"听诊器"，能帮你实时监控JVM的内存和GC状况。不同于需要提前配置的GC日志，jstat可以直接连接运行中的JVM进程，零成本获取关键指标。
2. jstat基础：如何快速上手？
2.1 基本命令格式
先通过jps找到目标Java进程的PID：
jps -l然后使用这个基础命令模板：
jstat -<option> <PID> [间隔时间(ms)] [采样次数]比如要每5秒监控一次GC情况，共采集20次：
jstat -gcutil 12345 5000 202.2 关键监控选项对比
| 选项 | 监控重点 | 典型使用场景 |
|---|---|---|
| -gc | 各区域容量和使用量(KB) | 内存泄漏初步排查 |
| -gcutil | 各区域使用百分比 | 快速评估内存压力 |
| -gccause | 同gcutil+最近GC原因 | 诊断突发GC问题 |
| -gcnew | 新生代详细统计 | Young GC频繁问题分析 |
| -gcold | 老年代和元空间统计 | Full GC问题分析 |
3. 实战诊断：从指标到问题定位
3.1 识别内存泄漏的典型模式
这是我最近排查的一个线上案例，应用每隔几小时就会卡顿一次。使用以下命令采集数据：
jstat -gcutil -t 54321 30s输出示例（关键部分）：
Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 45.2 0.00 50.32 82.15 45.67 95.21 90.18 120 1.892 3 0.543 2.435 75.3 0.00 50.32 92.33 63.41 95.21 90.18 120 1.892 4 0.843 2.735 105.4 0.00 50.32 78.56 78.95 95.21 90.18 120 1.892 5 1.243 3.135发现三个危险信号：
- 老年代使用率(O)持续上升(45%→78%)
- 每次Full GC后老年代空间没有明显释放
- 年轻代GC(YGC)次数停滞但老年代GC(FGC)持续增加
这典型是内存泄漏的表现——对象不断从年轻代晋升到老年代，但无法被回收。
3.2 诊断元空间溢出
另一个常见问题是元空间(Metaspace)膨胀：
Timestamp S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 32.1 99.67 0.00 34.21 25.67 99.98 95.21 42 0.521 1 0.231 0.752当M列接近100%时，说明元空间即将耗尽，会触发Full GC。这种情况通常需要调整：
-XX:MaxMetaspaceSize=256M4. 高级技巧：动态追踪GC问题
4.1 使用时间戳(-t)建立时间轴
在命令中加入-t参数：
jstat -gcutil -t 54321 1s输出会多出第一列时间戳（JVM启动后的秒数），这样就能：
- 计算GC发生的精确时间间隔
- 关联系统监控数据（如CPU飙升时间点）
- 绘制内存使用趋势图
4.2 结合-gccause分析GC根因
当发现异常GC时，立即运行：
jstat -gccause 54321 3s 5输出中的LGCC(上次GC原因)和GCC(当前GC原因)会显示如：
- "Allocation Failure"：年轻代空间不足
- "Metadata GC Threshold"：元空间不足
- "System.gc()"：有人调用了显式GC
5. 调优建议：从诊断到行动
5.1 年轻代优化方案
当Young GC频繁(YGC数值增长快)时：
# 增加年轻代大小（默认约占堆1/3） -Xmn512M # 调整Survivor区比例（-XX:SurvivorRatio=8表示Eden:Survivor=8:1:1） -XX:SurvivorRatio=65.2 老年代优化方案
针对Full GC问题：
# 使用G1垃圾回收器（JDK9+默认） -XX:+UseG1GC # 或者CMS回收器（JDK8推荐） -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=705.3 避免常见陷阱
- 不要过度调优：先确保真的有GC问题，再调整参数
- 监控长期效果：任何参数调整后至少要观察24小时
- 注意系统资源：增加堆内存可能引发swap使用，反而降低性能
曾经有个电商网站在大促前盲目把堆内存从4G调到8G，结果因为物理内存不足导致频繁swap，最终GC时间反而增加了3倍。后来我们用jstat发现实际堆使用峰值只有3.5G，回调到4G并改用G1GC后问题解决。
记住，jstat数据要结合业务场景看——比如秒杀场景下Young GC频率高点可能是正常的，关键是要保证单次GC停顿时间可控。建议把jstat监控集成到日常运维中，建立基线数据，这样遇到问题时才有比较基准。
