为什么越来越多人用Arthas 4 ？

苏三说技术
0 阅读12分钟

前阵子一个跑了三年的老服务，突然在每天下午三点左右开始卡顿。

CPU 不高，内存也正常，GC 日志看不出毛病。

日志里没有任何异常，监控指标一切“正常”。

但用户就是感觉慢，接口 P99 从 50ms 涨到了 800ms。

团队小伙伴排查了两天，毫无头绪。

有人提议重启试试，但这是个核心服务，重启的窗口期很难批。而且就算重启了，问题大概率还会回来——你连根因都没找到，重启只是把问题藏起来。

我先让他们别重启。然后挂上 Arthas，敲了几条命令。

第一条，thread -n 5，看 CPU 占用最高的五个线程。发现一个叫 pool-7-thread-3 的线程长期占用 CPU，但栈信息显示它一直在做 HashMap.get()。

第二条，trace 那个线程在跑的方法，看调用链路。发现一个本该走本地缓存的地方，因为缓存 key 拼错了，每次都在走一个同步的远程调用。远程服务响应慢的时候，线程就卡在那里。

整个排查过程，不到十五分钟。没有重启，没有改代码，没有加日志。

这就是 Arthas 的价值。

它不是“又一个监控工具”，它是一个能让你在线上运行的 JVM 里直接“做手术”的探针。

你不用改代码、不用重启、不用等下一个发版窗口，就能看清线程在干什么、方法被谁调用、返回值是什么、耗时花在哪。

而 Arthas 4，是这个工具在 2026 年的一次大版本升级。

它把 JDK 支持拉到了 25，把火焰图能力补全了，还做了一件很有意思的事——让你用自然语言让 AI 帮你跑诊断命令。

今天这篇文章，我就把 Arthas 4 到底强在哪、怎么用、适合什么场景，从头到尾给你拆解一遍。

希望对你会有所帮助。

更多项目实战在Java突击队网：susan.net.cn/project

一、Arthas 到底是什么？

有些小伙伴可能会说：“我用 jstack、jmap、jstat 不也能排查问题吗？”

能。

但那些是 JDK 自带的命令行工具，用起来有一个共同的问题：你需要在启动应用之前就规划好，或者至少知道该用哪个工具、看什么指标。

Arthas 不一样。

它是一个 Java Agent，通过 attach 机制挂到正在运行的 JVM 上，不需要重启、不需要改代码、不需要提前埋点。

挂上去之后，你可以在它的交互式终端里敲命令，像用 shell 一样诊断 JVM。

它的核心能力可以分成几类：

看全局：dashboard 看线程、内存、GC、系统负载；jvm 看 JVM 参数和类加载统计。

看线程：thread 看线程栈，thread -n 找 CPU 最高的线程，thread -b 找死锁。

看方法：watch 看入参和返回值，trace 看调用链路耗时，monitor 看周期性统计，tt 记录调用快照事后回放。

看类：sc 搜索已加载的类，jad 反编译运行时字节码，classloader 看类加载器。

热更新：jad + mc + redefine 一条龙，改完方法体直接生效，不用重启。

性能分析：profiler 生成火焰图，jfr 采集 JVM 飞行记录。

二、Arthas 4 到底“新”在哪？

Arthas 3.x 已经是很成熟的工具了。

4.x 的升级，我认为主要在三个方向：跟上 JDK 的演进、补全性能分析能力、拥抱 AI 工作流。

2.1 JDK 支持：从 8 到 25

Arthas 4 要求 JDK 8 及以上，官方明确说明支持 JDK 17、21、25。这意味着你的团队如果已经把运行时切到了 JDK 21 甚至更新的版本，Arthas 4 能直接挂上去，不需要为了诊断工具而保留老版本 JDK。

同时，依赖也做了一轮升级。Jackson、Fastjson2、OGNL、Netty 都升到了更新版本。

诊断工具本身也是软件，它自己的依赖安全同样重要。

2.2 火焰图：从“看 CPU”到“看墙钟时间”

profiler 命令内置了 async-profiler，4.2.0 版本升级到了 4.4。更重要的是，从 4.0.2 起支持 --wall 参数，可以看墙钟时间。

这个能力解决了一类很头疼的问题：CPU 看起来不高，但接口就是慢。

典型的场景是锁等待、网络 IO 阻塞、数据库连接池耗尽。这些情况下线程在“等”，不消耗 CPU，传统的 CPU 火焰图看不出来。

墙钟火焰图能把这些“等待时间”暴露出来，让你知道时间到底花在了哪里。

另外，会话默认超时从 30 分钟放宽到了 3 小时。采样跑一半被踢下线这种事，不会再发生了。

2.3 MCP Server：让 AI 帮你跑诊断命令

这是 Arthas 4 最有意思的变化。

