要使用jstat监控jvm，首先通过jps获取进程id，然后执行jstat命令并指定监控类型、采样间隔和次数。1）常用选项包括-gcutil查看垃圾回收利用率统计；2）-gc查看更详细的垃圾回收信息；3）-class监控类加载与卸载情况。例如：jstat -gcutil 1234 1000可每秒输出进程1234的gc利用率数据。通过观察老年代使用率（o）、full gc频率（fgc）等指标，可判断是否存在内存泄漏或性能瓶颈。诊断时若发现老年代持续增长且无法回收，可能表明存在内存泄漏，需结合jmap、jconsole等工具进一步分析。虽然jstat功能强大，但其无法查看历史数据、不能定位具体代码问题，通常需配合prometheus、grafana等工具构建完整监控体系。此外，频繁使用jstat对jvm性能影响较小，但仍建议合理设置采样间隔以减少开销。
Java中jstat是一个强大的JVM监控工具，它能帮助我们了解JVM的各种性能指标，比如堆内存使用情况、垃圾回收频率等等。掌握jstat的用法，对排查Java应用的性能问题至关重要。
jstat命令可以用来监视Java虚拟机（JVM）的各种统计信息。它特别擅长于跟踪垃圾收集活动，内存使用情况，以及类加载和卸载的统计数据。通过分析这些数据，开发者可以诊断内存泄漏，优化垃圾收集策略，并识别其他潜在的性能瓶颈。
如何使用jstat监控JVM？
jstat的基本语法是 jstat [options] vmid [interval] [count]。
立即学习“Java免费学习笔记（深入）”；
-
options：指定要监控的统计类型，例如-gcutil、-gc、-class等等。 -
vmid：目标JVM的进程ID。可以使用jps命令找到。 -
interval：采样间隔，单位是毫秒。 -
count：采样次数。如果省略，则会持续采样。
举个例子，如果我们想每秒钟查看一次进程ID为1234的JVM的垃圾回收情况，可以这样写：jstat -gcutil 1234 1000。
jstat -gcutil：最常用的垃圾回收统计
-gcutil选项可能是jstat最常用的了。它会显示各个代的内存使用百分比，以及垃圾回收的次数和时间。
输出的列包括：
-
S0：Survivor 0区已使用空间的百分比。 -
S1：Survivor 1区已使用空间的百分比。 -
E：Eden区已使用空间的百分比。 -
O：老年代已使用空间的百分比。 -
M：元空间已使用空间的百分比。 -
CCS：压缩类空间已使用空间的百分比。 -
YGC：年轻代垃圾回收的次数。 -
YGCT：年轻代垃圾回收消耗的时间。 -
FGC：Full GC的次数。 -
FGCT：Full GC消耗的时间。 -
GCT：总的垃圾回收消耗的时间。
通过观察这些指标，我们可以判断垃圾回收是否频繁，以及哪一代的内存压力比较大。如果发现Full GC非常频繁，那可能就需要调整堆内存的大小，或者优化代码，减少对象的创建。
jstat -gc：更详细的垃圾回收信息
-gc选项提供比-gcutil更详细的垃圾回收信息，包括各个代的容量、已使用空间、以及垃圾回收前后的大小变化。
输出的列非常多，这里列出几个关键的：
-
NGCMN：年轻代(new generation)最小容量 -
NGCMX：年轻代最大容量 -
NGC：年轻代当前容量 -
S0C：第一个幸存区(Survivor 0)容量 -
S1C：第二个幸存区(Survivor 1)容量 -
EC：Eden区容量 -
OGCMN：老年代(old generation)最小容量 -
OGCMX：老年代最大容量 -
OGC：老年代当前容量 -
OC：老年代已使用容量 -
MC：元空间容量 -
YGC：年轻代垃圾回收次数 -
FGC：Full GC次数
-gc输出的信息量很大，初学者可能会觉得难以理解。建议先从-gcutil开始，掌握基本的垃圾回收概念，再逐步深入学习-gc。
jstat -class：类加载和卸载统计
-class选项可以用来监控类加载和卸载的情况。
云点滴客户解决方案是针对中小企业量身制定的具有简单易用、功能强大、永久免费使用、终身升级维护的智能化客户解决方案。依托功能强大、安全稳定的阿里云平 台，性价比高、扩展性好、安全性高、稳定性好。高内聚低耦合的模块化设计，使得每个模块最大限度的满足需求，相关模块的组合能满足用户的一系列要求。简单 易用的云备份使得用户随时随地简单、安全、可靠的备份客户信息。功能强大的报表统计使得用户大数据分析变的简单，
输出的列包括：
-
Loaded：加载的类的数量。 -
Bytes：加载的类的总大小。 -
Unloaded：卸载的类的数量。 -
Bytes：卸载的类的总大小。 -
Time：加载和卸载类所消耗的时间。
如果发现加载的类很多，但卸载的类很少，那可能存在类加载器泄漏的问题。
案例分析：使用jstat诊断内存泄漏
假设我们的Java应用出现了OOM（OutOfMemoryError）错误。我们可以使用jstat来诊断是否发生了内存泄漏。
- 首先，使用
jps找到应用的进程ID。 - 然后，使用
jstat -gcutil命令，每秒钟查看一次垃圾回收情况。1000 - 观察老年代的使用百分比（
O列）。如果老年代的使用百分比持续增长，并且Full GC的频率也很高，但老年代的使用率仍然降不下来，那很可能存在内存泄漏。
接下来，我们可以使用其他的工具，比如jmap或jconsole，来进一步分析堆内存中的对象，找出泄漏的对象。
jstat命令的局限性
jstat虽然强大，但也存在一些局限性：
- 它只能监控正在运行的JVM，无法查看历史数据。
- 它只能提供统计信息，无法定位到具体的代码。
- 它的输出结果比较原始，需要一定的经验才能分析。
因此，在实际工作中，我们通常会结合其他的监控工具，比如Prometheus、Grafana等，来构建更完善的监控体系。
jstat如何影响JVM性能？
频繁地执行jstat命令会对JVM性能产生一定的影响，因为它需要收集和计算各种统计信息。但是，这种影响通常是很小的，可以忽略不计。
为了减少影响，可以适当调整采样间隔和采样次数。例如，可以将采样间隔设置为5秒或10秒，而不是1秒。
如何在生产环境中使用jstat？
在生产环境中，我们通常不会直接在命令行中使用jstat。而是会将jstat集成到监控系统中，定期采集数据，并进行分析和报警。
可以使用一些开源的监控工具，比如Prometheus，来采集jstat的数据。然后，使用Grafana来可视化这些数据。
除了jstat，还有哪些JVM监控工具？
除了jstat，Java还提供了许多其他的JVM监控工具，比如：
- jps：查看Java进程。
- jinfo：查看JVM配置信息。
- jmap：生成堆转储快照。
- jstack：生成线程转储快照。
- jconsole：图形化的监控工具。
- VisualVM：功能更强大的图形化监控工具。
选择合适的工具，取决于具体的监控需求。
