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

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

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

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

使用者痛点：线上排查时只能看到返回值，却看不清到底走到了哪个业务分支，导致“接口慢但不知道慢在哪”卡在原地。

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

@RequestMapping
public Integer calculate Integer x。@RequestParam Integer y,@RequestParam String op) {
return doCalculate;}
public int doCalculate {
if ) return x + y;else if ) return x - y;else if ) return x * y;else if ) return x / y;else throw new UnsupportedOperationException;不过，}

假设请求是 x=1&y=2&op=add。说起来，你用 watch 盯 doCalculate

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

返回值是 3。再看问题来了，"+" 也是返回值。"*" 也是返回值。watch 只告诉你「结果是 3」。不告诉你到底走进了 add 还是 mul.

watch 擅长验结果，不擅长验方法。

：给方法内部装行车记录仪

User Pain Point：需要看到方法内部的调用链还有每一步的耗时以定位真正的瓶颈。

Arthas trace: Arthas 用来打印某个方法内部调用方法，并统计方法上每个节点耗时的命令。把它想象成「给方法内部装上行车记录仪」——走过哪条岔路、每段花了多少毫秒，一目了然。

The official docs describe it as “主动搜索匹配方法的调用方法，渲染整条链路上的性能开销”。搜索关键词 “Arthas trace 官方文档” 即可找到最新参数说明。

IDEA 中右键目标方法 → Arthas Command → Trace，会自动生成类似命令：

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

Dismantling command:

• trace: 启用方法追踪。
• <类全名> <方法名>: 被追踪的入口。
• -n <次数>: 只抓 N 次后自动退出，线上避免无限挂起。
• --skipJDKMethod false: 是否把 JDK 内部调用也打印出来。

#cost 做耗时过滤：#cost 是 Arthas 条件表达式里可用的变量，代表当前方法执行耗时。写法如 '#cost> 100'。只输出执行超过 100 ms 的调用，实现“只录像超时工单”。

三、Arthas trace 看执行方法：代码到底有没有走到？

Pain point 凸显——我们不仅要知道结果，还要确认业务分支是否真的被触发。怎么说呢，

1. Attach 到目标进程。
2. 执行 trace 命令后发送请求：

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

The output tree contains a node like #行号:12 . 当 ?op=addE 时你会看到调用落在加法对应的那一行。

If you change param to ?老实说，op=mulE and repeat:

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

The line number changes accordingly. **行号对得上，分支才算真的走到了**——这正是 trace 能帮你弥补 watch 看不到的过程信息。

If you wonder wher one trace can dig ten levels deep: 官方明确指出，一次 trace 默认只跟踪匹配方法 **这一级子调用**；怎么说呢，想更深，需要使用正则一次匹配多个类/方法或使用动态 trace。不要指望单条命令把整棵调用树全部展开，那对线上 JVM 开销太大。

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

• Pain point: 业务代码没问题。却怀疑慢在 JDK 工具类，此时默认跳过会让你看不到关键节点。
•  --skipJDKMethod true 。跳过所有 java.* 调用，使树更简洁。
•  

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

• A 打开后你会看到诸如 , 等节点出现。信息增多也代表着噪音增加。推荐策略是:先默认跳过 JDK，定位到业务节点后再针对可疑子节点打开 false。.
​ ​ ​ ​ ​ ​ ​ ​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​ ​ ​ ​

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

... Oops this got messy due to accidental extra markup. Let's correct and provide clean final HTML.

This is **Arthas 在线诊断实战** series. In previous article we introduced `watch` command. Many readers asked:

• The input parameters look correct.
• The return value is also correct.
• I still don’t know which branch of code was executed.
• If interface is slow,which layer should I focus on?

The answer is **Arthas `trace`** – one line of command will give you both call tree and line numbers,so you instantly know which branch and which layer consumes most time.

一、watch 的盲区：只见结果。不见过程 🎯️️️️️️️️️️️️️️‍‍‍‍‍‍‍‍‍‍‍‍✦✦✦✦✦✦✦✦✦✦🟢🟢🟢🟢🟢🟢🟢⚠︎⚠︎⚠︎⚠︎⚠︎⚠︎⚠︎⚠︎⚠︎⚠︎⚠︎💡💡💡💡💡💡💡💡💡📍📍📍📍📍 📍 📍 📍 📍 📍 📍 📍 📍 📍 🧭 🧭 🧭 🧭 🧭 🧭 🧭 ⚙ ⚙ ⚙ ⚙ ⚙ ⚙ ⚙ 💥 💥 💥 💥 💥 💥 💥 🔎 🔎 🔎 🔎 🔎🔎🔎🔎🔎🔎🔎🔎🔎🚩🚩🚩🚩🚩🚩 🚨 🚨 🚨 🚨 🚨 🚨 🚨 😱 😱 😱 😱 😱 😱 🙁 🙁 🙁 🙁 🙁 🙁 🙁🙈🙈🙈🙈🙈🙈🙈🐛🐛🐛🐛🐛🐛🐛🐛🥀🥀🥀🥀🥀🥀🌋🌋🌋🌋🌋🌋🌋🏹🏹🏹🏹🏹🏹🏹⏰⏰⏰⏰⏰⏰⏰🍂🍂🍂🍂🍂🍂🍂🎬🎬🎬🎬🎬🎬🎬🔥🔥🔥🔥🔥🔥🔥❗❗❗❗❗❗❗✅✅✅✅✅✅✅👀👀👀👀👀👀👀😐😐😐😐😐😐😐🙂🙂🙂🙂🙂🙂🙂📊📊📊📊📊📊📊⬆⬆⬆⬆⬆⬆⬆↔↔↔↔↔↔↔☕☕☕☕☕☕☕📝📝📝📝📝📝📝⌚⌚⌚⌚⌚⌚⌚🤔🤔🤔🤔🤔🤔🤔👍👍👍👍👍👍👍🙏🙏🙏🙏🙏🙏🙏✨✨✨✨✨✨✨👏👏👏👏👏👏👏▶▶▶▶▶▶▶➤➤➤➤➤➤➤🔝🔝🔝🔝🔝🔝🔝➡➡➡➡➡➡➡————线上排查只能看到**结果**却看不到**真实方法**，导致“接口慢但不知道慢在哪”卡住不前。java @RequestMapping public Integer calculate Integer x。@RequestParam Integer y,@RequestParam String op) { return doCalculate;} public int doCalculate { if ) return x + y;else if ) return x - y;else if ) return x * y;else if ) return x / y;else throw new UnsupportedOperationException;按理说，} 假设请求是 `x=1&y=2&op=add`，使用 `watch` 来监控 `doCalculate`： bash watch com.ttk.controller.WebController doCalculate \ '{params。returnObj,throwExp}' -n -x 得到的返回值是 `3`，但我们仍然不知道实际走的是 `add` 分支还是 `mul` 分支。`watch` 擅长验证结果，不擅长验证方法。

场景	建议	原因
确认业务 if/else 是否被执行	--skipJDKMethod true	树短，行号清晰
怀疑慢在 JDK/工具 方法	--skipJDKMethod false	能看到 java.* 节点及其耗时
接口整体很慢且调用层级深	先 #cost 过滤，再决定是否展开 JDK	先降噪。再放大