–gcutil监视内容 与 -gc基本相同，但输出主要关注已使用空间占总空间的 百分比 。

jstat -gccause 28549 2000

gccause 与-gcutil功能一样，但是会额外输出导致上一次GC产生的原因

工作中我个人使用jstat -gccause和jstat -gc这个俩个命令比较多。

• jstat -gc jvm进程PID 2000

jvm的堆(heap)空间由S0(Survivor,0号幸存区) S1(Survivor,1号幸存区) Eden(年轻代) Tenured(Old老年代) Permanent(永久代)组成的。

注意:Permanent(永久代)在jdk1.7还是jdk1.8的时候被移除了,换成Metaspace(元数据)了。注意,永久代的意思并不是这块内存永远不会回收,在发生FullGC的时候,永久代里面的垃圾也会被回收掉。

所以jstat的输出结果说明为:

S0C(Capacity):S0的最大内存,总内存。Capacity就是容量的意思。单位:kb

S0U(Used):S0目前已经使用的大小。Used就是已经使用的意思。单位:kb

EC,EU:就是年轻代

PC,PU:就是永久代

OC,OU:就是老年代

YGC:就是年轻代的GC次数

YGCT:就是年轻代GC所花费的时间,单位秒

FGC:就是FGC的次数

FGCT:就是FGC所花费的时间,单位秒

GCT:就是YGC FGC俩个GC加起来所花费的时间,单位秒

• jstat -gcutil 4777 2000 5

这个命令里面的-gcutil 监视内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比，所以-gcutil看到的是使用率。

这些命令你会使用了，关键结果你能看得懂吗？其实很简单，我们主要关注，年轻代和老年代和持久代的使用率，目前用了多少G，最大的堆内存空间配置的是多少？是不是快满了，是不是快要内存溢出了就行。GC前后的年轻代和老年代占用的空间是否减少了，如果发生了一次GC，年轻代和老年代占用的空间并没有减少，那说明你的代码发生了内存泄漏。要赶紧使用我下面介绍的jmap命令将java的堆现场的情况dump下来使用MAT软件或者GCeasy或者visualVM或者国内PerfMa社区的软件来分析dump内存文件，找到代码泄漏的真正原因。Perfma社区的 阿飞Javaer 大神说FullGC一天超过一次肯定就不正常了，发现FullGC频繁的时候优先调查内存泄漏问题。我认为这个说法不太对，我看了一下，我们生产环境的GC情况，FullGC一天500次左右，服务也挺正常的。并且老年代回收完使用率才13%，说明我们生产环境FullGC是可以把垃圾回收掉的。FullGC的次数本质是跟JVM的内存使用量有关系的,如果你们的系统业务很繁忙,FullGC次数多也是正常的，只有GC之后能把垃圾都回收掉就可以。并且每次FullGC的STW线程停顿时间不长也没有关系的。

jinfo这个命令在JDK的安装目录bin/下面