【JVM性能优化】问题故障排查的解决方案（上）
前提概要
线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是df、free、top三连，然后依次jstack、jmap伺候，具体问题具体分析即可。
CPU的问题
一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用jstack来分析对应的堆栈情况。
jstack分析cpu问题
- 先用ps命令找到对应进程的pid(如果你有好几个目标进程，可以先用top看一下哪个占用比较高)，来找到cpu使用率比较高的一些线程
top -H -p pid
这里需要注意的是 -p代表着通过进程号，-H 查询的是输出使用率最高线程
- 将占用最高的pid转换为16进制得到nid
printf ‘%x\n’ pid
- 接着直接在jstack中找到相应的堆栈信息
jstack ‘0x42’ | grep ‘nid’ -C5 –color
可以看到我们已经找到了nid为0x42的堆栈信息，接着只要仔细分析一番即可。
- 排查整个jstack文件
- 当然更常见的是我们对整个jstack文件进行分析，通常我们会比较关注WAITING和TIMED_WAITING的部分，BLOCKED就不用说了。
- 使用命令
cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c
JVM频繁gc（FullGC）
使用jstack来分析问题，但有时候我们可以先确定下gc是不是太频繁，使用
jstat -gc pid 1000
命令来对gc分代变化情况进行观察，1000表示采样间隔(ms)。
- S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU分别代表两个Survivor区、Eden区、老年代、元数据区的容量和使用量。
- YGC/YGT、FGC/FGCT、GCT则代表YoungGc、FullGc的耗时和次数以及总耗时。
如果看到gc比较频繁，再针对gc方面做进一步分析
上下文切换
针对频繁上下文问题，可以使用vmstat命令来进行查看。
vmstat 1
代表着1秒打印一次。
- cs(context switch)一列则代表了上下文切换的次数。
如果我们希望对特定的pid进行监控那么可以使用
pidstat -w pid
命令，cswch和nvcswch表示自愿及非自愿切换。
磁盘的问题
状态信息
- 磁盘问题和cpu一样是属于比较基础的。首先是磁盘空间方面，我们直接使用
df -hl
- 磁盘问题还是性能上的问题。可以通过
iostat -d -k -x
图片来源于blog.csdn.net/pengjunlee/…
- 最后一列%util可以看到每块磁盘写入的程度，而rrqpm/s以及wrqm/s分别表示读写速度，一般就能帮助定位到具体哪块磁盘出现问题了。
- 另外我们还需要知道是哪个进程在进行读写，一般来说开发自己心里有数，或者用
iotop
不过这边拿到的是tid，我们要转换成pid，可以通过readlink来找到pidreadlink -f /proc/*/task/tid/…/…。
图片来源于blog.csdn.net/pengjunlee/…
找到pid之后就可以看这个进程具体的读写情况cat /proc/pid/io
可以通过lsof命令来确定具体的文件读写情况
lsof -p pid
图片来源于blog.csdn.net/pengjunlee/…
内存问题
内存问题排查起来相对比CPU麻烦一些，场景也比较多。主要包括OOM、GC问题和堆外内存。一般来讲，我们会先用
free
命令先来检查一发内存的各种情况。
堆内内存
内存问题大多还都是堆内内存问题。表象上主要分为OOM和StackOverflow。
OOM问题
JVM中的内存不足，OOM大致可以分为以下几种：
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
复制代码
- 没有足够的内存空间给线程分配java栈，基本上还是线程池代码写的有问题，比如说忘记shutdown，或者使用无限制的任务队列，所以说应该首先从代码层面来寻找问题，使用jstack或者jmap。
- 如果一切都正常，JVM方面可以通过指定Xss来减少单个thread stack的大小。
- 另外也可以在系统层面，可以通过修改/etc/security/limits.conf的，nofile和nproc来增大os对线程的限制
问题
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
复制代码
原因
这个意思是堆的内存占用已经达到-Xmx设置的最大值，应该是最常见的OOM错误了。
解决办法
解决思路仍然是先应该在代码中找，怀疑存在内存泄漏，通过jstack和jmap去定位问题。如果说一切都正常，才需要通过调整Xmx的值来扩大内存。
问题
Caused by: java.lang.OutOfMemoryError: Meta space
复制代码
解决办法
这个意思是元数据区的内存占用已经达到
-XX:MaxMetaspaceSize
设置的最大值，排查思路和上面的一致，参数方面可以通过
-XX:MaxPermSize
来进行调整(这里就不说1.8以前的永久代了)。
问题
Exception in thread "main" java.lang.StackOverflowError
复制代码
解决办法
表示线程栈需要的内存大于Xss值，同样也是先进行排查，参数方面通过Xss来调整，但调整的太大可能又会引起OOM。
- 使JMAP定位代码内存泄漏,上述关于OOM和StackOverflow的代码排查方面，我们一般使用
jmap -dump:format=b,file=filename pid
【JVM性能优化】问题故障排查的解决方案（上）【JVM性能优化】问题故障排查的解决方案（上）前提概要CPU的问题磁盘的问题最后： - 通过MAT(Eclipse Memory Analysis Tools)导入dump文件进行分析，内存泄漏问题一般我们直接选Leak Suspects即可，mat给出了内存泄漏的建议。另外也可以选择Top Consumers来查看最大对象报告。
- 线程相关的问题可以选择thread overview进行分析。除此之外就是选择Histogram类概览来自己慢慢分析，大家可以搜搜mat的相关教程。
代码产生内存泄漏是比较常见的事，并且比较隐蔽，需要开发者更加关注细节。
- 比如说每次请求都new对象，导致大量重复创建对象；
- 进行文件流操作但未正确关闭；手动不当触发gc，ByteBuffer缓存分配不合理等都会造成代码OOM。
可以在启动参数中指定
-XX:+HeapDumpOnOutOfMemoryError
来保存OOM时的dump文件。
gc问题和线程
- GC问题除了影响cpu也会影响内存，排查思路也是一致的。一般先使用jstat来查看分代变化情况，比如youngGC或者fullGC次数是不是太多呀；EU、OU等指标增长是不是异常呀等。
- 线程的话太多而且不被及时gc也会引发oom，大部分就是之前说的unable to create new native thread。除了jstack细细分析dump文件外，我们一般先会看下总体线程，通过
pstree -p pid |wc -l
【JVM性能优化】问题故障排查的解决方案（上）【JVM性能优化】问题故障排查的解决方案（上）前提概要CPU的问题磁盘的问题最后：
或者直接通过查看/proc/pid/task的数量即为线程数量。
堆外内存
如果碰到堆外内存溢出，那可真是太不幸了。首先堆外内存溢出表现就是物理常驻内存增长快，报错的话视使用方式都不确定。
由于使用Netty导致的，那错误日志里可能会出现OutOfDirectMemoryError错误，如果直接是DirectByteBuffer，那会报OutOfMemoryError: Direct buffer memory。
堆外内存溢出往往是和NIO的使用相关，一般我们先通过
pmap
来查看下进程占用的内存情况
pmap -x pid | sort -rn -k3 | head -30
，这段意思是查看对应pid倒序前30大的内存段。这边可以再一段时间后再跑一次命令看看内存增长情况，或者和正常机器比较可疑的内存段在哪里。
我们如果确定有可疑的内存端，需要通过
gdb
来分析
gdb --batch --pid {pid} -ex "dump memory filename.dump {内存起始地址} {内存起始地址+内存块大小}"
排查问题
获取dump文件后可用heaxdump进行查看
hexdump -C filename | less
，不过大多数看到的都是二进制乱码。
NMT是Java7U40引入的HotSpot新特性，配合jcmd命令我们就可以看到具体内存组成了。需要在启动参数中加入
-XX:NativeMemoryTracking=summary
或者
-XX:NativeMemoryTracking=detail
，会有略微性能损耗。
一般对于堆外内存缓慢增长直到爆炸的情况来说，可以先设一个基线
jcmd pid VM.native_memory baseline
。
然后等放一段时间后再去看看内存增长的情况，通过
jcmd pid VM.native_memory detail.diff(summary.diff)
做一下summary或者detail级别的diff。
可以看到jcmd分析出来的内存十分详细，包括堆内、线程以及gc(所以上述其他内存异常其实都可以用nmt来分析)，这边堆外内存我们重点关注Internal的内存增长，如果增长十分明显的话那就是有问题了。
detail级别的话还会有具体内存段的增长情况，如下图
此外在系统层面，我们还可以使用strace命令来监控内存分配
strace -f -e "brk,mmap,munmap" -p pid
这边内存分配信息主要包括了pid和内存地址
不过其实上面那些操作也很难定位到具体的问题点，关键还是要看错误日志栈，找到可疑的对象，搞清楚它的回收机制，然后去分析对应的对象。
- 比如DirectByteBuffer分配内存的话，是需要full GC或者手动system.gc来进行回收的(所以最好不要使用-XX:+DisableExplicitGC)。
那么其实我们可以跟踪一下DirectByteBuffer对象的内存情况，通过jmap -histo:live pid手动触发fullGC来看看堆外内存有没有被回收。
如果被回收了，那么大概率是堆外内存本身分配的太小了，通过 -XX:MaxDirectMemorySize
最后：
我想，可能还有很多人在今年刚过去的金三银四春招中保持着观望的形势，害怕自己的能力不够，或者是安于现状，觉得目前拿着几千的月薪觉得能够接受，那么你就要注意了，这是非常危险的！
我们身为技术人员，最怕的就是安于现状，一直在原地踏步，那么你可能在30岁就会迎来自己的职业危机，因为你工作这么久提升的只有自己的年龄，技术还是万年不变！
如果你想在未来能够自我突破，圆梦大厂，那或许以上这份Java学习资料，你需要阅读阅读，希望能够对你的职业发展有所帮助。
获取方式： 只需你**点赞+关注**后，加入Java架构资源交流群，找管理员获取哦-！
为你工作这么久提升的只有自己的年龄，技术还是万年不变！
如果你想在未来能够自我突破，圆梦大厂，那或许以上这份Java学习资料，你需要阅读阅读，希望能够对你的职业发展有所帮助。
获取方式： 只需你**点赞+关注**后，加入Java架构资源交流群，找管理员获取哦-！