java 性能分析工具jstat讲解

常用命令：

在JDK的bin目彔下,包含了java命令及其他实用工具。

jps:查看本机的Java中进程信息。

jstack:打印线程的栈信息,制作线程Dump。

jmap:打印内存映射,制作堆Dump。

jstat:性能监控工具。

jhat:内存分析工具。

jconsole:简易的可视化控制台。

jvisualvm:功能强大的控制台。

每一列都代表了一个不同的统计信息，如下所示：

S0C、S1C、S0U、S1U：Survivor 0和Survivor 1区域的当前容量（C）和使用量（U），单位是KB。
EC、EU：Eden区的当前容量（C）和使用量（U），单位是KB。
OC、OU：Old区的当前容量（C）和使用量（U），单位是KB。
MC、MU：Metaspace区的当前容量（C）和使用量（U），单位是KB。
CCSC、CCSU：压缩类空间的当前容量（C）和使用量（U），单位是KB。
YGC、YGCT：Young区的垃圾收集次数（GC）和总耗时（GCT），单位是秒。
FGC、FGCT：Full GC的次数（GC）和总耗时（GCT），单位是秒。
GCT：总的垃圾收集耗时，单位是秒。

通过这些数据，我们可以观察到应用程序的垃圾收集行为，如垃圾收集的频率、耗时，以及各个内存区域的使用情况。这将帮助我们更好地理解和优化应用程序的性能。

需要注意的是，jstat提供的是实时的性能数据，每次运行jstat时，都会获取最新的数据。因此，如果你想要持续监控应用程序的性能，你可以设置一个较小的采样间隔，或者在一个无限循环中运行jstat命令。

jstat -gc 1 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT CGC CGCT GCT 
0.0 4096.0 0.0 4096.0 309248.0 236544.0 183296.0 125409.0 140168.0 135553.7 15488.0 13814.7 236 3.545 0 0.000 12 0.188 3.733

命令 jstat -gc 1 表示每隔1毫秒就输出一行结果。

第一行表示在应用程序启动后第一次采样时，各个内存区域和垃圾回收的情况。

例如，你可以看到：

S0C是0.0，表示survivor space 0没有分配任何空间
S1C是4096.0，表示survivor space 1分配了4096 KB的空间
S0U是0.0，表示survivor space 0没有使用任何空间
S1U是4096.0，表示survivor space 1已经使用了全部空间
EC是309248.0，表示eden space分配了309248 KB的空间
EU是236544.0，表示eden space已经使用了236544 KB的空间
OC是183296.0，表示old space分配了183296 KB的空间
OU是125409.0，表示old space已经使用了125409 KB的空间
MC是140168.0，表示metaspace分配了140168 KB的空间
MU是135553.7，表示metaspace已经使用了135553.7 KB的空间
CCSC是15488.0，表示compressed class space分配了15488 KB的空间
CCSU是13814.7，表示compressed class space已经使用了13814.7 KB的空间
YGC是236，表示从应用程序启动到采样时发生了236次young generation垃圾回收
YGCT是3.545，表示从应用程序启动到采样时young generation垃圾回收花费了3.545秒
FGC是0，表示从应用程序启动到采样时没有发生full GC
FGCT是0.000，表示从应用程序启动到采样时full GC花费了0秒
CGC是12，表示从应用程序启动到采样时发生了12次concurrent GC
CGCT是0.188，表示从应用程序启动到采样时concurrent GC花费了0.188秒
GCT是3.733，表示从应用程序启动到采样时垃圾回收花费了总共3.733秒

根据，jstat -gc命令返回的结果可以用来监控Java虚拟机的内存区域和垃圾回收的情况。你可以通过以下几个方面来分析这些结果：

内存区域的容量和使用率：你可以通过比较各个内存区域（eden, survivor, old, metaspace, compressed class space）的容量（C）和使用空间（U）来判断内存是否充足，是否有内存泄漏的风险，是否需要调整内存参数。

一般来说，如果某个内存区域的使用率（U/C）接近或超过100%，就说明该区域可能不够用，需要增加容量或者优化代码。

例如，你可以看到在第一次采样时，survivor space 1的使用率是100%，eden space的使用率是76.5%，old space的使用率是68.4%，metaspace的使用率是96.7%，compressed class space的使用率是89.2%。这些都是比较高的使用率，可能会导致频繁或者长时间的垃圾回收。

垃圾回收的次数和时间：你可以通过比较不同类型的垃圾回收（young generation, full GC, concurrent GC）发生的次数（GC）和花费的时间（GCT）来判断垃圾回收是否频繁，是否影响应用程序的性能，是否需要调整垃圾回收器或者参数。

一般来说，如果某种类型的垃圾回收发生的次数过多或者花费的时间过长，就说明该类型的垃圾回收可能存在问题，需要优化。

例如，你可以看到在第一次采样时，young generation垃圾回收发生了236次，花费了3.545秒；full GC 发生了0次，花费了0秒；concurrent GC发生了12次，花费了0.188秒。这些数据表明young generation垃圾回收比较频繁，可能是因为eden space或者survivor space不够用；full GC没有发生，可能是因为old space还有一定空间；concurrent GC发生了一些次数，但是花费的时间不多，可能是因为metaspace或者compressed class space还有一些空间。