jstat简介
jstat（JVM Statistics Monitoring Tool）：用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。
option参数如下：
| 类型 | 内容 | 说明 |
|---|---|---|
| 类装载相关 | -class | 显示ClassLoader的相关信息:类的装载卸载数量、总空间、类装载消耗的时间等 |
| 垃圾回收相关 | -gc | 显示与GC相关的堆信息。包括Eden区、两个Survivor区、老年代、永久代等的容量、已用空间、GC时间合计等信息。 |
| -gccapacity- | 显示内容与-gc基本相同，但输出主要关注Java堆各个区域使用到的最大、最小空间 | |
| -gcutil | 显示内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比 | |
| -gccause | 与-gcutil功能一样，但是会额外输出导致最后一次或当前正在发生的GC产生的原因 | |
| -gcnew | 显示新生代GC状况 | |
| -gcnewcapacity | 显示内容与-gcnew基本相同，输出主要关注使用到的最大、最小空间 | |
| -gcold | 显示老年代GC状况 | |
| -gcoldcapacity | 显示内容与-gcold基本相同，输出主要关注使用到的最大、最小空间 | |
| -gcpermcapacity | 显示永久代使用到的最大、最小空间 | |
| JIT相关 | -compiler | 显示JIT编译器编译过的方法、耗时等信息 |
| -printcompilation | 输出已经被JIT编译的方法 |
jstat使用
1）统计类加载信息
[root@bogon ~]# jps -l
781 sun.tools.jps.Jps
25887 org.apache.catalina.startup.Bootstrap
[root@bogon ~]# jstat -class 25887
Loaded Bytes Unloaded Bytes Time
3377 6492.3 37 53.6 30.34
| 内容 | 说明 |
|---|---|
| Loaded | 已加载的class数量 |
| Bytes | 已加载的class占用空间大小 |
| Unloaded | 未加载的class数量 |
| Bytes | 未加载的class占用空间大小 |
| Time | 类加载耗时 |
间隔1s打印5次
输出程序执行时间
jstat -class -t 25887 1000 5
每隔3次打印一次表头
jstat -class -h 3 -t 25887 1000
2）查看JIT编译统计
[root@bogon ~]# jps -l
8264 sun.tools.jps.Jps
7706 ParamTest.jar
25887 org.apache.catalina.startup.Bootstrap
[root@bogon ~]# jstat -compiler 7706
Compiled Failed Invalid Time FailedType FailedMethod
10 0 0 0.00 0
| 内容 | 说明 |
|---|---|
| Compiled | JIT编译的class数量 |
| Failed | JIT编译失败的数量 |
| Invalid | 不可用数量 |
| Time | 时间 |
| FailedType | 失败类型 |
| FailedMethod | 失败方法 |
jstat -printcompilation 7706
3）垃圾回收统计
垃圾统计简单介绍
[root@bogon ~]# jstat -gc 25887
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
2880.0 2880.0 0.0 548.0 23552.0 8410.8 58488.0 41320.5 21632.0 20846.0 2432.0 2221.7 215 1.416 3 0.247 1.663
| 内容 | 说明 |
|---|---|
| S0C | 第一个Survivor区的大小（KB） |
| S1C | 第二个Survivor区的大小（KB） |
| S0U | 第一个Survivor区的使用大小（KB） |
| S1U | 第二个Survivor区的使用大小（KB） |
| EC | Eden区的大小（KB） |
| EU | Eden区的使用大小（KB） |
| OC | Old区的大小（KB） |
| OU | Old区的使用大小（KB） |
| MC | 方法区的大小（KB） |
| MU | 方法区的使用大小（KB） |
| CCSC | 压缩类的空间大小（KB） |
| CCSU | 压缩类的空间使用大小（KB） |
| YGC | 年轻代垃圾回收次数 |
| YGCT | 年轻代垃圾回收消耗时间 |
| FGC | 老年代垃圾回收次数 |
| FGCT | 老年代垃圾回收消耗时间 |
| GCT | 总的垃圾回收消耗时间 |
oracle官方文档：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc-ergonomics.html
默认堆大小
在没有指定堆内存大小时，默认堆内存为物理内存的1/64，最大堆内存为物理机内存的1/4或1G。
关于元空间需要注意：元空间会自动扩容，默认情况下不受限制。
[root@bogon ~]# jstat -gc 6619
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
1024.0 1024.0 0.0 0.0 8192.0 672.0 20480.0 0.0 4480.0 774.5 384.0 75.9 0 0.000 0 0.000 0.000
[root@bogon ~]# jinfo -flag InitialHeapSize 6619
-XX:InitialHeapSize=31457280
百分比显示GC使用信息
如何判断可能出现的OOM？
我们可以比较Java进程的启动时间以及总GC时间（GCT列），或者两次测量的间隔时间以及总GC时间的增量，来得出GC时间占运行时间的比例。
如果该比例超过20%，则说明目前堆的压力较大；
如果该比例超过90%，则说明堆里几乎没有可用空间，随时都可能抛出OOM异常。
如何判断可能存在的内存泄露？
第1步：在长时间运行的Java程序中，我们可以运行jstat命令连续获取多行性能数据，并取这几行数据中OU列（即已占用的老年代内存）的最小值。
第2步：然后，我们每隔一段较长的时间重复一次上述操作，来获得多组OU最小值。如果这些值呈上涨趋势，则说明该Java程序的老年代内存已使用率在不断上涨，这意味着无法回收的对象在不断增加，因此很有可能存在内存泄露。