jstat 是快速诊断 jvm gc 问题的核心工具：用 -gc 查频率与耗时，-gcutil 看内存使用趋势，-gccause 定位触发原因；远程监控需配置 jstatd 和正确网络解析。

直接看关键数字，不用等报表或图形界面——jstat 就是最快最准的入口。

用 jstat -gc 实时抓核心 GC 频率与耗时

运行 jstat -gc 1000 5（每秒一次，共5次），重点关注这几列：

• YGC / YGCT：年轻代 GC 次数和总耗时（秒）。YGC 超过 10 次/秒且 YGCT 持续上升，说明 Eden 区太小或对象存活时间偏长
• FGC / FGCT：Full GC 次数和总耗时。只要 FGC 数值在增长，就要立刻查原因——不是元空间打满、就是大对象直入老年代、或是 CMS 失败触发的兜底回收
• GCT：所有 GC 总耗时。除以总运行时间就是 GC 吞吐量，低于 95% 就算异常

用 jstat -gcutil 看内存区域使用率变化趋势

jstat -gcutil 2000 每2秒输出一行汇总数据，更聚焦利用率：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• E 列（Eden）：持续接近 100% 且不下降 → 对象分配快，或 Survivor 区太小导致对象提前晋升
• O 列（老年代）：缓慢但稳定上升 + FGC 增加 → 典型老年代泄漏信号，配合 jmap -histo 查长生命周期对象
• M 列（元空间）：持续上涨且 unloaded 类数几乎为 0 → 类加载器未释放，常见于 Spring Boot DevTools、MyBatis Mapper 动态代理等场景

加 -gccause 定位每次 GC 的真实触发原因

jstat -gccause 1000 输出中，“LGCC” 和 “LGCT” 是上一次 GC 的原因和耗时，比单纯看次数更有诊断价值：

• Allocation Failure：最常见，说明 Eden 满了；但如果频繁出现，说明新生代配置不合理
• Metadata GC Threshold：元空间达到阈值，该调 -XX:MaxMetaspaceSize 或查类泄漏
• System.gc()：代码里写了显式 GC 调用，生产环境应禁用 -XX:+DisableExplicitGC

远程多机批量监控要先配好 jstatd

想从一台机器看多台服务器的 JVM 状态，不能只靠本地 jstat：

• 每台目标机必须启动 jstatd，并指定安全策略文件（grant codebase "file:${java.home}/../lib/tools.jar"）
• 确保 hostname -i 返回真实内网 IP，否则连接会超时或拒绝
• 本地执行类似 jstat -gcutil 12345@10.1.2.101:1099 2000，就能拿到远程数据，指标含义和本地完全一致

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南