真碰到这种面试题，即使没有在生产环境使用过这些工具排查问题，也不要惊慌。把这些基本操作记住，面试就不慌。
出现 OOM 问题后，先得找到是哪个 Java 应用程序出问题了。也就是需要找到进程 id 才行。
（1）找进程 id
有两种方式找进程 id
（1）使用 top 命令列出当前的进程列表。
top -c
CPU 和 内存占用率排在最前面的就是占用最高的。里面包含了进程 id 信息。
（2）使用 ps 命令找 Java 相关的应用程序。
ps -ef | grep <关键字>
（2）jstat 命令
评估内存使用及GC压力情况
jstat -gc pid
会打印一堆信息，可以先初步看下 内存的使用情况和 GC 压力情况。另外有时候 dump 文件会非常大，可以先通过命令来排查，这样效率会高效点。
S0C: 第一个Survivor大小（kb）
S1C: 第二个Survivor大小
S0U: 第一个Survivor区的使用大小
S1U: 第二个Survivor区的使用大小
EC: eden区大小
EU: eden区的使用大小
OC: 老年代大小
OU: 老年代使用大小
MC: 方法区大小（元空间）
MU: 方法区使用大小
CCSC: 压缩类空间大小
CCSU: 压缩类空间使用大小
YGC: YoungGC次数
YGCT: YoungGC时间（s）
FGC: FullGC次数
FGCT: FullGC时间（s）
GCT: 总的GC时间（s）
可以指定时间间隔打印jvm的各部分空间占用，以及gc数据。命令如下：
jstat -gcutil {pid} {timeinterval}
（3）jstack 命令
当应用程序占用 CPU 很高，但是又没有发生 OOM，就可以通过 jstack 命令来看下到底哪里出问题了。
ps -mp <pid> -o THREAD,tid,time 定位到具体线程。
printf “%x\n” <pid>，把线程 pid 转为16进制，比如 0xf58
jstack <pid> | grep -A 10 0xf58 查看线程的堆栈日志
通过 jstack 命令可以迅速排查出来死锁问题或死循环的问题。
（4）jmap 命令
jmap 一般就是用来生成堆栈文件（dump 文件），然后把 dump 文件导入到可视化分析工具中，分析一把。比如jvisualvm 工具， MAT 工具。
jmap -dump:format=b,file=D:/demo.hprof <pid>
另外生产环境一般会配置内存溢出后自动打 dump 文件的命令：
-XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\jvm.dump
其他：
jmap -histo pid 查看实例个数以及占用内存信息。
jmap -heap pid 查看堆的使用情况。
（5）MAT 工具
分析 dump 文件的专业工具，查找内存泄露以及查看内存消耗情况，可以查看每个类的使用情况以及内存占用情况，从而分析问题。
eclipse 插件安装下这个工具就可以使用了。
MAT 插件会给出一份可疑的分析报告，结合源代码稍加分析就可以快速定位是哪段代码出问题了。
