大家好，我是程序员天天困。
这是「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
拆开看四个关键点：
trace：启用路径追踪。类全名 + 方法名：被追踪的入口，和 watch 一样。-n 5：只抓 5 次就退出，线上别无限挂着。--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。
| 场景 | 建议 | 原因 |
|---|---|---|
| 确认业务 if/else 走到哪 | --skipJDKMethod true（默认） |
树短，行号清晰 |
| 怀疑慢在 JDK/工具方法 | --skipJDKMethod false |
能看见 java.* 节点耗时 |
| 接口整体很慢、调用很深 | 先 #cost 过滤，再决定是否展开 JDK |
先降噪，再放大 |
五、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 |
|---|---|---|
| 核心问题 | 入参 / 返回值 / 异常对象是什么 | 走了哪条路径、哪段最耗时 |
| 输出形态 | 观察表达式结果 | 调用树 + 耗时 |
| 典型场景 | 结果不对、怀疑多算/少算 | 分支未执行、接口慢 |
| 常见组合 | 先看结果对不对 | 再看路径与热点 |
实战口诀就一句：先 watch 验结果，再 trace 验路径和耗时。 大部分线上「结果怪」或「延迟高」的问题，这两步就能收敛到具体方法甚至具体行号。
结语
Arthas trace 补上的，是 watch 看不见的那半边：过程与耗时。会用路径确认分支、会用 #cost 过滤噪音、知道一次只加深一层，你就已经超过很多「只会复制插件命令」的用法。
下一篇我会写 vmtool，聊聊怎么在不重启的前提下直接摸到 JVM 里的对象实例。本文命令参数以 Arthas 官方 trace 文档 为准，版本演进时请以官网为准。
我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你用 Arthas trace 时，有没有一次靠行号当场拆穿「假修复」的经历。
