Java线上故障排查完整套路和技巧分享[图]

线上故障主要会包括CPU、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是df、free、top三连，然后依次jstack、jmap伺候，具体问题具体分析即可。
CPU
一般来讲我们首先会排查CPU方面的问题。CPU异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用jstack来分析对应的堆栈情况。
使用jstack分析CPU问题
我们先用ps命令找到对应进程的pid(如果你有好几个目标进程，可以先用top看一下哪个占用比较高)。
接着用top-H-ppid来找到CPU使用率比较高的一些线程
然后将占用最高的pid转换为16进制printf'%x\n'pid得到nid
接着直接在jstack中找到相应的堆栈信息jstackpid|grep'nid'-C5–color
可以看到我们已经找到了nid为0x42的堆栈信息，接着只要仔细分析一番即可。

当然更常见的是我们对整个jstack文件进行分析，通常我们会比较关注WAITING和TIMED_WAITING的部分，BLOCKED就不用说了。我们可以使用命令catjstack.log|grep"java.lang.Thread.State"|sort-nr|uniq-c来对jstack的状态有一个整体的把握，如果WAITING之类的特别多，那么多半是有问题啦。
频繁gc
当然我们还是会使用jstack来分析问题，但有时候我们可以先确定下gc是不是太频繁，使用jstat-gcpid1000命令来对gc分代变化情况进行观察，1000表示采样间隔(ms)，S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU分别代表两个Survivor区、Eden区、老年代、元数据区的容量和使用量。YGC/YGT、FGC/FGCT、GCT则代表YoungGc、FullGc的耗时和次数以及总耗时。如果看到gc比较频繁，再针对gc方面做进一步分析，具体可以参考一下gc章节的描述。
上下文切换
针对频繁上下文问题，我们可以使用vmstat命令来进行查看
cs(contextswitch)一列则代表了上下文切换的次数。
如果我们希望对特定的pid进行监控那么可以使用pidstat-wpid命令，cswch和nvcswch表示自愿及非自愿切换。
磁盘
磁盘问题和CPU一样是属于比较基础的。首先是磁盘空间方面，我们直接使用df-hl来查看文件系统状态
更多时候，磁盘问题还是性能上的问题。我们可以通过iostatiostat-d-k-x来进行分析
最后一列%util可以看到每块磁盘写入的程度，而rrqpm/s以及wrqm/s分别表示读写速度，一般就能帮助定位到具体哪块磁盘出现问题了。
另外我们还需要知道是哪个进程在进行读写，一般来说开发自己心里有数，或者用iotop命令来进行定位文件读写的来源。
不过这边拿到的是tid，我们要转换成pid，可以通过readlink来找到pidreadlink-f/proc/*/task/tid/../..。
找到pid之后就可以看这个进程具体的读写情况cat/proc/pid/io
我们还可以通过lsof命令来确定具体的文件读写情况lsof-ppid
内存
内存问题排查起来相对比CPU麻烦一些，场景也比较多。主要包括OOM、GC问题和堆外内存。一般来讲，我们会先用free命令先来检查一发内存的各种情况。
堆内内存
内存问题大多还都是堆内内存问题。表象上主要分为OOM和StackOverflo。
OOM
JMV中的内存不足，OOM大致可以分为以下几种：
Exceptioninthread"main"java.lang.OutOfMemoryError:unabletocreatenewnativethread
这个意思是没有足够的内存空间给线程分配Java栈，基本上还是线程池代码写的有问题，比如说忘记shutdown，所以说应该首先从代码层面来寻找问题，使用jstack或者jmap。如果一切都正常，JVM方面可以通过指定Xss来减少单个threadstack的大小。另外也可以在系统层面，可以