Arthas 在线上排障到底怎么用？一次讲清 dashboard、thread、trace、watch 与常见实战场景

大家好，我是一名有 4 年工作经验的 Java 后端开发。
如果说线上 Java 排障有一个工具是我特别推荐掌握的，那 Arthas 一定算一个。
这篇文章我不想只介绍命令，而是想从线上排障场景出发，讲清楚 Arthas 到底适合解决什么问题、最常用哪些命令、什么场景下应该怎么用。

🦅个人主页
🐼

---

一、前言

很多人第一次用 Arthas，通常会有两个极端：

• 觉得命令很多，不知道从哪下手
• 上来就 trace、watch、jad 一顿敲，结果现场更乱

实际上，Arthas 最适合的不是“乱试命令”，而是：

在你已经大致知道问题方向时，用很低的代价快速确认现场。

它特别适合这些场景：

• 某个接口为什么慢
• 哪个线程卡住了
• 某个方法到底执行了多久
• 某个参数是不是异常
• JVM 内存是不是有问题

这篇文章就按线上排障思路来讲。

---

二、Arthas 最适合解决什么问题

我更建议你把 Arthas 理解成：

在线 Java 诊断工具箱。

它不一定替代：

• Prometheus / Grafana
• APM
• GC 日志
• MAT

但它非常适合做最后一跳确认。

比如：

• 监控看到接口慢了
• Trace 看到是某个方法慢
• 这时候 Arthas 上去一看线程、方法耗时、参数内容，往往就能快速定方向

---

三、最常用的几个命令到底怎么用

3.1 dashboard

先看全局概况。

dashboard

适合看：

• CPU
• 内存
• GC
• 线程数
• 运行概况

这通常是我上线后先看的第一个命令之一。

3.2 thread

看线程问题。

thread -n 10

适合看：

• 哪些线程最耗 CPU
• 哪些线程卡住了
• 是否有死锁风险

3.3 jad

反编译类。

jad com.demo.OrderService

适合确认：

• 线上跑的到底是不是你以为的代码

3.4 trace

跟踪方法耗时。

trace com.demo.OrderService submitOrder

适合看：

• 这个方法内部哪些调用最耗时

3.5 watch

观察方法参数、返回值、异常。

watch com.demo.OrderService submitOrder "{params, returnObj, throwExp}" -x 2

适合看：

• 传进来的参数到底对不对
• 返回值是不是异常
• 方法有没有抛异常

3.6 stack

看调用路径。

stack com.demo.OrderService submitOrder

适合确认：

• 某个方法是从哪里被调用进来的

---

四、几个典型线上场景怎么用 Arthas

4.1 场景一：接口变慢了

排查顺序通常是：

1. dashboard
2. thread -n 10
3. trace 某个核心方法

比如：

trace com.demo.OrderConfirmService confirm '#cost > 100'

这样可以只看耗时超过 100ms 的调用。

4.2 场景二：怀疑参数异常

比如你怀疑某个接口慢是因为传入数据异常。

可以：

watch com.demo.OrderService submitOrder "{params}" -x 2

这样可以快速看到实际入参。

4.3 场景三：怀疑线程池堆积或死锁

可以先：

thread -n 20

必要时再看：

thread <id>

4.4 场景四：怀疑内存有问题

可以配合：

memory

和：

dashboard

先快速看内存和 GC 概况。

---

五、Arthas 使用时最容易踩的坑

5.1 上来就大范围 trace

比如直接 trace 特别高频的方法，线上压力可能会进一步变大。

5.2 watch 打印对象太深

如果对象很大，输出会很多，也容易干扰现场。

5.3 把 Arthas 当成唯一排障工具

它很好用，但更适合配合：

• 监控
• Trace
• GC 日志
• 慢查询

一起使用。

5.4 没有目标，命令乱试

Arthas 最怕“没有方向就一直敲命令”，这样效率很低。

---

六、面试中怎么回答

如果面试官问你：

Arthas 在线上排障一般怎么用？

你可以这样回答：

第一，我会把 Arthas 当成线上问题定位的确认工具，而不是替代监控和链路追踪。通常先通过监控和 Trace 确认问题大致方向，再用 Arthas 做最后一跳定位。

第二，最常用的命令一般是 dashboard、thread、trace、watch。dashboard 用来看全局概况，thread 看线程问题，trace 跟踪方法耗时，watch 看参数、返回值和异常。

第三，如果是接口慢，我通常会先看线程和全局负载，再 trace 某个核心方法；如果怀疑参数异常或业务分支问题，会用 watch 看实际入参和返回值。

第四，线上用 Arthas 要控制范围，不会一上来就去 trace 高频方法或者打印特别大的对象，避免对现场造成额外影响。

---

七、总结

Arthas 真正好用的地方，不是命令多，而是它能让你在不重启应用的前提下，快速确认 Java 进程里到底发生了什么。

如果只记一句结论，我觉得可以记住这句：

Arthas 最适合作为线上排障的“最后一跳确认工具”，先有方向，再精准下手。

---

八、结尾

如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注。
后面我会继续整理一些更偏实战的 Java 后端和线上排障文章。