MCP（Model Context Protocol） 是一套让 AI 助手调用外部工具的协议。

Arthas 4 在自己的 HTTP 服务上实现了 MCP Server，AI 客户端连上来之后，可以像调用函数一样执行 Arthas 的诊断命令。

文档里列出了 29 个诊断工具，dashboard、thread、trace、jad、profiler 这些都在里面。Cherry Studio、Cline、Claude Desktop 这类客户端配置好之后，你可以用自然语言说“看看哪个线程最忙”或者“追踪一下这个方法的调用链路”，AI 会帮你跑对应的命令，然后把结果整理给你。

这个能力目前还是实验模块，但方向很清晰：诊断的门槛在降低。以前你需要记住 trace 的参数和 OGNL 表达式，以后你可能只需要描述现象。

三、一张图看懂 Arthas 4 的核心能力

mermaid-20261101-085612.png 这张图展示的是 Arthas 4 的能力全景。

从 attach 到 JVM，到全局视图、方法级诊断、类操作、性能分析，再到 MCP 的 AI 集成，每一层都有对应的命令支撑。

四、代码实战：几个最常用的场景

4.1 场景一：找出最忙的线程

# 看 CPU 占用最高的 5 个线程
thread -n 5

输出会告诉你线程名、CPU 占用、以及当前的栈信息。如果发现某个线程一直在跑某个方法，就用 trace 去追。

4.2 场景二：追踪方法调用链路耗时

# 追踪方法调用，只看耗时大于 100ms 的
trace com.example.OrderService createOrder '#cost>100' -n 5

trace 默认只追踪一层内部调用，不是递归所有层级。想追多层用 --maxDepth，但不要开太深，性能开销会很大。

一个容易踩的坑：被 JIT 内联的方法可能追踪不到，这是正常现象，不是 Arthas 的问题。

4.3 场景三：观察入参和返回值

# 观察入参和返回值，展开 2 层
watch com.example.OrderService createOrder '{params, returnObj}' -x 2

注意：watch 默认会匹配子类和实现类，范围可能比你想的大。在高频方法上一定要加 -n 限制次数，或者加条件过滤，否则会打爆 CPU。

-x 也不要开太大，最多 3 层。展开大对象会触发大量反射，性能开销很大。

4.4 场景四：tt 时间隧道，事后排查

# 记录方法调用
tt -t com.example.OrderService createOrder

# 查看记录列表
tt -l

# 回放第 10 次调用
tt -i 10 -p

tt 是我个人最推荐的功能。watch 是实时的，错过了就没了；tt 把每次调用的完整上下文存下来，你可以慢慢看、反复回放、甚至修改入参重新执行。

但有一个坑必须记住：tt 默认最多存 100 条记录，存的是对象引用。如果对象后续被修改了，你看到的值可能不对。而且退出 Arthas 不会自动清理 tt 缓存，用完记得 tt --delete-all，否则会内存泄漏。

4.5 场景五：生成火焰图

# CPU 采样
profiler start
profiler stop --file /tmp/cpu-flame.svg

# 墙钟时间采样（看等待时间花在哪）
profiler start --wall
profiler stop --file /tmp/wall-flame.svg

生成的 SVG 文件用浏览器打开就能看。火焰图的宽度代表占用时间，越宽说明消耗越大。

五、AI 实战：用自然语言让 AI 替你排障

这是 Arthas 4 最值得单独拿出来讲的部分。

MCP Server 让 AI 可以调用 Arthas 的诊断工具，你只需要描述现象，AI 负责翻译成命令、执行、整理结果。

5.1 配置 MCP

在 arthas.properties 里打开 MCP 端点：

arthas.mcpEndpoint=/mcp
arthas.httpPort=8563
arthas.password=your-secure-password

验证服务是否通了：

curl http://localhost:8563/mcp

返回 MCP 协议握手信息就说明通了。

AI 客户端配置（以 Claude Desktop 或 Cline 为例）：

{
  "mcpServers": {
    "arthas-mcp": {
      "type": "streamableHttp",
      "url": "http://localhost:8563/mcp",
      "headers": {
        "Authorization": "Bearer your-secure-password"
      }
    }
  }
}

5.2 AI 怎么替你定位问题

场景一：CPU 飙高，定位热点线程

传统方式：你需要知道先敲 dashboard，再敲 thread -n 5，然后逐条分析输出，耗时 3-8 分钟。

AI 方式：你在对话框里说——

“帮我看看当前 CPU 最高的线程，以及它们在做什么。”

AI 会通过 MCP 调用 thread 工具，拿到结果后直接告诉你：“占用最高的是 pool-7-thread-3，它一直在执行 HashMap.get()，栈信息显示它卡在 OrderService.calculateDiscount 方法里，建议用 trace 追一下这个方法。”

