Arthas 使用指北：线上排障别再全靠“猜”

前言

有些线上问题，乍一看像玄学。

接口突然变慢了，日志没报错，机器负载也不高，开发同学围着屏幕看了半天，最后得出一个非常有技术含量的结论：再观察观察。

如果你也经历过这种场面，那大概率会需要 Arthas。

它不是银弹，但它非常像一个能随时插进 JVM 里“看现场”的老师傅。程序已经跑起来了，不用重启，不用提前埋一堆日志，也不用一边改代码一边祈祷“希望这次能复现”。很多时候，Arthas 的价值就一句话：

出问题的时候，它能让你少靠脑补，多看事实。

这篇文章不打算把 Arthas 所有命令都铺满一屏，那样读完只会让人想关网页。我们就聊最常用、最接地气的一部分，争取做到：

• 看得懂
• 用得上
• 下次线上出事时，能想起来先开 Arthas，而不是先拜祖师爷

一、Arthas 到底是干嘛的？

简单说，Arthas 是一个 Java 诊断工具，可以在应用运行时查看类、方法、线程、JVM 状态，还能动态跟踪方法调用、观察参数和返回值，甚至临时执行一些排查动作。

你可以把它理解成：

• top、jstack、日志、临时调试输出的一个“加强缝合版”
• 给线上 JVM 开了一个“观察窗”
• 程序员深夜救火时，情绪稳定器

它最适合的场景一般有这些：

• 某个接口为什么变慢了
• 某个方法到底有没有被调用
• 传进去的参数到底是什么鬼
• 返回值为什么和我想的不一样
• CPU 飙高到底是哪几个线程在闹
• 某个类是不是我以为的那个版本

二、先启动起来

最常见的启动方式，一般是这样：

curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar

运行后，它会列出当前机器上的 Java 进程，比如：

[1]: 12345 demo-application.jar
[2]: 23456 another-service.jar

输入对应编号，Arthas 就会 attach 到目标进程。

这一步的感觉很像：

“你先别慌，让我进去看看你脑子里现在到底在跑什么。”

如果你用的是 Spring Boot、Tomcat、微服务应用，流程都差不多。选中进程后，会进入 Arthas 命令行界面，接下来就能开始排查。

三、先记住这几个高频命令

Arthas 命令不少，但真正常用的，先掌握下面这些就够你打很多场仗了。

1. dashboard：先看大盘，别一上来就瞎追

dashboard

它会展示当前 JVM 的一些整体信息，比如：

• 线程数量
• 内存使用情况
• GC 情况
• 运行状态

适合在刚连上系统时先扫一眼。

很多人排障像刑侦剧里的热血新人，一上来就冲方法级别追踪。其实更稳妥的做法是先看全局：线程多不多？GC 抖不抖？是不是整体就已经不正常了？

dashboard 就像医生量血压，虽然不能直接告诉你病根，但至少能先判断病人是不是已经快拍桌子了。

2. thread：谁在吃 CPU，一看便知

thread

如果你怀疑 CPU 高，可以直接看最忙的线程：

thread -n 5

这个命令会列出最占 CPU 的几个线程，还能看到线程状态。

如果某台机器 CPU 飙得跟起飞一样，这个命令特别实用。你可以先定位“是谁最能折腾”，再顺着线程栈继续查。

常见思路是：

1. 先用 thread -n 5 找出高 CPU 线程
2. 看线程栈在跑什么代码
3. 再结合业务判断是不是死循环、频繁重试、锁竞争或者某段逻辑特别重

很多线上 CPU 问题，说白了不是 JVM 发神经，而是代码在努力把服务器送走。

3. sc：确认类到底在不在

sc -d com.example.demo.service.UserService

sc 是 search class，用来查类的信息。

常见用途：

• 这个类到底有没有加载
• 是哪个 ClassLoader 加载的
• 类的源码位置、类信息对不对

如果你怀疑“我明明改了代码为什么没生效”，那先别急着怀疑人生，先用 sc 看看加载的到底是不是你以为的那个类。

线上最怕的不是 bug，而是你以为线上跑的是 A，结果它跑的是 B，还特别自信。

4. jad：反编译看看现场代码

jad com.example.demo.service.UserService

这个命令非常实用。它可以把 JVM 里已经加载的类反编译出来。

有什么价值？

