【Java】面试必问之Java常见线上故障排查方案详解

一、问题解析

在软件开发过程中，排查和修复产线问题是每⼀位⼯程师都需要掌握的基本技能。但是在⽣产环境中，

程序代码、硬件、⽹络、协作软件等任⼀因素，都会引发意想不到的问题，所以排查产线问题⽐较困

难，所以问题的定位体现了⼀名⼯程师的基础能⼒，问题的解决则体现了⼯程师的技能素养。

以下从5个⽅⾯分享产线常⻅问题的排查⼿段。

1. Java常⻅线上问题总结
2. 如何定位问题
3. APM链路跟踪分析
4. 常⽤Linux分析命令
5. Arthas（阿尔萨斯）诊断命令
6. JVM问题定位命令
7. GC分析

33.1 Java常⻅线上问题总结

绝⼤多数Java线上问题从表象来看通常可以归纳为4个⽅⾯：CPU、内存、磁盘、⽹络。⽐如，应⽤上线

后突然CPU使⽤率99%、内存泄漏、STW时间过⻓，这些问题通常可以分为两⼤类：

系统异常 （CPU占⽤率过⾼、磁盘使⽤率100%、系统可⽤内存低等）

业务异常 （服务运⾏⼀段时间⾃动退出、服务间调⽤时间过⻓、多线程并发异常、死锁等）

33.2 如何定位问题

解决问题的第⼀步是定位问题，因为只有定位到了问题产⽣的原因，才能准确的抉择出解决⽅案，排查

⼿段⼀般包括以下⼏项，也可以将此理解为排查顺序：

1. 业务⽇志分析排查

2. APM分析排查

3. 外部环境排查

4. 应⽤服务排查

5. 云⼚商或运营商问题排查

33.2.1 业务⽇志分析排查

通常情况下，⼤部分错误信息都会在⽇志上有所体现，⽐如看看下⾯这段代码

这段代码使⽤了 并发流 将数据加⼊到⼀个List中，再运⾏过程中，抛出了

ArrayIndexOutOfBoundsException ，具体异常栈信息如下：

通过⽇志可以看到出错的位置在 TaskServiceImpl.java ⽂件的第75⾏代码上，错误信息

是 java.lang.ArrayIndexOutOfBoundsException:163 ，这就是问题定位，整体描述出来就是： 在

TaskServiceImpl.java⽂件中第75⾏代码上出现了数组越界异常，引起异常的原因是在调⽤

java.util.ArrayList#add()⽅法时因为并发请求导致没有动态扩展数组容量 。

为什么我们能够直接描述出来是在调⽤ ArrayList#add() ⽅法时因为并发请求导致的没有动态扩展数

组容量呢？因为我们结合ArrayList的内部实现原理及动态扩容的特性，可以知道在单线程的情况下，代

码是串⾏执⾏，ArrayList内的数组都会是先扩容再插⼊，所以不会出现数组越界的错误，既然单线程不

会引起该错误，那⼀定就是多线程并发造成的了，解决⽅案就是给代码加锁或者由并发改串⾏，就是这

么简单，这就是技能素养的体现。

通过上⾯的分析，教育了我们：⼀定要在关键代码逻辑位置输出相关⽇志，尤其是在代码发⽣异常的时

候，定要将⽇志输出到⽂件中，只有这样，才更利于我们的排查。

33.2.2 APM分析排查

APM，全称Application Performance Management，应⽤性能管理，⽬的是通过各种探针采集数据，

收集关键指标，同时搭配数据呈现以实现对应⽤程序性能管理和故障管理的系统化解决⽅案。通过分布

式链路调⽤跟踪系统，通过在系统请求中透传 trace-id，将所有相关⽇志进⾏聚合，然后⽇志统⼀采集

和分析后，以图形化的形式展示给⼯程师们，⽽他们在排查问题的时候，可以简单粗暴且直观的调度出

问题最根本的原因。

业务⽇志较优于解决单体服务异常，但现在的应⽤通常使⽤的是分布式架构，⽽在分布式系统中，仅通

过单服务节点的⽇志，很难将错误信息与请求链路关联在⼀起，也就是通过系统中某个服务的异常⽇志

信息很难定位到问题的根本原因。并且我们还需要关注各服务执⾏过程中的耗时情况，及时的发现异常

服务，并根据异常信息进⾏修复。要满⾜这种需求，仅通过分析单个服务的⽇志信息是不够的，此时则

需要APM进⾏全链路分析，通过请求链路监控，实时的发现链路中相关服务的异常情况。

⽐如我们使⽤Skywalking，进⼊到Skywalking的控制台查看的链路信息就是这样的：

⽬前市场上使⽤较多的链路跟踪⼯具有如下⼏个：

Apache Skywalking：Apache SkyWalking

Pinpoint：https://pinpoint.com/product/for-engineers

SpringCloud Zipkin：https://docs.spring.io/spring-cloud-sleuth/docs/current-SNAPSHOT/referenc

e/html/#sending-spans-to-zipkin

33.2.3 物理环境排查

物理环境是指⼯程所依附的物理环境，⽐如服务器、宿主机、容器等，细分为服务器负载、CPU、内

存、磁盘、⽹络⼏个⽅⾯。

33.2.3.1 CPU分析

排查CPU的⽬的主要是查看服务器CPU的使⽤率， 使⽤top命令分析CPU使⽤情况

33.2.3.2 内存分析

使⽤free -m命令查看内存使⽤情况

33.2.3.3 磁盘分析

使⽤df -h、iostat、lsof等命令查看磁盘IO情况，找到读写异常的进程

33.2.3.4 ⽹络分析

使⽤dstat、vmstat等命令查看⽹络流量、TCP连接等情况，分析异常流量

33.2.4 应⽤服务排查

应⽤排查，排查应⽤本身最有可能引发的问题，针对各种场景进⾏对应分析

33.2.4.1 CPU分析

使⽤jstack等命令进⾏JVM分析

33.2.4.2 内存分析

使⽤jmap等命令分析内存使⽤情况

33.2.4 云⼚商或运营商问题排查

排查到了这⼀步的话，只需关注云⼚商或运营商官⽅公告即可。

假设我们从业务⽇志、APM分析中都没分析出问题所在，那么此时基本只能连接到⽣产环境中进⾏排查

了。根据上⾯的外部排查⽅案，这⾥简单复习下常⽤的Linux分析命令以便从系统层⾯上分析。

33.3 常⽤Linux分析命令

针对外部环境排查，需要使⽤的常⽤Linux分析命令包括 : top、free、df、lsof、dstat、vmstat等，简

单介绍如下：

33.3.1 CPU

CPU使⽤率是衡量系统繁忙程度的重要指标。但是CPU使⽤率的安全阈值是相对的，取决于你的系统的

IO密集型还是计算密集型。⼀般计算密集型应⽤CPU使