java排查故障思路

一.前言

        好长时间没有写文章了，因为遇见了个倒霉公司，全员降薪30%,我这马上就要做爸爸的人了，没钱可不行。果断告别老东家，拥抱新主子~。新公司业务逻辑比较复杂。持续学习中。。。今天我们来讲一下线上故障的排查思路。话不多说，开启正题

二.概述

 线上的故障无非就是四种，cpu,磁盘，内存，网络。出现的大多数问题都不仅仅在一个层面上面，基本出现问题了就是df,free,top 三连，然后上jstack,jmap.遇见具体问题分析即可

三.CPU

对于cpu飙升问题，一般都是因为死循环啦，频繁GC以及上下文切换过多导致的，而最常见的就是业务逻辑导致了，这时候我们可以使用jstack来分析堆栈情况

首先 ps -ef | grep '有问题的程序' 找到对应的进程pid

接着使用 top -H -p pid 来找到cpu使用率高的线程

然后即将线程id转换为16进制  printf '%x\n'  使用率高的pid

接着直接使用jstack找到对应的堆栈信息

jstack pid | grep 'nid' -C5 -color  这个nid 就是上面转化完16位的pid

这就能看到整个堆栈信息啦

但是通常我们都会对整个jstack文件进行分析，通常我们比较关注waiting和time_waiting部分，brocked就更不用说了，

使用命令 cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c

什么，还不知道jstack.log怎么生成的？  肯定是  jstack -p pid > 路径/就stack.log

 对于频繁GC

        当然我们还是会使用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的耗时和次数以及总耗时

上下文切换

针对频繁上下文切换 我们可以使用vmstat命令来查看

vmstat 5 10   是 数字5 数字10 嗷   5代表5s一次  10 代表总次数

其中结果的意思如下：

CPU状态的监控指标主要有以下几个参数获得：
r：在运行队列中等待的进程数
bÿ