整个交互在 30 秒内完成。

场景二：接口偶发超时，追踪方法耗时

你说——

“订单提交接口 P99 超时，帮我追踪 OrderService.submitOrder 方法内部每个步骤的耗时，重点看数据库调用和下游 RPC。”

AI 自动调用：

trace com.example.OrderService submitOrder -n 10

它从 trace 结果里发现 inventoryClient.deduct() 耗时 3.2 秒（正常应该 50ms），然后告诉你：“库存服务 RPC 超时，建议检查库存服务健康状态和超时配置。”

场景三：内存泄漏，生成堆快照

你说——

“老年代 GC 频繁，怀疑有对象泄漏，帮我生成堆快照并分析。”

AI 调用 heapdump 生成文件，然后展示各内存区域占用，并建议你结合 MAT 工具分析 hprof，重点关注 byte[] 和 HashMap 的 retained heap。

5.3 AI 排障的边界在哪里？

AI 能帮你做的事：把“现象”翻译成“命令序列”，把“原始输出”整理成“结论”，减少你翻手册、查语法的时间。

AI 不能替你做的事：判断这个结论是否真的符合业务逻辑。AI 说“库存服务 RPC 超时”，但库存服务为什么超时？是它自己挂了，还是网络问题，还是调用量突增？这个判断依然需要你来做。

还有一个安全建议：官方明确标注 MCP Server 是实验性模块，建议在生产环境以只读诊断为主，避免让 AI 触发 redefine 这类热替换操作。AI 可以帮你跑 trace、watch、thread，但别让它跑 redefine。

六、优缺点

优点

1. 不重启、不改代码
通过 attach 挂到运行中的 JVM，诊断过程对业务零侵入。这是 Arthas 最核心的价值。

2. JDK 8 到 25 全覆盖
Arthas 4 支持 JDK 8 及以上，包括 17、21、25。不需要为了诊断工具保留老版本 JDK。

3. 火焰图能力完整
async-profiler 4.4 + 墙钟时间采样，CPU 高和“CPU 不高但慢”两类问题都能覆盖。

4. tt 时间隧道
事后排查偶发问题的神器。记录调用快照，可回放、可修改入参重试。

5. MCP Server 拥抱 AI
29 个诊断工具可以通过自然语言调用。虽然还是实验模块，但方向很清晰。

6. 生态成熟
从 2018 年开源至今，阿里巴巴维护，社区活跃，文档完善。

缺点

1. 高频方法上要小心
watch、trace 这些命令本身有性能开销。在高频方法上不加限制地使用，可能把 CPU 打满。必须加 -n 或条件过滤。

2. tt 需要手动清理
退出 Arthas 不会自动清空 tt 缓存。忘了清理可能导致内存泄漏。

3. 热更新限制多
只能改方法体，不能新增/删除字段和方法。和 watch/trace 等命令冲突，执行前要先 reset。复杂逻辑不建议热更，只适合救急小 Bug。

4. MCP Server 还在实验阶段
29 个工具虽然覆盖了核心能力，但协议和客户端支持还在演进中。生产环境大规模使用还需要观察。

七、适用场景

场景推荐程度理由
线上偶发问题排查✅✅✅ 强烈推荐不改代码不重启，直接看现场
CPU 飙高定位✅✅✅ 强烈推荐thread -n + trace 快速定位热点
接口变慢但 CPU 不高✅✅✅ 强烈推荐profiler --wall 看等待时间花在哪
类冲突/NoSuchMethodError✅✅✅ 强烈推荐sc + jad + classloader 排查
小 Bug 热修复✅✅ 推荐只能改方法体，适合救急不适合常规发布
偶发异常事后排查✅✅✅ 强烈推荐tt 记录快照，事后回放
AI 辅助排障入门✅✅ 推荐MCP + AI 客户端，降低命令学习成本
生产环境第一次用热更新❌ 不推荐先在测试环境练熟，生产环境风险高

更多项目实战在Java突击队网：susan.net.cn/project

八、写在最后

回到最初的问题：为什么越来越多人用 Arthas 4？

因为它让“线上诊断”这件事，从“猜”变成了“看”，现在又从“看”变成了“问”。

你不用再靠日志猜线程在干什么，不用再靠监控猜方法耗时花在哪，不用再为了排查一个偶发问题去加日志、发版、等复现。挂上 Arthas，敲几条命令，现场就在你眼前。

Arthas 4 的升级，方向也很清晰：跟上 JDK 的演进、补全火焰图能力、拥抱 AI 工作流。

JDK 25 支持意味着新项目也能用，墙钟火焰图意味着“CPU 不高但慢”的问题也有解法，MCP Server 意味着未来你可能只需要描述现象，AI 帮你跑命令。

参考资源

avatar
文章
阅读
粉丝