Jstat命令解析

Jstat是JDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”，它位于java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。

使用时，需加上查看进程的进程id，和所选参数。参考格式如下：jstat -options

jstat -options

-class (类加载器)显示ClassLoad的相关信息

-compiler (JIT)显示JIT编译的相关信息

-gc (GC堆状态)显示和gc相关的堆信息

-gccapacity (各区大小)显示各个代的容量以及使用情况

-gccause 显示垃圾回收的相关信息（同-gcutil）,同时显示最后一次或当前正在发生的垃圾回收的诱因；

-gcmetacapacity 显示metaspace的大小

-gcnew 显示新生代信息

-gcnewcapacity显示新生代大小和使用情况

-gcold 显示老年代和永久代的信息

-gcoldcapacity 显示老年代的大小

-gcutil显示垃圾收集信息

-printcompilation输出JIT编译的方法信息

示例一：-class

显示加载class的数量，及所占空间等信息。

jstat -class <pid>

下面对返回的参数做了详解

Loaded —已经装载的类的数量

Bytes — 装载类所占用的字节数

Unloaded —已经卸载类的数量

Bytes —卸载类的字节数

Time —装载和卸载类所花费的时间

示例二： -compiler

显示VM实时编译(JIT)的数量等信息。

jstat -compiler <pid>

下面对返回的参数做了详解

Compiled —编译任务执行数量

Failed —编译任务执行失败数量

Invalid —编译任务执行失效数量

Time —编译任务消耗时间

FailedType —最后一个编译失败任务的类型

FailedMethod —最后一个编译失败任务所在的类及方法

示例三： -gc

显示gc相关的堆信息，查看gc的次数，及时间。

jstat –gc <pid>

下面对返回的参数做了详解

S0C —年轻代中第一个survivor（幸存区）的容量（字节）

S1C—年轻代中第二个survivor（幸存区）的容量 (字节)

S0U —年轻代中第一个survivor（幸存区）目前已使用空间 (字节)

S1U —年轻代中第二个survivor（幸存区）目前已使用空间 (字节)

EC —年轻代中Eden（伊甸园）的容量 (字节)

EU —年轻代中Eden（伊甸园）目前已使用空间 (字节)

OC —Old代的容量 (字节)

OU —Old代目前已使用空间 (字节)

MC —metaspace(元空间)的容量 (字节)

MU —metaspace(元空间)目前已使用空间 (字节)

YGC —从应用程序启动到采样时年轻代中gc次数

YGCT —从应用程序启动到采样时年轻代中gc所用时间(s)

FGC —从应用程序启动到采样时old代(全gc)gc次数

FGCT —从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT —从应用程序启动到采样时gc用的总时间(s)

备注：只展示后几位

jstat -gc 39557 2s 10 |awk '{print $13,$14,$15,$16,$17}'

示例四：-gccause

jstat -gccause PID

查看当前jvm的GC情况

下面对返回的参数做了详解

S0 — Heap上的 Survivor space 0 区已使用空间的百分比

S1 — Heap上的 Survivor space 1 区已使用空间的百分比

E   — Heap上的 Eden space 区已使用空间的百分比

O   — Heap上的 Old space 区已使用空间的百分比

P   — Perm space 区已使用空间的百分比

YGC — 从应用程序启动到采样时发生 Young GC 的次数

YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)

FGC — 从应用程序启动到采样时发生 Full GC 的次数

FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)

GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)

LGCC — 上次GC的原因

GCC — 当前GC的原因

示例五：-gcutil

jstat -gcutil 39557 2s 3

使用 jstat -gcutil ${pid} 2s 每隔一秒打印一次 GC 统计信息，统计3次。

下面对返回的参数做了详解

S0 —年轻代中第一个survivor（幸存区）已使用的占当前容量百分比

S1 —年轻代中第二个survivor（幸存区）已使用的占当前容量百分比

E —年轻代中Eden（伊甸园）已使用的占当前容量百分比

O —old代已使用的占当前容量百分比

P —perm代已使用的占当前容量百分比

YGC —从应用程序启动到采样时年轻代中gc次数

YGCT —从应用程序启动到采样时年轻代中gc所用时间(s)

FGC —从应用程序启动到采样时old代(全gc)gc次数

FGCT —从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT —从应用程序启动到采样时gc用的总时间(s)

其他可参考：jstat命令详解[通俗易懂]-腾讯云开发者社区-腾讯云

示例六：查看JVM中堆内存使用情况

jmap -heap 进程号

通过jmap -heap 进程号查看堆默认分配情况为

最大堆内存为1024MB、新生代分配大小：341MB。
Eden区：340MB
From区、To区：0.5MB
OLd区：683MB

参考：https://www.jianshu.com/p/67a0c4a7b955

Jstat的实践

0、查询进程号

$jps

或ps -ef |grep jar

1、#查询使用空间百分比(-gccause 或-gcutil都可以)

jstat -gccause PID 2s 3

每隔2s输出当前jvm的GC情况，总共输出3次，主要查询使用空间百分比

YGC:848

YGCT:10.824s (单位为秒)

FGC:3次

FGCT:0.912 (单位为秒)

解析：

YGC —从应用程序启动到采样时年轻代中gc次数

