概论
命令监控最方便，但是最优的方式是通过工具打开监控：比如jconsole、jvisualvm，几乎全部的信息都有了，另外jvisualvm支持远程监控，但是需要做一些配置
使用命令的目的
获取垃圾回收器的类型和系统参数 // jmap -heap pid
查看应用启动的参数// jinfo -flags pid
查看当前各个代区的容量和使用量情况 // jstat
FGC、YGC的总次数和总耗时 // jstat
立即生成Dump文件 //jmap -dump:live,file=dump_001.bin PID
强制FullGC // jmap -dump:live
查看线程的运行信息（包括死锁的线程) // jstack -l pid
jmap命令
heap pid：查看 JDK的概况的最好的一个参数
JVM主要参数：垃圾回收器的类型、各种ratio、当前实际Size、MaxSize是多少
当前各个代区的使用情况：Eden、From、To、Old区、Perm区
参数解读
垃圾回收器： parallel + Concurrent Mark-Sweep
堆区MaxSize是4G，也就是默认是操作系统的1/4,16G*1/4=4G
堆区低于40%，或者大于70% 会自动调整老年代的大小（但是不能低于xms的配置 2G，也不能高于 MaxSize 4G）
Perm区 最大1G ，如我们配置
老年代（concurrent mark-sweep generation）容量：1715.25MB
年轻代：New Generation + 1 Survivor Space= 299.5MB+33.25MB
堆区的当前容量：1715.25+299.5+33.25=2048M
dump：生成快照文件，然后可以利用工具（比如jvisualvm）来分析dump包
dump堆到文件,format指定输出格式，live指明是活着的对象,file指定文件名
./jmap -dump:live,format=b,file=/usr/developer/huangForBackUp/test20190129.dump 25508jmap还有一个额外的功能，通过命令触发FullGC，比如可以执行定时任务，在业务低峰期执行，会自动触发FullGC
因为在*:live前会进行full gc，如果带上live则只统计活对象，因此不加live的堆大小要大于加live堆的大小
jmap -histo:live <pid>
jmap -dump:live,file=dump_001.bin PIDjstat命令
gc: 主要查看FGC、YGC的总次数和累计耗时
查看堆内各个代区的当前容量和当前使用量（当前容量不等于MaxCapactiy，当前容量是根据条件动态调整的），因为当前容量不等于Max容量所以在定位问题的时候，没有太多的使用价值
- S0C : survivor0区的总容量
- S1C : survivor1区的总容量
- S0U : survivor0区已使用的容量
- S1C : survivor1区已使用的容量
- EC : Eden区的总容量
- EU : Eden区已使用的容量
- OC : Old区的总容量
- OU : Old区已使用的容量
- PC 当前perm的容量 (KB)
- PU perm的使用 (KB)
- YGC : 新生代垃圾回收次数
- YGCT : 新生代垃圾回收时间
- FGC : 老年代垃圾回收次数
- FGCT : 老年代垃圾回收时间
- GCT : 垃圾回收总消耗时间
gcutil:功能和gc 一样，但是是百分比的形式，读取更友好
gccapacity：读取各个代区的当前容量、最大容量、当前使用量等信息
NGCMN : 新生代占用的最小空间
NGCMX : 新生代占用的最大空间
OGCMN : 老年代占用的最小空间
OGCMX : 老年代占用的最大空间
OGC：当前年老代的容量 (KB)
OC：当前年老代的空间 (KB)
PGCMN : perm占用的最小空间
PGCMX : perm占用的最大空间
命令的使用：
./jstat -gc 91328
./jstat -gcutil 91328
./jstat -gccapacity 91328
jstack -l pid >> stackLog.log //-l 表示包括线程死锁的信息
输出当前应用的线程使用信息，其中包括线程死锁的相关信息
原文地址：https://blog.51cto.com/13981400/2389698