前提概要
线上故障主要会包括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来对jstack的状态有一个整体的把握，如果WAITING之类的特别多，那么多半是有问题啦。
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来导出dump文件
通过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
- 或者直接通过查看/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进行调整。如果没有什么变化，那就要使用jmap去分析那些不能被gc的对象，以及和DirectByteBuffer之间的引用关系了。
