Arthas trace 命令怎么用？一行定位最慢那行代码

大家好，我是程序员天天困。

这是「Arthas 线上诊断实战」系列第 2 篇。上一篇讲完 watch 命令实战，很多读者有疑问：入参对了、返回值也对了，可我还是不知道代码到底走了哪条分支，接口慢又该盯哪一层。

答案就是 Arthas trace：贴一条命令，调用树和行号直接告诉你走了哪条分支、哪一层最耗时。点个收藏，我们直接上手。

一、watch 的盲区：只见结果，不见过程

还是用系列同款计算器接口：

@RequestMapping(path = "/user/calculate", method = RequestMethod.GET)
public Integer calculate(@RequestParam("x") Integer x,
                         @RequestParam("y") Integer y,
                         @RequestParam(name = "op") String op) {
   
    return doCalculate(x, y, op) + 1;
}

public int doCalculate(int x, int y, String op) {
   
    if ("add".equals(op))      return x + y;
    else if ("sub".equals(op)) return x - y;
    else if ("mul".equals(op)) return x * y;
    else if ("div".equals(op)) return x / y;
    else throw new UnsupportedOperationException("NotSupportOp" + op);
}

假设请求是 x=2&y=2&op=add。你用 watch 盯 doCalculate：

watch com.ttk.controller.WebController doCalculate \
  '{params,returnObj,throwExp}' -n 5 -x 3

返回值是 4。问题来了：2+2 也是 4，2*2 也是 4。watch 只告诉你「结果是 4」，不告诉你到底走进了 add 还是 mul。

watch 擅长验结果，不擅长验路径。 线上最常见的「接口慢但不知道慢在哪」，就卡在这个盲区上。

二、Arthas trace 是什么：给方法内部装行车记录仪

Arthas trace（方法路径追踪）：Arthas 用来打印某个方法内部调用路径、并统计路径上每个节点耗时的命令。你可以把它理解成「给方法内部装上行车记录仪」：走过哪条岔路、每一段花了多少毫秒，仪表盘上全有。

官方文档对它的定位很直接：主动搜索匹配方法的调用路径，渲染整条链路上的性能开销。搜索关键词「Arthas trace 官方文档」即可找到最新参数说明。

IDEA 里对目标方法右键 → Arthas Command → Trace，通常会复制出类似命令：

trace com.ttk.controller.WebController doCalculate  -n 5 --skipJDKMethod false

拆开看四个关键点：

1. trace：启用路径追踪。
2. 类全名 + 方法名：被追踪的入口，和 watch 一样。
3. -n 5：只抓 5 次就退出，线上别无限挂着。
4. --skipJDKMethod false：是否把 JDK 内部调用也打出来（默认跳过）。

用 #cost 做耗时过滤：#cost 是 Arthas 条件表达式里能用的一个变量，代表方法执行耗时（单位 ms），watch / stack / trace 都支持。写法如 '#cost > 100'，只输出执行超过 100ms 的调用。你可以把它想成「只给超时工单开录像回放」，正常的快速调用直接略过，噪音少很多。

三、Arthas trace 看执行路径：代码到底有没有走到

先 attach 好进程（第 1 篇已讲过，此处不重复），贴上命令，再发请求：

curl 'http://localhost:8080/user/calculate?x=2&y=2&op=add'

树里的 #行号 是关键证据：它标的是「在被 trace 的那个方法源码的第几行发起了这次调用」。op=add 时，你会看到执行落到加法对应的那一行。

再把 op 换成 mul，发一次：

curl 'http://localhost:8080/user/calculate?x=2&y=2&op=mul'

行号对得上，分支才算真的走到了。 同一个 doCalculate，op=add 和 op=mul 落在两行不同的行号上——这就是 trace 比 watch 多看见的那半边：过程。

可能有人会问：一次 trace 能顺着往下钻十几层吗？官方明确说过，一次 trace 默认只跟踪匹配方法这一级子调用，不会自动无限下钻；想看更深，要用正则一次匹配多个类方法，或用后面说的动态 trace。别指望一条命令把整棵调用树全展开，那对线上 JVM 太贵。

四、--skipJDKMethod：JDK 调用要不要展开

