JAVA应用运维，线上故障排查全套路！！！

最新推荐文章于 2022-11-30 10:10:18 发布

Java世界上最好的语言

最新推荐文章于 2022-11-30 10:10:18 发布

阅读量334

点赞数

文章标签： java

本文链接：https://blog.youkuaiyun.com/doubututou/article/details/117172684

版权

本文详述了JAVA应用运维中遇到的CPU、磁盘、内存线上故障的排查步骤和工具使用，包括jstack、jmap、vmstat、iostat等。首先通过df、free、top命令初步分析，然后利用jstack分析CPU问题，jstat监控GC情况，vmstat查看上下文切换。磁盘问题通过df和iostat进行性能分析，内存问题则涉及OOM、StackOverflow，使用jmap定位代码内存泄漏。文章还介绍了如何处理网络层面的超时、TCP队列溢出和RST异常等问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

线上故障主要会包括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章节的描述。