【JVM】之监控命令-jstat详解垃圾回收参数详解

转载自博客：https://blog.csdn.net/A_captain_608/article/details/126391048

目录

jstat -gc

jstat -gcutil

jstat -gcnew

jstat -gcold

jstat -gc

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

2、jstat -gc xxx

 

 

 

jstat -gc 2040
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
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（已使用的容量）

前缀代表区域。

区域 含义
S0C Survive0 第一个幸存区的容量大小
S1C Survive1 第二个幸存区的容量大小
S0U Survive0 第一个幸存区已使用的内存大小
S1U Survive1 第二个幸存区已使用的内存大小
EC Eden 伊甸园区的容量大小
EU Eden 伊甸园区已使用的内存大小
OC Old 老年代的容量大小
OU Old 老年代已使用的内存大小
MC Meta 方法区的容量大小
MU Meta 方法区已使用的内存大小
YGC Young GC发生的次数
YGCT Young GC的总耗时
FGC Full GC发生的次数
FGCT Full 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之间的流转。
————————————————
版权声明：本文为CSDN博主「Petter's Blog」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/A_captain_608/article/details/126391048