JVM-jstat使用及分析思路

青旅半醒 2022-10-12 15:53 178阅读 0赞

## 一.jstat的命令使用 ##

在window上找到jdk的安装路径在bin目录中打开win的cmd

**通过jps命令查看本机jvm进程**

![20210705140121784.png][]

**通过 jstat -gc PID  查看Java进程（其实本质就是一个JVM）的内存和GC情况**

![20210705140219826.png][]

各参数介绍：

> S0C：这是From Survivor区的大小  
> S1C：这是To Survivor区的大小  
> S0U：这是From Survivor区当前使用的内存大小  
> S1U：这是To Survivor区当前使用的内存大小  
> EC：这是Eden区的大小  
> EU：这是Eden区当前使用的内存大小  
> OC：这是老年代的大小  
> OU：这是老年代当前使用的内存大小  
> MC：这是方法区（永久代、元数据区）的大小
> 
> MU：这是方法区（永久代、元数据区）的当前使用的内存大小  
> YGC：这是系统运行迄今为止的Young GC次数  
> YGCT：这是Young GC的耗时  
> FGC：这是系统运行迄今为止的Full GC次数  
> FGCT：这是Full GC的耗时  
> GCT：这是所有GC的总耗时

**其他命令介绍：**

> jstat -gccapacity PID：堆内存分析  
> jstat -gcnew PID：年轻代GC分析，这里的TT和MTT可以看到对象在年轻代存活的年龄和存活的最大年龄  
> jstat -gcnewcapacity PID：年轻代内存分析  
> jstat -gcold PID：老年代GC分析  
> jstat -gcoldcapacity PID：老年代内存分析  
> jstat -gcmetacapacity PID：元数据区内存分析

通过命令获取新生代对象增长的速率，Young GC的触发频率，Young GC的耗时，每次Young GC后有多少对象是存活下来的，每次Young GC过后有多少对象进入了老年代，老年代对象增长的速率，Full GC的触发频率，Full GC的耗时，根据这些信息合理分配内存空间，**尽可能让对象留在年轻，代不进入老年代，避免发生频繁的Full GC**。

参数介绍的文档：[https://blog.csdn.net/zhaozheng7758/article/details/8623549][https_blog.csdn.net_zhaozheng7758_article_details_8623549]

## 二.新生代对象的增速查看 ##

jstat -gc PID 1000 10

该命令  1000代表1秒，10代表打印10次   总体是每秒打印一次gc日志，共打印10次

通过该命令获取的信息，我们可以分析Eden区每秒或者设置的每分钟增长的新生代的大小。

**可根据该分析推测出Young GC的触发频率和每次耗时**。

## 三.分析每次Young GC后有多少对象是存活和进入老年代 ##

通过上面的步骤，推测出ygc的触发频率，然后通过

jstat -gc ygc触发频率  10

观察Eden、Survivor、老年代的对象变化。

>         主要是观察老年代的对象增长速率，从一个正常的角度来看，**老年代的对象是不太可能不停的快速增长的**，因为普通的系统其实没那么多长期存活的对象。如果你发现比如每次Young GC过后，老年代对象都要增长几十MB，那很有可能就是你一次Young GC过后存活对象太多了。存活对象太多，可能导致放入Survivor区域之后触发了动态年龄判定规则进入老年代，也可能是Survivor区域放不下了，所以大部分存活对象进入老年代。最常见的就是这种情况。如果你的老年代每次在Young GC过后就新增几百KB，或者几MB的对象，这个还算情有可缘，但是如果老年代对象快速增长，那一定是不正常的。

## 四.Full GC的触发时机和耗时 ##

通过上述分析了老年代的增长速率，可以推测出Full GC触发时机。

然后可以看到jstat打印出来的系统运行起劲为止的Full GC次数以及总耗时，比如一共执行了10次Full GC，共耗时30s，每次Full GC大概就是需要耗费3s左右。

[20210705140121784.png]: /images/20221005/7b308e3cff3a465899376d3007ac1d5f.png
[20210705140219826.png]: /images/20221005/99f5f34db3024f8ab03d30290a2c95b0.png
[https_blog.csdn.net_zhaozheng7758_article_details_8623549]: https://blog.csdn.net/zhaozheng7758/article/details/8623549