YGCT —从应用程序启动到采样时年轻代中gc所用时间(s)

FGC —从应用程序启动到采样时old代(全gc)gc次数

FGCT —从应用程序启动到采样时old代(全gc)gc所用时间(s)

2、#查询当前jvm使用情况

jstat -gc PID

YGC:847

YGCT:10.812s (单位为秒)

FGC:3次

FGCT:0.912 (单位为秒)

解析：

YGC —从应用程序启动到采样时年轻代中gc次数

YGCT —从应用程序启动到采样时年轻代中gc所用时间(s)

FGC —从应用程序启动到采样时old代(全gc)gc次数

FGCT —从应用程序启动到采样时old代(全gc)gc所用时间(s)

3、查看下进程的运行时间

ps -p pid -o etime

4、如何确认你JVM的YGC是否合适？

两个维度：单位时间执行次数和执行时间(GC耗时)

(1-2命令中一个和3命令结合使用)

单位时间执行次数(YGC频率)：

计算公式：3的命令得出的时间/YGC，(8*60+32)*60/847=36秒

结论：可以看到该进程总共运行8个多小时，前面的截图可以看到YGC了847次，平均每36秒YGC一次，是健康的GC频次。

执行时间(YGC耗时)：

计算公式：YGCT/YGC，平均每次YGC花费12.76毫秒（10.812(s)/847=12.76ms）

结论：单次Young GC平均耗时12.76ms左右，是健康的GC耗时。

备注：

如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化；如果单次GC耗时超过1〜3 秒，或者频繁G C ,则必须优化。

如果满足下面的指标，则一般不需要进行GC:
■YoungGC频次不超过3秒/次。(经验值3秒~10秒/次都是比较合理的YGC频率,10秒以上比较空闲)

■每次YoungGC时间不超过15mss;
■ Full GC执行时间不到1s;

■ Full GC 频率多高

看这个频率和看YoungGC的频率是一样的，可以看高峰时期某几次的平均值。这个Full GC是很耗时的，Full GC的频率我们最好控制在一天1次或者几天一次的范围。特别是对时效性要求比较高的系统，一定要减少Full GC次数。

参考：

【3s一次YoungGC的频率，甚至频率更低，5s一次，7s一次，这是正常的；

如果超过1s一次YoungGC的频率，0.5s一次YGC(GC比较频繁，那么Yong GC对系统响应的压力就比较明显了)，

那你可以尝试优化JVM参数或增加服务器配置了。】

其他参考：YoungGC频次不超过3秒/次

如果YGC频率远高于这个值，例如20秒/次，30秒/次，甚至60秒/次，这种情况下，说明JVM相当空闲，处于基本上无事可做的状态。建议缩容，减少服务器浪费；

如果YoungGC频率远低于这个值，例如1秒/次，甚至1秒/好多次，这种情况下，JVM相当繁忙，建议follow如下步骤进行初步症断：

检查Young区，Young区在整个堆占比在25%~40%比较合理，如果Young区太小，建议扩大Xmn。

检查SurvivorRatio，保持默认值8即可，Eden:S0:S1=8:1:1是一个比较合理的值；

参考：https://blog.csdn.net/msbjyJava/article/details/106547105

学习参考：https://blog.csdn.net/qq_39002724/article/details/112338766

https://blog.csdn.net/Qgwperfect/article/details/108089353

JVM其他参数介绍：

常用的参数介绍：

-Xms512m 设置JVM促使内存为512m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。

-Xmx512m ，设置JVM最大可用内存为512M。

-Xmn200m：设置年轻代大小为200M。此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是（eden+1 survivor space）不同的。

计算公式有：

年老代大小=-Xmx减去-Xmn

整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。

持久代一般固定大小为64m，所以增大年轻代（-Xmn）后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。

-XX:SurvivorRatio

用于设置Eden和其中一个Survivor的比值，默认比例为8（Eden）：1（一个survivor），这个值也比较重要。

例如：–XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6。

-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

-Xloggc:file

与-verbose:gc功能类似，只是将每次GC事件的相关情况记录到一个文件中，文件的位置最好在本地，以避免网络的潜在问题。

若与verbose命令同时出现在命令行中，则以-Xloggc为准。

-Xprof

跟踪正运行的程序，并将跟踪数据在标准输出输出；适合于开发环境调试。

-Xrunhprof

-Xdebug:JVM调试参数，用于远程调试

例如在tomcat中的远程调试设置方法为-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

-Xbootclasspath:

-Xbootclasspath用来指定你需要加载，但不想通过校验的类路径。JVM 会对所有的类在加载前进行校验并为每个类通过一个int数值来应用。这个是保证 JVM稳定的必要过程，但比较耗时，如果你希望跳过这个过程，就把你的类通过这个参数来指定。-Xbootclasspath参数、java -jar参数运行应用时classpath的设置方法

-Xnoclassgc：

-Xnoclassgc 表示不对方法区进行垃圾回收。请谨慎使用。见GC 的算法分析、各类垃圾收集器介绍

-XX:MaxMetaspaceSize

java8中-XX:MaxMetaspaceSize=10M设置MetaSpace的最大值为10m。默认是Java的Metaspace空间：不受限制

参考：https://cloud.tencent.com/developer/article/2063186