• 看线上运行的代码到底长什么样
• 排查部署包和本地代码是不是不一致
• 验证某个分支逻辑到底有没有被打进去

很多时候，本地代码、仓库代码、构建产物、线上运行代码，这四位选手并不一定意见统一。
jad 的作用，就是让你停止争论，直接看证据。

5. sm：查某个类里有哪些方法

sm com.example.demo.service.UserService

如果你只记得类名，不记得具体方法签名，可以先用 sm 看方法列表。

比如你想观察一个方法，但名字记混了，或者重载太多，这时候先 sm 一下，比硬着头皮乱写要靠谱。

这命令像通讯录：

“人我认识，但全名一下子想不起来，你先让我翻一下。”

四、真正干活的几个命令

上面的命令偏“看信息”，下面这些则更像“直接盯现场”。

也是 Arthas 最容易让人上头的部分。

1. watch：看方法参数、返回值、异常

这是最常用的命令之一。

比如：

watch com.example.demo.service.UserService getUser '{params, returnObj, throwExp}' -x 2

它的意思大概是：

• 观察 UserService 的 getUser 方法
• 输出参数、返回值、异常信息
• -x 2 表示展开对象层级

这个命令很适合回答下面这些灵魂拷问：

• 这个方法到底收到了什么参数？
• 为什么查出来是 null？
• 为什么它抛异常了？
• 调用链上游是不是传了脏数据？

如果日志没打够，watch 就特别像临时补了个高清监控。

不过要注意，线上使用时别一把梭观察太宽泛的方法，尤其是高频调用的方法。否则你本来是去排障的，结果变成了手动制造更多输出。

建议控制范围：

• 尽量指定具体类和方法
• 必要时加条件表达式
• 先看少量样本，别上来就“全量围观”

2. trace：慢在哪一层，给我摊开讲

trace com.example.demo.controller.UserController queryUser

trace 可以追踪一个方法内部的调用耗时。

比如一个接口慢，你不确定慢在：

• 查数据库
• 调远程服务
• 数据转换
• 某个 if 分支里的神秘逻辑

这时候 trace 很有用，它会把调用路径和各层耗时列出来。

排查性能问题时，这命令基本属于“别废话，直接上证据”。

一个常见场景：

你以为慢是数据库问题，结果一 trace，发现 80% 时间都花在 JSON 转换上。
这时候你就会明白，很多性能问题不是“架构不行”，而是代码在偷偷干体力活。

3. tt：记录方法调用，像回放录像

tt 全称是 Time Tunnel，时间隧道。

名字很炫，功能也确实挺能打。

比如：

tt -t com.example.demo.service.OrderService createOrder

它会把这个方法的调用记录下来。之后你可以查看这些调用记录：

tt -l

还可以指定某条记录查看详情：

tt -i 1000

适合什么场景？

• 某个方法偶发异常，不容易稳定复现
• 你想保留调用现场，后面慢慢看
• 想对同一个问题样本反复分析

如果说 watch 像实时监控，那 tt 就更像 DVR 回放。
问题发生的时候先录下来，事后再一帧一帧看，气质都从慌张排障变成了从容办案。

4. monitor：统计方法调用情况

monitor -c 5 com.example.demo.service.UserService getUser

这个命令会周期性统计某个方法的调用指标，比如：

• 调用次数
• 成功次数
• 失败次数
• 平均响应时间

适合观察一段时间内的方法表现，而不是只看单次调用。

比如接口报错率升高，你想知道：

• 到底失败多不多
• 是持续失败还是偶发失败
• 平均耗时是不是明显上升了

这时候 monitor 很顺手。

它像值班表，不负责讲故事，但很适合告诉你：“这个人最近表现确实不太对劲。”

五、几个很实战的排查场景

光讲命令容易看完就忘。下面直接上几个常见场景。

场景一：接口很慢，但不知道慢在哪

思路可以这么走：

1. dashboard 看整体 JVM 状态
2. thread -n 5 看有没有线程异常繁忙
3. trace 跟踪目标接口方法耗时
4. 必要时对关键方法再用 watch 看参数和返回值

适合的命令示例：

trace com.example.demo.controller.OrderController submit
watch com.example.demo.service.OrderService createOrder '{params, returnObj}' -x 2

这个流程的核心原则是：

先看全局，再盯局部；先定位范围，再下钻细节。

不要一上来就对整个系统疯狂 watch，那不是排障，那是行为艺术。

