当前位置:   article > 正文

【JVM】之监控命令-jstat详解_jstat -gc

jstat -gc

目录

jstat -gc 

jstat -gcutil

jstat -gcnew

jstat -gcold


jstat -gc

1、jps获取进程号(也可以是用ps -ef 或 ps -aux)

2、jstat -gc xxx

  1. jstat -gc 2040
  2. S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
  3. 512.0 1024.0 489.3 0.0 172544.0 115728.9 193536.0 88848.1 50432.0 48798.3 5888.0 5434.6 156 0.550 2 0.124 0.674

各属性代表的含义:

末尾为C,代表该区Capacity(容量)

末尾为U,代表Used(已使用的容量)

前缀代表区域。

区域含义
S0CSurvive0 第一个幸存区的容量大小
S1CSurvive1 第二个幸存区的容量大小
S0USurvive0 第一个幸存区已使用的内存大小
S1USurvive1 第二个幸存区已使用的内存大小
ECEden 伊甸园区的容量大小
EUEden 伊甸园区已使用的内存大小
OCOld 老年代的容量大小
OUOld 老年代已使用的内存大小
MCMeta 方法区的容量大小
MUMeta 方法区已使用的内存大小
YGCYoung GC发生的次数
YGCTYoung GC的总耗时
FGCFull GC发生的次数
FGCTFull GC的总耗时

--说明:

 其中,年轻代(S0C、S1C、EC)、老年代(OC)在不同的时间点看到的容量可能会不一样。

其原因是:容量大小会因为JVM参数(Xmx、Xms)配置的大小不一致,而导致各区容量会在内存紧张时变为最大,内存空闲时变为最小。这是因为JVM的参数配置,而导致的内存容量的收缩与扩张。

在某种程度上来讲可以将【Xmx、Xms】、XX:MaxNewSize、XX:NewSize配置为一样大小,减少在内存紧张时,对象在各内存区流转而引起的内存扩张、收缩,进而充分利用各区内存资源。

实时监控

除了查询之后,还可以在jstat -gc后面加毫秒后缀、打印次数,来实现实时监控,如下图中的 1000代表1000毫秒,即一秒,100代表打印100次。

 在上图中我们还可以看到Eden区的已使用容量在不断的增大,也就是我们程序的运行产生的对象在Eden区增长。当Eden区的EU达到了EC(最大容量)时,这个时候就会进行Eden区的垃圾回收,依然存活的对象会从Eden区转移到S0区;当对象持续增长时,就会执行S0的垃圾回收,依然存活的对象会从S0转移到S1,如果对象依旧持续产生,就会有对象转移到Old区,也就是老年代。当老年代的内存容量也满了时,就会发生Full GC。

通过jstat -gc 毫秒 次数,可以实时的监控到程序的内存情况,以及对象在各区之间的流转。


 jstat -gcutil

用来查询当前进程下,各区已使用的内存占比情况

S0:S0区的已使用的内存占比

S1:S1区已使用的内存占比

E:Eden区已使用的内存占比

O:Old区已使用的内存占比

M:方法区已使用的内存占比

YGC:Young GC发生的次数

YGCT:Young GC的总耗时

FGC:Full GC发生的次数

FGCT:Full GC的总耗时

GCT:Young GC + Full GC的总耗时

同样的,jstat -gcutil同样可以实时查询

 

可以看到,Eden区在程序运行中,内存占比在不断的增大


jstat -gcnew 、jstat -gcold

类似的,jstat -gcnew与jstat -gcold是用来排查年轻代和年老代的内存占用情况,同样的,可以通过加 毫秒 次数 来实现实时查询:

从这张图中,可以更加清晰的看到,对象在Eden区、S0、S1之间的流转。

本文内容由网友自发贡献,转载请注明出处:【wpsshop博客】
推荐阅读
相关标签
  

闽ICP备14008679号