Java应用后端响应慢问题排查思路

Java应用后端响应慢问题排查思路

java应用后端响应缓慢，在未知是否数据库写入读取慢、网络链路正常的情况下，应该如何排查。

这里引入arthas 的排查思路。（arthas 需要JDK 1.6 以上，且仅支持Java应用，命令详细使用见官方文档：https://arthas.aliyun.com/doc/）

java应用响应慢，较大概率是数据库响应慢、自身Full GC以及业务逻辑过于复杂。链路调用的网络问题在此不做讨论

一、获取前端访问的后端接口

java 后端应用响应缓慢，需要先确认是哪个接口的返回较慢。

• WEB应用：可通过前端浏览器，开发者工具，network 查看前端耗时较长的接口，逐层定位

• 所以应用适用：根据日志调用信息，排查耗时较高的接口，串联日志排查（比如根据业务数据在日志中的路径，trace ID 等）

• 如果有全链路监控，接口监控（如zipkin、pinpoint等），根据接口定位响应缓慢的接口

• 简单粗暴，和研发确认该功能的调用栈

• 通过arthas monitor 命令监控可疑方法

  [arthas@123]$ monitor -c 5 demo.MathGame primeFactors #每隔5秒打印一次类demo.MathGame中方法primeFactors的调用情况
  

二、知道了响应缓慢的接口，如何进行下一步排查

通过第一步，我们基本确认了是哪个接口响应慢，接下来，借用arthas进行下一步分析。

首先应排除是否数据库响应慢导致，该步骤不在此讨论

1、 检查应用GC 情况，可通过监控、GC log来查看，在arthas 中，可通过dashboard 查看,GC 问题可通过heapdump、threaddump 分析。

[arthas@123]$ dashboard  #arthas 控制面板
[arthas@123]$ jvm #jvm基本信息
[arthas@123]$ heapdump --live /tmp/dump.hprof  #打印heapdump 信息，类似jmap:jmap -dump:[live,]format=b,file=/tmp/dump.hprof <pid>

#使用jdk 自带命令查看GC信息
$ jstack -l <pid>
$ jstack[ option ] pid

dashboard 结果图示

2、查看是否由线程死锁、线程阻塞。通过thread 查看线程信息

[arthas@123]$ thread  #查看所有线程信息
[arthas@123]$ thread 23 #查看线程ID是23 的线程
[arthas@123]$ thread -b #查看阻塞线程，block 线程
[arthas@123]$ thread -n 3 #查看最繁忙的3个线程

3、但无法确实是线程等待、block的原因时，通过trace 查看调用链路及耗时

​ 根据逐层查到耗时高的方法排查

[arthas@123]$ trace com.XXXController XXX # trace 类 方法
[arthas@123]$ trace com.XXXController XXX -n 3 # 捕捉到3次后退出
[arthas@123]$ trace com.XXXController XXX '#cost > 10' #耗时大于10ms 的请求
#更详细用法参考官方文档

4、根据逐层排查到的方法，最终应用是在哪里响应较慢，结合代码逻辑进行分析定位根因

比如是调用数据库返回较慢，最后一层调用应该是数据库连接层耗时较高。