场景二：接口返回结果不对

比如用户说：“这个接口查出来的数据不对。”

先别急着甩锅数据库、缓存、第三方接口和水逆。

可以这样查：

1. watch 看 controller 或 service 方法入参
2. 看返回值是不是从这里开始歪的
3. 如果逻辑复杂，用 trace 看分支耗时和调用过程
4. 用 jad 看线上实际代码是不是你预期的版本

示例：

watch com.example.demo.service.UserProfileService queryProfile '{params, returnObj, throwExp}' -x 3
jad com.example.demo.service.UserProfileService

很多“结果不对”的问题，最后都不是框架锅，而是某个参数一路传着传着，半路就长歪了。

场景三：偶发异常，日志又不完整

这个最烦。

因为它不稳定、难复现、还喜欢在你下班前十分钟出现。

这时候可以优先考虑：

tt -t com.example.demo.service.PaymentService pay

把调用先录下来，等异常出现后再：

tt -l
tt -i 1001

这样至少能把出问题那次调用的参数、返回、异常现场抓住。

有时候排障最痛苦的不是问题难，而是你根本没拿到现场。
tt 的意义，就是帮你把“案发录像”留住。

六、Arthas 不是越猛越好，用的时候要有分寸

这部分很重要。

Arthas 很强，但不是让你在线上随便开“上帝视角”的理由。命令用得不克制，可能会带来额外开销，尤其是：

• 盯高频方法
• 打印大对象
• 观察范围过宽
• 长时间持续输出

几个实用建议：

• 先缩小目标，不要一把抓全服务
• 优先针对具体类、具体方法
• 对象展开层级别开太大，-x 2、-x 3 通常够用了
• 用完及时停掉相关命令
• 在线上高峰期操作要更谨慎

说直白点：

Arthas 是手术刀，不是电锯。

你是去定位问题的，不是去给线上服务做行为实验的。

七、新手最容易踩的几个坑

1. 方法名写对了，结果就是没输出

可能原因：

• 类名没写全
• 方法签名没匹配上
• 目标方法根本没被调用
• 你 attach 错进程了

别笑，这个问题发生频率相当高。很多时候不是 Arthas 不工作，是人工作得比较有想象力。

2. 输出太多，把自己看晕了

这是 watch、trace 常见问题。

建议从最小范围开始，先看一两个请求，再逐步扩大，不要一开始就让终端进入“瀑布模式”。

如果你看到输出疯狂滚动，心里开始发虚，通常说明你观察得太猛了。

3. 只盯技术指标，不结合业务判断

Arthas 能告诉你“发生了什么”，但不一定直接告诉你“为什么业务会这样”。

比如你看到一个方法耗时高，不代表它一定有 bug；也可能是这个请求本来就需要查很多数据。

所以排查时一定要结合：

• 请求场景
• 业务入参
• 调用链上下文
• 近期发布记录

工具负责给证据，人负责做判断。
别把工具当算命先生。

八、给一份够用的排障套路

如果你现在只想先记住一套“线上排障起手式”，可以记这个：

1. 进入 Arthas，确认进程
2. 用 dashboard 看整体状态
3. 用 thread 看线程和 CPU
4. 用 sc、sm、jad 确认类和方法没找错
5. 用 trace 找耗时点
6. 用 watch 看参数、返回值、异常
7. 遇到偶发问题，用 tt 留现场

这套不一定覆盖所有复杂场景，但处理日常线上问题，已经相当能打。

九、最后总结

Arthas 真正厉害的地方，不是命令多，也不是界面酷，而是它让线上问题从“靠猜”变成“可观察”。

以前很多排障过程像这样：

• 我感觉是这里有问题
• 我猜可能是缓存
• 我怀疑是线程池
• 我觉得数据库有点可疑

用了 Arthas 以后，风格会逐渐变成：

• 参数就是这样传进来的
• 这层调用耗时最高
• 这个线程确实在忙这个方法
• 线上跑的代码就是这个版本

这就是区别。

它不会替你解决所有问题，但能让你少走很多弯路。
对于 Java 开发来说，Arthas 非常值得熟悉，尤其是做线上排障、性能分析、问题定位的时候，几乎属于“会了不一定天天用，但真出事时会非常想它”。

如果要用一句大白话收尾，那就是：

线上出问题时，别急着拍脑袋，先让 Arthas 说话。