企业官网建设流程全解析

前言

接口突然变慢的时候，日志里常常只剩一行超时。CPU 打满的时候，jstack打出来的栈又长又密。进程还在对外提供服务，这时候最需要的，是就地看一眼现场。阿里开源的 Arthas，就是为这种时刻准备的。它贴到正在运行的 Java 进程上，用一组命令把线程、方法、类和内存摊开来。到了 4 这个大版本，它跟上了新的 JDK，火焰图更好用了，也开始能把诊断能力交给 AI 助手。今天来聊聊 Arthas 4 这个版本，还是很强大的 。

Arthas 是干什么的

Arthas 是阿里巴巴开源的 Java 诊断工具，代码在 alibaba/arthas。它能跑在 Linux、macOS 和 Windows 上，平时用命令行跟你对话，Tab 键可以补全命令和类名。

你可以把它想成一根随时插上的听诊器。业务代码保持原样，JVM 参数也不必提前埋点。进程还在跑，用arthas-boot.jar选中它，就能开始问：现在哪根线程最忙？这个方法被谁调用、花了多少时间？线上真正加载的类，反编译出来长什么样？

值班时最常碰到的几条命令，大概是这些：

装上也很轻。把启动包拉下来，选中进程即可：

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

回车后会列出本机的 Java 进程，输入编号就连上了。Windows 上同样走这条java -jar。

线上排障，大致走哪几步

第一次打开命令列表，很容易不知道从哪条下手。顺序其实很固定：先看全貌，再钻到方法和调用栈，最后用采样把热点钉死。

后面的三个例子，就是按这张图往下走的。

Arthas 4 新在哪里

4.x 把两件事做实了：在更新的 JDK 上稳住，以及把诊断结果交给更多人看。下面几条，是我会特意记在小本子上的。

JDK 从 8 覆盖到 25。Arthas 4 要求 JDK 8 及以上。官方说明里写了 JDK 17、21、25 都在支持范围内。团队运行时已经切到 JDK 21，甚至更新的版本，就用 4.x 这一档。依赖也收过一轮，Jackson、Fastjson2、OGNL、Netty 都升过，诊断工具自己少踩安全方面的坑。

火焰图这条链路更完整。profiler内置的 async-profiler，在 4.2.0 里升到了 4.4。CPU 采样之外，4.0.2 起可以用--wall看墙钟时间。锁等待、网络卡住这类「CPU 看起来不高、接口却很慢」的问题，会更容易露出来。会话默认超时也从 30 分钟放宽到 3 小时，采样进行到一半，命令行不容易被踢掉。

Metaspace 可以按类加载器拆开。新命令classloader-metaspace借助 JFR 的jdk.ClassLoaderStatistics，按每个 ClassLoader 统计已加载类的数量，以及 metaspace 的 chunk、block 大小。它看的是类元数据占用，适合动态代理、脚本引擎、反复生成类，把 Metaspace 慢慢顶满的场景。当前 JDK 没有 JFR 时，这条命令不会出现。

诊断可以交给 AI 助手。Arthas MCP Server 目前还是实验模块。配好arthas.mcpEndpoint之后，HTTP 默认在8563端口提供 MCP 接口。文档里列出了 29 个诊断工具，dashboard、thread、trace、jad、profiler这些老面孔都在。Cherry Studio、Cline 这类客户端连上以后，可以用自然语言让助手去跑命令。设置了arthas.password时，访问要带 Bearer Token。

顺带一提，4.1 之后补上了龙芯loongarch64，也支持从启动包加载外部命令。日常排障用不到的话，知道有这条路就够了。

三个可以直接上手的例子

下面假设已经连上目标进程，业务里有一个demo.UserService.login。类名换成你自己的即可。

例子一：先看谁在忙

CPU 告警上来，先看一眼面板，再抓最忙的 3 根线程。

dashboard -n 1

dashboard -n 1刷新一次就退出，适合留个快照。thread -n 3会把 CPU 占用最高的线程和栈打出来。栈顶如果反复停在某个业务方法上，下一步就去追这个方法。

例子二：这个登录方法，时间花在哪

调用慢、日志又看不清分支时，用trace看内部耗时，用watch看真实入参。

trace demo.UserService login

trace会把方法内部的调用节点和耗时铺开。慢在参数校验，还是慢在一次远程调用，分开看就清楚了。watch里的-x 2把对象展开两层，-n 5只抓 5 次，避免刷屏。调用量很大时，可以只看耗时超过 100 毫秒的那几次：

trace demo.UserService login '#cost > 100'

例子三：火焰图，以及 Metaspace

热点散在很多小方法里时，拉一段采样，再把火焰图落成 html。

profiler start --event cpu

停下来的时候，终端会打印文件路径，一般在arthas-output目录下。浏览器打开后，横条越宽，说明待得越久。

CPU 不高、线程却大量堵在锁或网络上，换成墙钟采样：

profiler start --wall

Metaspace 一直往上涨时，用这条按类加载器看占用：

classloader-metaspace --duration 2500ms --limit 10

结果按 chunk 从大到小排。某个业务 ClassLoader 的classes和chunkSize特别高，就顺着它查是不是有动态类在不停生成。

如果希望助手来跑这些命令，在arthas.properties里打开 MCP：

# 打开 MCP，默认端口 8563

客户端可以这样接：

{

这个能力还在实验阶段，先在测试环境把命令跑熟，再接到助手上，心里更有底。

开源地址：https://github.com/alibaba/arthas

为什么越来越多人用Arthas4

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

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 到底强在哪、怎么用、适合什么场景，从头到尾给你拆解一遍。

一、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 的核心能力

这张图展示的是 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 startprofiler stop --file /tmp/cpu-flame.svg# 墙钟时间采样（看等待时间花在哪）profiler start --wallprofiler stop --file /tmp/wall-flame.svg

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

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

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

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

5.1 配置 MCP

在arthas.properties里打开 MCP 端点：

arthas.mcpEndpoint=/mcparthas.httpPort=8563arthas.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 个工具虽然覆盖了核心能力，但协议和客户端支持还在演进中。生产环境大规模使用还需要观察。

七、适用场景

八、写在最后

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

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

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

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

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

参考资源

• GitHub：https://github.com/alibaba/arthas

• 官方文档：https://arthas.aliyun.com

本文的引用仅限自我学习如有侵权，请联系作者删除。
参考知识
阿里开源的Java诊断工具 - Arthas 4 到底有多强大 ？
为什么越来越多人用Arthas4？