前提概要
线上有过一两次OOM的问题，但是每次定位问题都有点手足无措的感觉，刚好利用星期天，以测试环境为模版来学习一下Linux常用的几个排查问题的命令。也可以帮助自己在以后的工作中快速的排查线上问题。
jmap命令
- jmap -heap pid ：输出当前进程 JVM 堆新生代、老年代、持久代等请情况，GC 使用的算法等信息
- jmap -histo:live {pid} | head -n 10 ：输出当前进程内存中所有对象包含的大小
- jmap -dump:format=b,file=/dump.hprof {pid} :以二进制输出档当前内存的堆情况，然后可以导入MAT等工具进行
jmap -heap pid
输出当前进程JVM堆新生代、老年代、持久代等情况，GC使用的算法等信息。
jmap -histo:live {pid} | head -n 10
输出当前进程内存中所有对象包含的大小
输出当前进程内存中所有对象实例数 (instances) 和大小 (bytes), 如果某个业务对象实例数和大小存在异常情况，可能存在内存泄露或者业务设计方面存在不合理之处。
jmap -dump：
命令如下：
（1）jmap命令到处dump文件信息。
mkdir logs jmap -dump:format=b,file=/tmp/logs/dump.hprof {pid} 复制代码
-dump:format=b,file= 二进制输出当前内存的堆情况至相应的文件，然后可以结合MAT等内存分析工具深入分析当前内存情况。
（2）也可以通过JVM参数配置OOM时自动dump当前内存镜像文件。
-XX:+HeapDumpOnOutOfMemoryError 和**-XX:HeapDumpPath**所代表的含义就是当程序出现OutofMemory时，将会在相应的目录下生成一份dump文件，而如果不指定选项-XX:HeapDumpPath则在当前目录下生成dump文件。
确保应用发生 OOM 时 JVM 能够保存并 dump 出当前的内存镜像。
- 当然，如果你决定手动 dump 内存时，dump 操作占据一定 CPU 时间片、内存资源、磁盘资源等，因此会带来一定的负面影响。
- 此外，dump的文件可能比较大 , 一般我们可以考虑使用 zip 命令对文件进行压缩处理，这样在下载文件时能减少带宽的开销。
- 下载 dump文件完成之后，由于 dump 文件较大可将 dump 文件备份至制定位置或者直接删除，以释放磁盘在这块的空间占用。
dump 日志分析
MAT(Memory Analyzer Tool)，一个基于 Eclipse 的内存分析工具，是一个快速、功能丰富的 JAVA heap 分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。
使用内存分析工具从众多的对象中进行分析，快速的计算出在内存中对象的占用大小，看看是谁阻止了垃圾收集器的回收工作，并可以通过报表直观的查看到可能造成这种结果的对象。
具体可以参考：
jstack命令-查看线程堆栈信息
10进制至16进制线程ID(native线程)% d10进制
printf '%x\n' tid 复制代码
jstack pid | grep tid -C 30 --color ps -mp 8278 -o THREAD,tid,time | head -n 40 复制代码
(1).java进程CPU占用率高，我们想要定位到其中 CPU 占用率最高的线程
- 先利用top命令找到CPU占用高的进程pid
- 也可以通过 ps -ef | grep 应用名 来快速定位自己应用的pid
显示pid：29080
(2).利用 top 命令可以查出占 CPU 最高的线程 pid (先找到该pid 29080下所有的线程数据)
可以看到占用cpu资源最高的为29173 复制代码
(3).占用率最高的线程 ID 为29173，将其转换为 16 进制形式 (因为 java native 线程以 16 进制形式输出)
printf '%x\n' 29173
(4).利用 jstack 打印出 java 线程调用栈信息
jstack 29080 | grep '0x71f5' -A 50 --color
可以看到这个线程是在做kafka相关的操作。因为这是测试，所以并不是因为CPU真的占用过高的情况。
更多内容也可以参考：
jstat命令
jstat：Java Virtual Machine statistics monitoring tool JDK自带的一个轻量级小工具。
jstat显示GC执行的情况
jstat -gc 12538 5000 jstat -gcutil 12538 5000
即会每5秒一次显示进程号为12538的java进成的GC情况
jinfo命令
jinfo可以用来查看正在运行的java运用程序的扩展参数。
查看pid对应的JVM参数，可以到 PerfMa : xxfox.perfma.com/jvm/check 校…
jinfo -flags pid
说明：
显示内容说明如下：
S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
EC：年轻代中Eden（伊甸园）的容量 (字节)
EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
OC：Old代的容量 (字节)
OU：Old代目前已使用空间 (字节)
PC：Perm(持久代)的容量 (字节)
PU：Perm(持久代)目前已使用空间 (字节)
- YGC：从应用程序启动到采样时年轻代中gc次数
- YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
- FGC：从应用程序启动到采样时old代(全gc)gc次数
- FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
- GCT：从应用程序启动到采样时gc用的总时间(s)
总结
一般分析CPU或者内存异常情况可以通过以下几步：
- 查看日志
- 查看CPU情况
- 查看TCP情况
- 查看java线程，jstack
- 查看java堆，jmap
- 通过MAT分析堆文件，寻找无法被回收的对象
