你们项⽬如何排查JVM问题

一、对于还在正常运⾏的系统：

1. 可以使⽤jmap来查看JVM中各个区域的使⽤情况。

jmap pid查看进程的内存映像信息,类似 Solaris pmap 命令。

image

jmap -heap pid 显示Java堆详细信息。

image

jmap -histo:live pid 显示堆中对象的统计信息。
jmap -clstats pid 打印类加载器信息。
map -finalizerinfo pid打印等待终结的对象信息。
jmap -dump:format=b,file=heapdump.phrof pid 生成堆转储快照dump文件。

2. 可以通过jstack来查看线程的运⾏情况，⽐如哪些线程阻塞、是否出现了死锁.

jstack pid 

3. 可以通过jstat命令来查看垃圾回收的情况，特别是fullgc，如果发现fullgc⽐较频繁，那么就得进⾏调优了。

jstat -gc pid 垃圾回收统计
Jstat -gc 74589 250 10
命令的意思是：每隔250毫秒查询一次进程为74589的垃圾收集情况，一共查询10次。

image

- S0C：第一个幸存区的大小
- S1C：第二个幸存区的大小
- S0U：第一个幸存区的使用大小
- S1U：第二个幸存区的使用大小
- EC：伊甸园区的大小
- EU：伊甸园区的使用大小
- OC：老年代大小
- OU：老年代使用大小
- MC：方法区大小
- MU：方法区使用大小
- CCSC:压缩类空间大小
- CCSU:压缩类空间使用大小
- YGC：年轻代垃圾回收次数
- YGCT：年轻代垃圾回收消耗时间
- FGC：老年代垃圾回收次数
- FGCT：老年代垃圾回收消耗时间
- GCT：垃圾回收消耗总时间

jstat -gcutil pid 总结垃圾回收统计

image

其他使用见博客：
https://www.jianshu.com/p/123079b47670

4. 通过各个命令的结果，或者jvisualvm等⼯具来进⾏分析。
5. ⾸先，初步猜测频繁发送fullgc的原因，如果频繁发⽣fullgc但是⼜⼀直没有出现内存溢出，那么表示 fullgc实际上是回收了很多对象了，所以这些对象最好能在younggc过程中就直接回收掉，避免这些对 象进⼊到⽼年代，对于这种情况，就要考虑这些存活时间不⻓的对象是不是⽐较⼤，导致年轻代放不下，直接进⼊到了⽼年代，尝试加⼤年轻代的⼤⼩，如果改完之后，fullgc减少，则证明修改有效。
6. 同时，还可以找到占⽤CPU最多的线程，定位到具体的⽅法，优化这个⽅法的执⾏，看是否能避免某些 对象的创建，从⽽节省内存。

二、对于已经发⽣了OOM的系统：

1. ⼀般⽣产系统中都会设置当系统发⽣了OOM时，⽣成当时的dump⽂件。
   （- XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base）

2. 我们可以利⽤jvisualvm等⼯具来分析dump⽂件。

3. 使用jmap dump出文件进行查看

# 查看堆内存信息
jmap -heap pid
# 找到最耗内存的对象
jmap -histo:live pid | more
# 使用jmap内存使用的详细情况输出到文件，之后一般使用其他工具进行分 析
jmap -dump:format=b,file=heapdump.phrof pid 

把dump文件在jvisualvm里打开。或者上传到网站 https://heaphero.io/index.jsp 进行分析

4. 使用jstack查询线程相关信息

# jstack 命令dump出信息，到分析工具分析
jstack -l 74589 > testdump.dmp

或者使用https://fastthread.io/在线分析工具。
使用方法是将程序jstack出来然后上传文件到上面网址就行，命令是jstack -l 56523 > 56523.jstack

3. 根据dump⽂件找到异常的实例对象，和异常的线程（占⽤CPU⾼），定位到具体的代码。
4. 然后再进⾏详细的分析和调试 总之，调优不是⼀蹴⽽就的，需要分析、推理、实践、总结、再分析，最终定位到具体的问题。

三、演示一套行云流水的操作

1、使用uptime查看当前load，发现load飙高

➜  ~ uptime
13:29  up 23:41, 3 users, load averages: 10 10 10

2、使用top命令，查看占用CPU较高的进程ID

➜  ~ top
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1893 admin     20   0 7127m 2.6g  38m S 181.7 32.6  10:20.26 java

发现PID为1893的进程占用CPU 181%,而且是一个Java进程，基本断定是软件问题
3、使用 top命令，查看具体是哪个线程占用率较高

➜  ~ top -Hp 1893
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
4519 admin     20   0 7127m 2.6g  38m R 18.6 32.6   0:40.11 java

4、使用printf命令查看这个线程的16进制

➜  ~ printf %x 4519
11a7

5、使用jstack命令查看当前线程正在执行的方法

➜  ~ jstack 1893 |grep -A 200 11a7

6、使用jmap内存使用的详细情况输出到文件，之后一般使用其他工具进行分 析

➜ ~ jmap -dump:format=b,file=heapDump 1893

在线分析dump文件（方法一）

在线分析线程问题