首先，JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是 jconsole 和 jvisualvm 这两款视图监控工具。

一、jps(Java Process Status)

用于查看有权访问的虚拟机的进程，并显示他们的进程号
-v：列出虚拟机进程启动时的 JVM 参数。比如：-Xms20m -Xmx50m 是启动程序指定的 jvm 参数

二、jstat（JVM Statistics Monitoring Tool）

可以用来监视 JVM 内存内的各种堆和非堆的大小及其内存使用量、类装载、垃圾收集、JIT 编译等运行数据

jstat - [-t] [-h] [ []]

-gc：显示堆各分区大小、YGC,FGC次数和时长。包括 Eden 区、两个 Survivor 区、老年代、永久代等的容量、已用空间、GC 时间合计等信息
-gccapacity：显示内容与 -gc 基本相同，但输出主要关注 Java 堆各个区域使用到的最大、最小空间
-gcutil：显示内容与 -gc 基本相同，但输出主要关注已使用空间占总空间的百分比
-gccause：与 -gcutil 功能一样，但是会额外输出导致最后一次或当前正在发生的 GC 产生的原因
-gcnew：显示新生代 GC 状况
-gcnewcapacity：显示内容与 -gcnew 基本相同，输出主要关注使用到的最大、最小空间
-geold：显示老年代 GC 状况
-gcoldcapacity：显示内容与 -gcold 基本相同，输出主要关注使用到的最大、最小空间
-gcpermcapacity：显示永久代使用到的最大、最小空间

interval 参数：用于指定输出统计数据的周期，单位为毫秒。即：查询间隔
count 参数：用于指定查询的总次数

OOM案例：比较GC时长（GCT列）占运行市场的比例：
如果该比例超过 20%，则说明目前堆的压力较大;
如果该比例超过 98%，则说明这段时期内几乎一直在GC，堆里几乎没有可用空间，随时都可能抛出 OOM 异常

内存泄露案例
每隔一段较长的时间采样多组 OU（老年代内存量）的最小值，如果这些最小值在上涨，说明无法回收对象在不断增加，可能是内存泄漏导致的。
在长时间运行的 Java 程序中，我们可以运行 jstat 命令连续获取多行性能数据，并取这几行数据中 OU 列（Old Used，已占用的老年代内存）的最小值
然后，我们每隔一段较长的时间重复一次上述操作，来获得多组 OU 最小值。
如果这些值呈上涨趋势，则说明该 Java 程序的老年代内存已使用量在不断上涨，这意味着无法回收的对象在不断增加，因此很有可能存在内存泄漏（不再使用的对象仍然被引用，导致GC无法回收）