–gcutil监视内容 与 -gc基本相同，但输出主要关注已使用空间占总空间的 百分比 。
jstat -gccause 28549 2000
gccause 与-gcutil功能一样，但是会额外输出导致上一次GC产生的原因
工作中我个人使用jstat -gccause和jstat -gc这个俩个命令比较多。
3.2 jstat输出内容解释- 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线程停顿时间不长也没有关系的。
4. JAVA自带命令–jinfo,查看JVM的配置信息jinfo这个命令在JDK的安装目录bin/下面
