java -jar 未响应_手把手教你使用Arthas的trace命令排查线上服务平均响应时间太长问题...

你知道的越多，不知道的就越多，业余的像一棵小草！

你来，我们一起精进！你不来，我和你的竞争对手一起精进！

编辑：业余草

来源：suo.im/5XtQMD

推荐：https://www.xttblog.com/?p=5112

前言

最近线上环境某个接口服务响应时间偏长，导致用户体验超差，那平时该怎么快速的排查这类问题呢？

• 为代码添加上详细的打印日志；不建议，一是线上环境，没法随便的重新部署更换了详细日志的代码，二是 添加详细的日志输出，那就意味这会生成大量的日志文件，这些日志文件会占据大量服务器磁盘空间。
• 搭建一个模拟了线上环境的测试环境进行复盘排查；额，出现了这种问题哪有那么多的时间让你进行环境复盘排查，所以此方案也是 不建议的 。
• 线上诊断神器 Arthas ，这个工具是阿里开源的，专门用于线上环境问题排查的，这个工具提供了很多的命令用来排查问题；当出现上面的响应时间偏长的问题，就可以使用 Arthas 提供的trace命令进行排查，使用这个工具的 trace 命令可以统计到方法中整个调用链路上的所有性能开销和追踪调用链路，查找其中耗时比较长的方法再具体排查即可。

本文接下来将从两方面展开：

• 搭建模拟线上服务接口响应时间偏长的环境；SpringBoot 服务接口 +  JMeter 模拟服务接口调用；
• 使用诊断神器 Arthas 提供的命令 trace 命令进行响应时间偏长的问题排查；

下面我们先模拟线上环境：利用 SpringBoot 项目搭建，并且编写好服务接口；

注意：服务接口代码为了简便，只写了 一些大循环的代码 来模拟较长的耗时；除此之外，实际上还包含很多多其它常见的情况，例如：

• 服务接口方法中存在很多的  JDBC 操作 ，并且由于数据库中数据量太大，导致很多的 JDBC 查询非常耗时，并且此时可能由于还没有创建合适的索引，导致查询耗时更加的长，最终导致服务接口响应时间偏长；
• 此服务接口中调用了 其它的服务接口 ，由于内部调用的其它服务接口出现问题等，导致此其它服务接口执行耗时比较长，进而导致服务接口响应时间偏长；

服务接口代码如下：

test1、test2方法如下：

第二步 JMeter 模拟用户调用的测试脚本配置：

第三步服务接口 SpringBoot 代码 和 JMeter 测试脚本的所在项目位置：

服务接口代码准备好后，使用IDEA开发工具等方式将其导出为 Jar 包 。

为了模拟最为真实的线上环境，需将准备好的 服务接口 Jar 包放到 服务器中，然后使用命令 java -jar *.jar 运行起 Jar 包；然后使用 JMeter 进行接口的调用，在 聚合报告 中发现平均响应时间偏长；如图：

如果有用户反映某功能响应时间太长了，别着急，根据下面的方法进行排查，绝对方便又快速的找到问题原因。

Arthas 问题排查：

• 首先需要下载阿里开源的Arthas 的诊断工具 Jar 包：arthas-boot.jar；然后将 Jar 包放到 部署服务接口项目的服务器中 。
• 然后使用 ps 命令，查询出当前运行服务接口的程序进程号；例如：本文章模拟的服务接口程序 Jar 包名称为 springboot_arthas-1.0.0.jar ，所以命令为：ps -ef | grep springboot_arthas-1.0.0  。
• 然后运行Arthas 诊断工具，命令：java  -jar  arthas-boot.jar ；开始运行的界面如图：

此时诊断工具还没有运行完，需要手动选择要诊断/监控的java 进程，并且此工具也会列出全部的java进程号，你只需要输入 它们最前的序号 [1] 即可；如图：

运行完后，可以使用 trace命令 监控服务接口方法中调用的其它方法的耗时；

trace 命令能主动搜索 class-pattern／method-pattern 对应的方法调用路径，渲染和统计整个调用链路上的所有性能开销和追踪调用链路。

具体命令格式：trace [全限定类名][类中的方法名]

例如：监控本服务接口；com.lyl.controller.TestController : 全限定类名，process：TestController 类中的方法；

具体命令举例如下所示：

trace com.lyl.controller.TestController process

trace 命令执行结果展示，如图：

❝

通过trace 命令监控统计的调用链路各个方法的执行耗时，可以发现调用的 com.lyl.util.StringUtil 类中的 test2() 方法执行耗时比较大；所以需要特别去查看这个方法的代码是否存在问题；如果这个代码中还存在许多的方法调用链路，则需要再次使用 trace 命令进行监控调用链路的耗时，找出具体可能存在问题的方法。

❞

Arthas 阿里开源的诊断工具还提供了很多的命令供使用，大家可以去查看学习。B站搜“业余草”也可以查看到我之前录制的视频教程。

另外这里有两个需要注意的地方：

• 使用Arthas 诊断的程序代码，在打包时 不能混淆 ，否则在使用trace 命令会报 类或方法找不到；
• 在使用trace命令监控统计时，需要JMeter测试脚本正在运行调用服务接口，如果没有调用，则统计不到内部调用链路的耗时情况；

如果有看不懂本文的，或者暂时用不到这些技术的先收藏起来，等急用时方便查阅资料。