一整套线上故障排查技巧，爱了 ★★★建议星标我们★★★J

★★★建议星标我们★★★
Java进阶架构师★“星标”！这样才不会错过每日进阶架构文章呀。
文章插图
文章插图
2020年Java原创面试题库连载中
【000期】Java最全面试题库思维导图
【020期】JavaSE系列面试题汇总（共18篇）
【028期】JavaWeb系列面试题汇总（共10篇）
【042期】JavaEE系列面试题汇总（共13篇）
【049期】数据库系列面试题汇总（共6篇）
【053期】中间件系列面试题汇总（共3篇）
【065期】数据结构与算法面试题汇总（共11篇）
【076期】分布式面试题汇总（共10篇）
【077期】综合面试题系列（一）
【078期】综合面试题系列（二）
【079期】综合面试题系列（三）
【080期】综合面试题系列（四）
【081期】综合面试题系列（五）
【082期】综合面试题系列（六）
【083期】综合面试题系列（七）
【084期】综合面试题系列（八）
【085期】综合面试题系列（九）
【086期】综合面试题系列（十）
【087期】综合面试题系列（十一）
【088期】综合面试题系列（十二）
【089期】综合面试题系列（十三）
更多内容，点击上面蓝字查看
文章插图
本文来源：

线上故障主要会包括 CPU、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。
同时例如 jstack、jmap 等工具也是不囿于一个方面的问题的，基本上出问题就是 df、free、top 三连，然后依次 jstack、jmap 伺候，具体问题具体分析即可。
CPU
一般来讲我们首先会排查 CPU 方面的问题。 CPU 异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁 GC 以及上下文切换过多。
而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用 jstack 来分析对应的堆栈情况。
①使用 jstack 分析 CPU 问题
我们先用 ps 命令找到对应进程的 pid（如果你有好几个目标进程，可以先用 top 看一下哪个占用比较高）。
接着用top -H -p pid来找到 CPU 使用率比较高的一些线程：
文章插图
然后将占用最高的 pid 转换为 16 进制 printf '%x\n' pid 得到 nid：
文章插图
接着直接在 jstack 中找到相应的堆栈信息 jstack pid |grep 'nid' -C5 –color：
文章插图
可以看到我们已经找到了 nid 为 0x42 的堆栈信息，接着只要仔细分析一番即可。
当然更常见的是我们对整个 jstack 文件进行分析，通常我们会比较关注 WAITING 和 TIMED_WAITING 的部分， BLOCKED 就不用说了。
我们可以使用命令 cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c 来对 jstack 的状态有一个整体的把握，如果 WAITING 之类的特别多，那么多半是有问题啦。
文章插图
②频繁 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 的耗时和次数以及总耗时。
如果看到 GC 比较频繁，再针对 GC 方面做进一步分析，具体可以参考一下 GC章节的描述。
文章插图
③上下文切换
针对频繁上下文问题，我们可以使用 vmstat 命令来进行查看：
文章插图
cs（context switch）一列则代表了上下文切换的次数。如果我们希望对特定的 pid 进行监控那么可以使用 pidstat -w pid 命令， cswch 和 nvcswch 表示自愿及非自愿切换。
文章插图