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

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

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

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

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

```java
@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`：

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

![](https://developer.qcloudimg.com/http-save/yehe-11608098/55176de17f46115fabbc2f9558ba7b95.png)

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

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

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

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

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

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

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

![](https://developer.qcloudimg.com/http-save/yehe-11608098/8a6334ab2edccc26b4c24d1efe9efc20.png)

拆开看四个关键点：

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 篇已讲过，此处不重复），贴上命令，再发请求：

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

![](https://developer.qcloudimg.com/http-save/yehe-11608098/88613ed65490c1b568c7415b51d50bdc.png)

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

再把 `op` 换成 `mul`，发一次：

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

![](https://developer.qcloudimg.com/http-save/yehe-11608098/cb3a1729be1ff078092fe9b130603d51.png)

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

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

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

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

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

```bash
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 示例：

```java
@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 飙高，日志却只有总耗时。

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

触发请求：

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

![](https://developer.qcloudimg.com/http-save/yehe-11608098/b42885bd09a75aa1626b411aae4a2f49.png)

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

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

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

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

## 六、异常也是一条路径

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

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

![](https://developer.qcloudimg.com/http-save/yehe-11608098/ef9be0d966275d29435beb867de168d4.png)

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

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

![](https://developer.qcloudimg.com/http-save/yehe-11608098/edce9995d39fb65bfefe56f0410af55a.png)

**异常现场要用 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 文档](https://arthas.aliyun.com/doc/trace.html) 为准，版本演进时请以官网为准。

---

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

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

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

Arthas trace 弥补 watch 只见结果不见过程的短板：追踪调用路径、统计耗时，快速定位慢接口与未执行分支

架构设计

"Arthas trace命令实战：精准定位代码执行路径与性能瓶颈。通过方法调用树+行号追踪，解决watch命令无法判断分支走向的痛点，快速识别接口慢的根源。详解trace参数配置、耗时分析技巧及与watch的配合使用，帮助开发者高效排查线上问题。掌握#cost过滤和动态trace技巧，提升Java应用诊断效率。"

性能测试

代码解释

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Arthas trace 命令怎么用？一行定位最慢那行代码-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