一、引言线上排查的困境与 Arthas 的诞生对于每一位负责线上系统的 Java 工程师来说最让人崩溃的时刻往往不是写代码而是面对生产环境突然出现的诡异问题服务突然变慢、CPU 持续飙高、内存缓慢泄漏、某个接口偶发报错、死锁导致整个请求链路卡死。更让人绝望的是这些问题中的绝大多数只在生产环境出现本地环境无论怎么压测、怎么造数据都无法复现而一旦重启服务珍贵的故障现场就会随之消失留给排查者的只剩下一堆不完整的日志和一条条含糊不清的监控曲线。在 Arthas 出现之前Java 开发者面对线上问题的手段其实非常有限而且每一种手段都有明显的短板加日志必须重启想要知道某个方法的入参、某个分支的执行情况最常见的做法就是修改代码、补充日志、重新构建、发布、重启。这套流程在敏捷开发模式下少则几分钟多则几十分钟甚至更久而且发布动作本身存在风险更关键的是重启往往会破坏问题现场让排查工作前功尽弃。本地无法复现生产环境和本地开发环境在数据量、并发量、网络拓扑、中间件版本、JVM 参数等维度都有巨大差异很多性能问题只有在特定流量、特定数据、特定运行时长下才会暴露本地复现几乎不可能。监控粒度不足常规的监控平台和 APM 工具虽然能告诉我们 CPU 高了、内存涨了、接口慢了但它们大多只能提供宏观指标很难精确定位到“到底是哪一行代码、哪一个方法调用、哪一次请求触发了问题”。线上调试基本无解生产环境当然不可能像本地那样开启 Debug 端口挂上 IDE 单步调试远程调试不仅配置繁琐而且存在严重的安全隐患和性能影响几乎没有团队敢在生产环境长期开放调试端口。正是在这样的背景下阿里巴巴开源了 Arthas。Arthas 是一款面向 Java 应用的在线诊断工具它能够在不停机、不重启、不修改代码的前提下实时查看 JVM 的运行状态、方法的调用链路与参数返回值、类的加载信息、线程的堆栈与锁竞争情况等关键数据帮助开发者以最快的速度定位线上问题。Arthas 项目自开源以来迅速受到开发者的追捧在 GitHub 上获得了数万颗星标并被大量企业的生产环境所采用逐渐成为 Java 开发者必备的排障利器。用一句流传甚广的话来概括Arthas 解决的正是“线上出了 Bug不用重启、不用加一行日志就能把问题看清楚”这一核心痛点。本文将从零开始系统深入地介绍 Arthas 的安装部署、命令体系、核心玩法、实战案例以及进阶技巧力求用接近两万字的篇幅带你真正掌握这一款 Java 在线诊断神器。二、认识 Arthas它到底是什么Arthas 是 Alibaba 开源的一款 Java 诊断工具项目托管在 GitHub 上目前已经捐赠给开源社区并持续活跃维护。Arthas 一词取自古希腊神话中的“丰收女神”寓意帮助开发者“收获”解决问题的答案。官方对它的定位非常直接Arthas 是 Alibaba 开源的 Java 诊断工具深受开发者喜爱。从技术本质上看Arthas 的强大能力主要建立在大底层技术之上Java Agent 与 Attach 机制Arthas 以 Java Agent 的形式通过 JDK 提供的 Attach API 动态附加到目标 JVM 进程上。整个过程无需修改目标应用的启动参数也无需重启应用就可以在运行时把诊断探针注入到正在运行的 JVM 中。字节码增强技术Arthas 底层基于字节码操作框架主要是 ASM对目标类进行运行时增强。在不修改源代码的前提下它可以在方法入口、方法出口、异常抛出点、方法调用点等位置织入监控逻辑从而实现 watch、trace、stack、tt 等强大的诊断能力。需要特别澄清的是Arthas 与传统的性能监控工具存在本质区别。它不是一个持续运行的 APM 平台而是一个“按需启动、按需关闭”的命令行诊断工具。你可以把它想象成给线上 JVM 安装的一盏“手术无影灯”和一套“微创内窥镜”哪里有问题就照哪里排查结束后即可撤离对系统的侵入性和性能开销都在可控范围内。当然Arthas 对性能并不是零开销特别是在进行方法级监控时高频调用和大方法体都会放大开销因此官方建议只在排查问题时临时使用问题定位后及时关闭。2.1 Arthas 能解决哪些问题Arthas 官方文档中列举了大量典型场景几乎覆盖了 Java 线上排障的方方面面这个类是从哪个 jar 包加载的为什么会报各种 Class 相关的异常为什么我改的代码没有执行到难道是我没提交还是分支搞错了线上遇到问题无法 debug能不能通过 Arthas 在线 debug线上某个接口数据处理比较慢到底是哪一步慢线上系统 CPU 飙高是哪个线程、哪段代码导致的运行的多线程有没有死锁线程池当前状态如何我动态修改了代码能不能在不重启的情况下让它生效某个方法的调用参数和返回值到底是什么异常是从哪里抛出来的这些问题绝大多数都可以在 Arthas 的交互式命令行中借助对应的命令快速找到答案。2.2 Arthas 与同类工具的关系在 Java 诊断领域除了 Arthas还有一些工具经常被拿来对比JDK 自带的 jstack、jmap、jstat、jinfo、jcmd以及 Btrace、Greys、VisualVM、MAT 等。Arthas 早期正是从 Greys 项目脱胎而来经过阿里巴巴内部大量生产实践的打磨后逐步演化成今天的样子。相比 JDK 自带的命令行工具Arthas 的优势在于交互体验更好、信息呈现更聚焦、覆盖场景更全面同时把原本分散的多个工具能力整合到了一个统一的交互式 Shell 中避免了记忆大量参数和反复切换工具的麻烦。三、Arthas 的核心特性理解 Arthas 的价值首先要从它的核心特性入手。正是下面这些特性使 Arthas 在一众诊断工具中脱颖而出。3.1 无侵入、免重启Arthas 采用 Attach 方式附加到运行中的 JVM整个过程不需要修改目标应用的启动脚本也不需要重启服务。诊断逻辑通过字节码增强临时注入当你执行 stop 命令退出 Arthas 时可以选择关闭增强让应用恢复到原始状态。这一点对于“问题只能在线复现”的场景至关重要你可以在问题发生的瞬间把 Arthas 挂上去而不必担心重启破坏现场排查结束后又可以把增强逻辑全部清理干净。3.2 丰富的诊断命令Arthas 提供了数十个开箱即用的命令覆盖了线程、类加载、方法调用、反编译、内存、GC、系统属性、日志、容器等各个维度。无论是刚刚入门的新手还是经验丰富的资深工程师都可以通过简单的命令组合完成复杂的问题定位工作学习成本低记忆负担小。3.3 强大的在线调试能力通过 watch、trace、stack、monitor、tt 等命令Arthas 可以在方法级别观察方法的入参、返回值、抛出异常、调用耗时、调用栈等细节。这相当于在指定方法上临时安装了“探针”而且支持使用条件表达式和观察表达式进行精准过滤避免输出被海量调用淹没真正做到“在千万次调用中只看你想看的那一次”。3.4 动态热更新通过 jad 反编译、mc 内存编译、redefine 重载的组合Arthas 支持在线修改类定义并立即生效。这意味着你可以在不发版的情况下完成一些紧急修复或者验证实验。配合 retransform 命令还能实现更精细的字节码替换这一能力在很多应急场景下价值巨大。3.5 离线、纯命令行、低依赖Arthas 是一个纯命令行工具新版也提供了 Web Console 界面。它的核心打包产物是一个可执行 jar 文件几乎零外部依赖下载即可使用。对于无法开放额外端口、无法安装图形化工具的生产服务器来说这种轻量化的设计非常友好部署成本几乎可以忽略不计。四、安装与快速上手Arthas 的安装和使用门槛极低从下载到成功附加到目标进程并进入命令行交互界面通常只需要一两分钟。4.1 环境准备在使用 Arthas 之前需要确认以下环境条件JDK 版本要求Arthas 支持 JDK 6 及以上版本推荐使用 JDK 8 及以上。这里需要注意的是目标服务器上必须安装完整 JDK 而不能只有 JRE因为 Arthas 的部分功能依赖编译能力以及相关工具类库。权限要求运行 Arthas 的操作系统用户必须与目标 Java 进程的启动用户一致否则会因为权限不足而无法完成 Attach。这在很多以 root 启动应用的场景中容易被忽略。网络要求首次通过 arthas-boot.jar 启动时默认会自动从远程仓库下载最新版本的 Arthas 核心包因此服务器需要能访问外网。如果服务器处于内网隔离环境可以提前下载完整包并离线部署。4.2 下载安装最快捷的方式是使用官方提供的引导脚本。在 Linux 或 Mac 环境下执行下面的命令即可下载启动引导 jarbashcurl -O https://arthas.aliyun.com/arthas-boot.jar java -jar arthas-boot.jar在 Windows 环境下可以直接从官网或 Maven 仓库下载 arthas-boot.jar然后执行同样的 java -jar 命令也可以下载完整发行包 arthas-packaging解压后运行 bin 目录下的 as.bat 脚本。默认情况下arthas-boot.jar 会自动下载最新版本的 Arthas 核心包也支持通过参数指定版本例如使用 --target-version 参数来指定某个历史版本。4.3 选择目标进程执行 java -jar arthas-boot.jar 之后Arthas 会列出当前用户下所有正在运行的 Java 进程并提示你输入目标进程对应的编号text[INFO] arthas-boot version: 3.7.1 [INFO] Found existing java process, please choose one and input the serial number of the process, eg : 1. Then hit ENTER. * [1]: 12345 com.example.OrderServiceApplication [2]: 23456 com.example.UserServiceApplication输入目标进程对应的编号并回车Arthas 就会附加到该进程上随后进入交互式命令行界面此时就可以开始执行各种诊断命令了。4.4 退出 ArthasArthas 提供了两种不同语义的退出方式很多初学者容易混淆quit 或 exit只退出 Arthas 客户端目标 JVM 中的 Agent 默认继续运行。这意味着你之后还可以再次连接回来之前设置的各种增强和监控仍然有效。stop彻底关闭 Arthas 服务端退出时可以选择是否还原已经增强过的类。这是真正意义上的“拔掉探针”会让增强逻辑清理干净。日常使用中如果只是临时排查建议在排查结束后执行 stop让增强逻辑彻底清理干净避免长期驻留带来额外开销和潜在风险。而如果你担心后续还需要继续排查可以先 quit 保持现场待问题彻底解决后再回来执行 stop。4.5 全局命令与帮助进入 Arthas 交互界面后输入 help 可以查看所有可用命令及简要说明输入 help 加命令名可以查看某个命令的详细用法和全部参数。例如 help watch 就会展示 watch 命令的所有参数、示例和注意事项。Arthas 的命令设计遵循“先概览、再精查”的思路即使偶尔忘记某个参数也完全可以现场查阅帮助文档记忆负担很小。五、基础入门仪表盘与 JVM 宏观视图掌握 Arthas通常从两个宏观命令开始dashboard 和 JVM 相关命令。它们能帮助你快速建立对目标应用整体运行状态的认知是后续所有精细化排查工作的基础。5.1 dashboard实时数据面板dashboard 是 Arthas 的第一个“仪表盘”它集中展示线程、内存、GC、运行环境等核心指标并以固定频率自动刷新是快速感知系统整体健康状况的首选命令。执行方式非常简单bashdashboard输出内容主要分为以下几个区域线程区列出当前活跃线程包括线程 ID、线程名称、所属线程组、优先级、状态、CPU 占用率和累计执行时间。通过这一区域可以快速发现当前占用 CPU 最高的线程它是 CPU 飙高问题排查的第一现场。内存区展示 heap、nonheap、各内存池的使用量和最大值以及 GC 各分代的统计信息。通过观察各分区的增长趋势可以初步判断是否存在内存泄漏或 GC 异常。运行时区显示操作系统、JDK 版本、虚拟机参数等基本信息方便确认运行环境与预期是否一致。dashboard 还支持参数定制例如 -n 指定刷新次数、-i 指定刷新间隔毫秒bashdashboard -n 5 -i 2000这条命令会每 2 秒刷新一次一共刷新 5 次后自动退出非常适合脚本化采集或者生成快照报告。5.2 JVM 相关命令除了 dashboard 之外Arthas 还提供了一组从 JVM 视角观察运行状态的命令它们与 JDK 自带工具的含义大体对应但输出更友好jvm查看当前 JVM 的详细信息包括 JVM 版本、启动参数、类加载统计、编译统计、GC 统计、内存管理器等相当于把 jinfo 和部分 jstat 的能力集中展示。memory查看 JVM 内存信息相当于对 MemoryMXBean 的直观解读可以看到堆和非堆的各个内存池使用情况便于判断内存分配是否合理。thread查看线程信息这是 Arthas 中使用频率最高的命令之一后面会用专门章节详细展开。sysprop查看和修改 JVM 的系统属性相当于 System.getProperties 的实时操作入口。sysenv查看 JVM 的环境变量便于确认运行环境中的环境变量与预期是否一致。vmoption查看和更新 JVM 中诊断相关的 VM 参数可以动态调整部分可写的 JVM 选项。一个非常典型的排查链路是先用 dashboard 观察宏观趋势发现 CPU 异常后再用 thread 定位到具体线程最后用 watch 或 trace 等命令下沉到方法级别。这种“由面到点”的排查路径是 Arthas 高效定位问题的关键所在也是每一位使用者都应该熟练掌握的基本功。六、线程诊断thread 命令详解CPU 飙高、线程死锁、线程池耗尽是线上最常见的几类问题而 thread 命令正是排查这些问题的主力工具。thread 的默认行为是打印当前所有线程信息可以看作是 JDK 自带 jstack 的升级版但输出更简洁、更聚焦并且支持丰富的过滤和定位参数。6.1 查看所有线程直接执行 thread 命令即可查看当前所有线程的概要信息bashthread输出中可以看到每个线程的 ID、名称、状态、优先级、CPU 时间等关键字段。如果线程数量非常多可以通过管道配合 grep 进行过滤Arthas 的命令行支持管道和重定向例如筛选出名称中包含 order 的线程bashthread | grep -i order在 Arthas 中管道符的使用与 Linux Shell 一致只是 Arthas 内置的管道命令是 grep具体支持的管道命令可以通过 help 查看。6.2 查看最繁忙的线程排查 CPU 飙高问题时最常用的参数是 -n它按 CPU 使用率倒序列出最繁忙的前 N 个线程及其堆栈bashthread -n 3执行 thread -n 3 后Arthas 会按 CPU 使用率倒序列出当前最繁忙的 3 个线程并给出每个线程的完整运行堆栈。输出中会展示线程名称、线程 ID、CPU 占用比例以及触发高 CPU 的关键方法调用栈例如texthttp-nio-8080-exec-7 Id78 cpuUsage96.2% RUNNABLE at com.example.demo.service.OrderService.calcTotal(OrderService.java:42) at com.example.demo.service.OrderService.listOrder(OrderService.java:21) at com.example.demo.controller.OrderController.list(OrderController.java:35) at java.lang.reflect.Method.invoke(Native Method) at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)需要特别说明的是thread -n 给出的是某一时刻的静态快照而 dashboard 中的线程区是动态刷新的。实际排查时通常先在 dashboard 里观察哪一个线程持续占用 CPU 最高再用 thread -n 获取该线程的详细堆栈从而把 CPU 飙高问题一步步收敛到具体的方法和代码行。6.3 查看指定线程的详细堆栈如果已经通过 dashboard 或线程列表拿到了目标线程 ID可以直接把线程 ID 作为参数传给 thread 命令查看该线程当次运行时的详细堆栈信息bashthread 78这条命令会打印指定线程的完整调用栈并且会在堆栈中高亮标注线程当前正在执行的业务代码。对于“线程卡在某处不动”“某个请求一直没有返回”这类问题直接查看对应工作线程的堆栈往往能一眼看到阻塞点。6.4 死锁检测thread -b死锁是并发编程中最隐蔽的问题之一。多个线程互相持有对方需要的锁并彼此等待时系统不会立刻崩溃但相关请求会长时间卡死线程池也会逐渐耗尽。Arthas 提供了专门的死锁检测参数 -b它会扫描当前 JVM 中所有线程的锁等待关系并输出死锁链路bashthread -b如果系统中不存在死锁命令会提示没有发现死锁如果命中死锁环路输出中会清晰列出哪些线程持有哪些锁、又在等待哪些锁并能定位到具体类名和方法行号排查效率远高于手动分析 jstack 文本。6.5 按状态过滤线程当线程数量很多时可以使用 --state 参数过滤出指定状态的线程支持的状态包括 RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、NEW、TERMINATED 等。例如查看所有处于 WAITING 状态的线程bashthread --state WAITING还可以用 --all 参数显示所有线程的完整堆栈适合在需要完整线程现场时使用。例如一次性查看前 5 个最繁忙线程的完整堆栈bashthread -n 5 --all此外thread 还可以设置刷新间隔例如每秒输出一次最繁忙的前 3 个线程持续观察 CPU 热点变化。由于输出量较大生产环境使用前建议先结合业务调用频率和命令行窗口滚动能力做好评估。七、方法调用诊断watch、trace、stack 三剑客如果说 thread 命令解决的是“哪个线程出了问题”那么 watch、trace、stack 这一组命令解决的则是“方法内部到底发生了什么”。它们都以类的完整限定名加方法名作为基本定位方式通过在运行时增强目标方法实时观察方法的入参、返回值、异常和调用栈。这是 Arthas 最核心、也是日常使用频率最高的能力。7.1 watch观察方法入参、返回值和异常watch 命令可以在不重启应用、不修改代码的前提下实时观察目标方法每次调用时的入参、返回值和抛出异常。其基本语法为bashwatch 类全限定名 方法名 观察表达式 -x 展开深度 -n 执行次数观察表达式通常使用 OGNL 表达式Arthas 提供了 params、returnObj、throwExp 三个核心变量分别表示方法参数数组、返回值和异常对象。例如查看 OrderService.calcTotal 方法的入参和返回值bashwatch com.example.demo.service.OrderService calcTotal {params,returnObj} -x 2 -n 5这条命令会在 calcTotal 每次被调用时打印参数数组和返回值-x 2 表示对象展开深度为 2-n 5 表示匹配 5 次后自动结束观察避免命令一直占用终端。如果还想观察异常可以写成bashwatch com.example.demo.service.OrderService calcTotal {params,returnObj,throwExp} -x 2 -n 10当方法抛异常时throwExp 会携带异常对象如果方法正常返回throwExp 则为 null。通过这种方式线上某个接口偶发报错时可以直接挂上 watch 看异常到底从哪个方法抛出、携带了什么消息。7.2 watch 条件表达式只看你关心的那一次调用线上热门方法的调用频率往往非常高如果不加任何过滤就挂 watch输出会被海量调用瞬间冲刷既看不清也影响性能。watch 支持在观察表达式之后追加条件表达式只有当条件为 true 时才会输出。典型用法如bashwatch com.example.demo.service.OrderService calcTotal {params,returnObj} params[0]!null params[0].length10 -x 2 -n 3上述命令表示只有第一个参数不为空且长度大于 10 时才打印这次调用的入参和返回值。条件表达式让排查思路可以直接映射成命令例如“只观察 userId 为 10001 的请求”“只观察金额大于 1000 的订单”等真正实现精准采样。7.3 trace追踪调用链路与耗时当某个接口整体比较慢但不确定具体慢在哪个环节时trace 命令非常有效。它会追踪目标方法内部的完整调用链路并统计每一个子调用的执行耗时bashtrace com.example.demo.service.OrderService listOrder -n 5 --skipJDKMethod false输出会以树形结构展示 listOrder 内部依次调用了哪些方法每个节点上的耗时是多少、占总耗时比例是多少例如先调用查询订单、再调用查询用户、最后调用计算金额其中查询用户耗时占比 80%那么问题就大概率集中在用户查询这一段。掌握这条命令后接口性能优化就从“到处猜测”变成“顺着耗时链路逐层下钻”。trace 默认会跳过 JDK 方法以降低噪音确认问题不在 JDK 内部后可以通过 --skipJDKMethod false 打开完整视图。高频调用方法同样建议配合 -n 限制次数必要时再配合条件表达式缩小范围。7.4 stack查看方法被谁调用有时候你发现某个重要方法被调用得过于频繁或者参数被传错了却不知道调用方到底是谁。stack 命令可以输出目标方法被触发时的完整调用堆栈bashstack com.example.demo.service.OrderService calcTotal -n 3stack 会一路向上溯源从触发入口一直展示到目标方法。对于“这个方法为什么会在不该出现的地方被调用”“究竟有哪几条上游链路都会走到这里”等问题stack 能直接给出清晰的调用关系。八、tt 时空隧道记录和回放方法调用现场watch、trace、stack 等命令有一个共同特点只能“守株待兔”式地观察实时发生的调用。如果问题已经发生或者调用频率很低就需要提前把调用现场记录下来再离线分析。Arthas 的 tt 命令正是为此设计它像一个“时空隧道”能够记录目标方法的每次调用入参、返回值、耗时和异常并支持事后查看和重放。8.1 记录调用现场使用 tt -t 可以开始记录目标方法的调用事件bashtt -t com.example.demo.service.OrderService calcTotal命令进入记录模式后每次调用都会产生一条带唯一 INDEX 编号的记录。记录内容包括方法入参、返回值、调用耗时、调用线程、异常信息等。使用一段时间后按 CtrlC 或执行 tt -l 查看已记录的事件bashtt -l每条记录对应一次真实调用相当于给偶发问题自动留档。相比贴大量临时日志这种方式更集中事后分析也更方便。8.2 查看和重放具体记录通过 tt -l 拿到 INDEX 后可以用 tt -i 查看某条记录的详细内容bashtt -i 1000 --verbose更强大的是 tt -p它可以基于历史记录“重新播放”这次方法调用bashtt -i 1000 -p重放会使用当时记录的入参再次触发方法执行适合在修复后验证同样的入参是否还会复现问题。这一能力在复现难度高的线上故障场景中尤其有价值先记录事故现场的调用再在调试阶段反复重放直到定位根因。8.3 tt 的注意事项tt 记录期间会保留每次调用的入参和返回值对象如果入参对象较大或调用频率很高可能会造成内存占用上升。因此建议只针对重点方法短时间记录并在分析完成后通过 stop 清理增强。对于生产环境最好先在低峰期进行小范围验证再应用于关键链路。九、类与类加载诊断类加载相关问题是 Java 线上故障的另一大来源例如 NoClassDefFoundError、ClassNotFoundException、NoSuchMethodError、类被重复加载等。Arthas 提供了 sc、sm、classloader、getstatic 等一系列命令可以在运行时查看类的来源、方法签名、类加载器和静态字段。9.1 sc查看已加载类sc 命令用于查看 JVM 中已加载的类信息。最基本的形式是bashsc com.example.demo.service.OrderService输出会显示类名、类加载器和类的来源路径。加上 -d 可以显示更进一步的信息包括类的修饰符、注解、实现的接口、所在的类加载器哈希值等bashsc -d com.example.demo.service.OrderServicesc 还支持通配符例如查看某个包下所有已加载的服务类bashsc *OrderService当遇到“明明依赖了某个 jar但运行时类找不到”或者“同名类加载了多份”的问题时先用 sc 确认类源路径和类加载器往往能快速定位是版本冲突还是打包遗漏。9.2 sm查看方法签名sm 命令用于查看类中已加载的方法信息包括方法名、参数类型和返回类型。基本用法bashsm com.example.demo.service.OrderService加上方法名可以只看某个具体方法的签名bashsm com.example.demo.service.OrderService calcTotal再配合 -d 参数可以查看方法的附加信息bashsm -d com.example.demo.service.OrderService calcTotal当出现 NoSuchMethodError 时通过 sm 查看运行期实际方法的签名再和编译期对比就能快速确认是不是参数类型不匹配、泛型擦除或方法签名变化导致的版本不兼容。9.3 classloader查看类加载器classloader 命令用于查看 JVM 中所有类加载器的层次关系以及它们各自加载的类数量bashclassloader使用 -t 可以以树形结构展示类加载器的父子关系bashclassloader -t当需要进一步明确某个类是哪个类加载器加载时可以先通过 sc -d 拿到类加载器哈希值再通过 classloader -c 查看具体信息。类加载器隔离问题是微服务和中间件场景下的高频故障掌握了 classloader 和 sc 的组合用法排查效率会明显提升。9.4 getstatic查看静态字段getstatic 命令可以实时查看类的静态字段当前值非常适合确认配置、开关、缓存等静态状态是否符合预期bashgetstatic com.example.demo.config.AppConfig VALUE当怀疑某个配置没有生效、某个静态开关状态与预期不一致时直接执行 getstatic 就能拿到当前类的静态字段值省去了分析日志和猜想的环节。十、反编译与在线热更新Arthas 不仅能“看”还能在严格的应急场景中“改”。通过 jad、mc、redefine、retransform 的组合可以在不重新发版的情况下反编译、修改、重编译并热替换类定义完成紧急修复或验证实验。10.1 jad反编译源码jad 命令用于反编译已加载类的字节码从而查看 JVM 中真正在执行的源码。最常见的情况是“我改的代码没有生效怀疑线上运行的还是旧版本”此时直接反编译运行态类即可确认bashjad com.example.demo.service.OrderService使用 --source-only 可以只输出反编译后的源码不附带类元信息便于快速浏览bashjad --source-only com.example.demo.service.OrderService反编译结果可能与原始源码存在少量差异但对于回滚确认、判断依赖版本、检查运行逻辑而言已经足够实用。10.2 mc内存编译mc 命令可以把内存中的源代码编译成 class 文件。典型用法是先把 jad 反编译得到的源码保存到临时文件修改后再通过 mc 编译bashmc /tmp/OrderService.java -d /tmp-d 指定 class 文件的输出目录。由于 mc 使用的是运行期编译器目标机器需要具备完整 JDK这也再次呼应了前面安装环境准备中的要求。10.3 redefine热替换类编译得到新的 class 文件后可以使用 redefine 命令将其重载进 JVM立即替换旧的类定义bashredefine /tmp/com/example/demo/service/OrderService.classredefine 适用于大部分方法体级别的修改。但需要强调它不能增加或删除字段、不能改变方法签名、不能修改继承关系这些都属于 JVM 类重定义机制本身的限制。因此热更新更适合应急修复简单逻辑或临时打开日志开关而不能完全替代正常发版。10.4 retransform精细字节码替换retransform 是更底层的类转换入口配合自定义脚本可以在类加载后才能观察到的时机触发增强适合一些需要精细控制字节码的高级场景。普通日常使用时redefine 已经可以覆盖大多数应急热修复诉求retransform 可以作为进阶能力按需掌握。10.5 热更新的风险提醒在线热更新是一把双刃剑。虽然它能省去发版流程快速止损但如果替换的类在多个节点执行不一致、替换代码存在缺陷或者内部状态不兼容也可能引入新的问题。生产环境使用前务必在测试环境充分验证并同步保留原 class 文件备份一旦出现异常立即回滚并重启相关节点进行标准化修复。十一、OGNL 与其他实用命令11.1 ognl执行表达式ognl 命令允许在目标 JVM 中执行 OGNL 表达式可以用来读取甚至修改对象的属性是 watch、tt 等命令观察表达式的底层基础。例如查看某个静态字段的值bashognl com.example.demo.config.AppConfigVALUE再比如调用某个对象的 getter 方法获取运行时状态bashognl com.example.demo.cache.CacheManagergetInstance().size()ognl 的表达式能力非常强适合在排查时需要临时读取一些无法通过常规命令直接获取的值。但也正因为其能力强大生产环境使用时要格外谨慎尤其是涉及修改对象状态的表达式。11.2 monitor周期性监控方法调用monitor 命令用于周期性地监控目标方法的调用次数、成功次数、失败次数、平均耗时和失败率。它不像 watch 那样逐次输出而是按固定周期统计汇总适合观察一段时间内的整体趋势bashmonitor -c 5 com.example.demo.service.OrderService calcTotal上述命令表示每 5 秒统计一次 calcTotal 的调用情况。对于判断某个方法是否被高频调用、成功率是否异常、耗时是否上升等场景非常实用而且相比 watch 输出量小得多对系统的干扰也更低。11.3 profiler生成火焰图profiler 命令可以启动或停止采样并生成火焰图用于直观展示 CPU 时间在各方法上的分布。这是排查复杂性能问题时非常有价值的工具bashprofiler start profiler stop --format html停止采样后会生成一个 HTML 格式的火焰图文件用浏览器打开即可查看。火焰图的横向宽度代表 CPU 占用时间占比纵向代表调用栈深度能快速定位到热点方法。11.4 logger查看和修改日志级别logger 命令可以在不重启应用的情况下查看和动态调整日志级别这在排查线上问题时非常实用bash# 查看所有 logger logger # 查看指定 logger logger -n com.example.demo # 将指定 logger 调整为 debug 级别 logger -n com.example.demo -l debug通过动态调整日志级别可以在不重新发布的情况下获取更多排查信息问题定位后再调回原级别。这比直接修改配置文件重启应用要高效得多。十二、实战案例12.1 案例一CPU 飙高定位现象线上某服务 CPU 持续维持在 90% 以上接口响应变慢。排查步骤使用dashboard观察线程区发现某个线程 CPU 占用异常高。使用thread -n 3查看最繁忙线程的堆栈定位到具体业务方法。使用trace追踪该方法的内部调用发现某个循环内存在重复计算。结合代码审查确认问题修复后通过压测验证。关键命令bashdashboard thread -n 3 trace com.example.demo.service.OrderService calcTotal -n 512.2 案例二接口偶发超时现象某接口在高峰期偶发超时日志中没有明显异常。排查步骤使用tt -t记录该接口方法的所有调用等待问题复现。通过tt -l找到耗时异常的记录。使用tt -i查看该次调用的详细入参和返回值发现某个参数值异常。使用watch配合条件表达式只观察该参数值的调用确认问题规律。定位到上游传参逻辑修复后验证。关键命令bashtt -t com.example.demo.service.OrderService queryOrder tt -l tt -i 1000 --verbose watch com.example.demo.service.OrderService queryOrder {params,returnObj} params[0]!null -x 2 -n 512.3 案例三内存缓慢泄漏现象服务运行几天后内存持续上升最终触发 Full GC 频繁。排查步骤使用memory查看堆内存各区域的使用情况确认老年代持续增长。使用heapdump导出堆快照用 MAT 分析大对象和引用链。结合sc和getstatic检查是否有静态集合持续增长。定位到缓存无上限的问题修复后验证。关键命令bashmemory heapdump /tmp/heap.hprof getstatic com.example.demo.cache.UserCache CACHE_MAP12.4 案例四类冲突导致 NoSuchMethodError现象某个接口调用时抛出 NoSuchMethodError但本地测试正常。排查步骤使用sc -d查看报错类的加载器和来源路径发现加载了旧版本的类。使用sm查看运行期实际的方法签名与编译期对比。确认是依赖冲突导致排除旧版本依赖后重新发布。关键命令bashsc -d com.example.demo.service.OrderService sm com.example.demo.service.OrderService calcTotal classloader -t十三、性能开销与使用建议Arthas 虽然强大但并不是零开销。不同的命令对性能的影响差异很大使用时需要根据场景权衡。命令性能开销适用场景dashboard低宏观观察可较长时间使用thread低线程问题排查快照式使用watch中高方法级观察建议配合 -n 和条件表达式trace高调用链路追踪短时间使用tt中记录调用现场注意内存占用profiler中高性能分析短时间采样使用建议优先从宏观命令入手逐步收敛到具体方法。方法级命令一定配合 -n 限制次数避免无限输出。使用条件表达式精准过滤减少无效输出和性能开销。排查结束后及时执行stop清理字节码增强。生产环境尽量选择低峰期操作必要时先在测试环境验证。十四、总结Arthas 之所以能成为 Java 开发者必备的线上排障利器核心在于它把原本分散、复杂、需要停机或加日志才能完成的诊断能力整合成了一套免重启、无侵入、交互友好的命令行工具。通过本文的梳理可以把 Arthas 的能力体系归纳为几条主线宏观观察dashboard、jvm、memory 帮助快速建立对系统整体状态的认知。线程诊断thread 系列命令解决 CPU 飙高、死锁、线程阻塞等高频问题。方法诊断watch、trace、stack 三剑客深入到方法级别的入参、返回值、异常和调用链。现场记录tt 命令像时空隧道一样记录和重放调用解决偶发问题难以复现的痛点。类与加载sc、sm、classloader、getstatic 解决类冲突、版本不兼容、配置不生效等问题。在线热更新jad、mc、redefine 组合支持紧急场景下的不停机修复。其他利器ognl、monitor、profiler、logger 覆盖更多细分场景。