默认 --skipJDKMethod 为 true，也就是跳过 java.* 一类调用，树更干净。排查业务分支时，这样通常够用。

当你怀疑慢在字符串拼接、集合操作、或者某个 JDK 工具方法时，再打开：

trace com.ttk.controller.WebController doCalculate \
  -n 3 --skipJDKMethod false

这时树会变「茂盛」：StringBuilder、Integer.valueOf 之类都会冒出来。信息变多，也更容易被噪音淹没。我的习惯是：先默认跳过 JDK，定位到业务方法后，再对可疑节点单独开 false。

五、Arthas trace 耗时分析：揪出接口最慢那一层

路径之外，trace 更大的日常价值是找慢点。给控制器加一组串行 sleep 示例：

@RequestMapping(path = "/user/cost", method = RequestMethod.GET)
public Integer cost() throws InterruptedException {
   
    cost1();
    cost2();
    cost3();
    return 1;
}

public void cost1() throws InterruptedException {
    Thread.sleep(100); }
public void cost2() throws InterruptedException {
    Thread.sleep(200); }
public void cost3() throws InterruptedException {
    Thread.sleep(300); }

预期总耗时大约 600ms+。线上等价场景是：一个接口串行打了三个下游，P99 飙高，日志却只有总耗时。

trace com.ttk.controller.WebController cost -n 5 --skipJDKMethod false

触发请求：

curl 'http://localhost:8080/user/cost'

输出里每个子调用都会带耗时；Arthas 还会用百分比标出每个子调用占入口耗时的比例，占比高的自然就是慢点。一目了然，不用猜。

请求很频繁时，别把所有调用都打出来，加上耗时过滤：

trace com.ttk.controller.WebController cost '#cost > 200' -n 5

这样只保留总耗时超过 200ms 的样本。可能有人会问：trace 出来的毫秒数能不能当性能测试报告？别急，官方也提醒过——trace 自己有观测开销，子节点耗时加总往往小于父节点，差值就来自未追踪的 JDK 调用、字节码指令，甚至 GC 停顿。

六、异常也是一条路径

异常对 trace 来说，并不是特殊物种，只是执行路径的另一种走向。把 op 改成不支持的值，例如：

curl 'http://localhost:8080/user/calculate?x=2&y=2&op=add2'

再试运行时异常，比如除零（op=div&y=0）：

curl 'http://localhost:8080/user/calculate?x=2&y=0&op=div'

异常现场要用 watch 看对象，用 trace 看走到了哪。 两者叠在一起，比单独翻 error 日志更立体：一个告诉你「抛了什么」，一个告诉你「从哪条分支抛出来的」。

七、动态 trace：一层不够就再挖一层

Arthas 3.3.0 之后支持动态 trace：第一次 trace 入口方法时，终端会打印 listenerId；另开一个 Arthas 连接，对可疑子方法再 trace ... --listenerId <同一个 id>，原来的终端里调用树会多长出一层。

动态 trace（按 listenerId 加深）：在已有 trace 会话上，用同一个 listenerId 继续增强子方法，让调用树多长出一层的能力。你可以把它理解成「行车记录仪先拍主干道，发现堵车口再往小巷加一路摄像头」，而不是一上来全城监控。

这招适合「已经锁定慢在 A，还想看 A 里面到底是 B 还是 C」。比一上来用大正则扫半个包要克制，线上也更安全。我自己的顺序通常是：入口 trace → 看最慢子调用 → 动态加深一层 → 必要时再 watch 该节点的入参。

八、watch 和 Arthas trace 怎么搭配

实战口诀就一句：先 watch 验结果，再 trace 验路径和耗时。 大部分线上「结果怪」或「延迟高」的问题，这两步就能收敛到具体方法甚至具体行号。

结语

Arthas trace 补上的，是 watch 看不见的那半边：过程与耗时。会用路径确认分支、会用 #cost 过滤噪音、知道一次只加深一层，你就已经超过很多「只会复制插件命令」的用法。

下一篇我会写 vmtool，聊聊怎么在不重启的前提下直接摸到 JVM 里的对象实例。本文命令参数以 Arthas 官方 trace 文档 为准，版本演进时请以官网为准。

我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你用 Arthas trace 时，有没有一次靠行号当场拆穿「假修复」的经历。