线上 Java 出了毛病，本地 IDE 远程调试基本用不上：网络隔离、审计不让挂、断点一打还可能拖停业务线程。加日志再发版又赶不上「重启就消失」的那种毛病。这种时候很多人会想起 Arthas——问题是 4.x 还适不适合现在的 JDK，以及一上来该敲哪些命令、哪些命令最好先别碰。
官方把自己定位成什么
中文简介和英文 Introduction 口径一致：不改业务代码、不重启 JVM，看 load、内存、GC、线程，看方法出入参和耗时、类加载来源等。文中原话强调它作为观察者，不会暂停正在运行的线程——这点和 IDE 断点调试不是一类东西。能力列表里还包括反编译确认线上到底跑的哪版字节码、调用栈、trace 慢子调用、监控 QPS/RT、profiler/火焰图、按类查堆里的实例等。交互是命令行，带 Tab 补全，也支持 telnet / WebSocket，方便本机或远程连上再诊断。
JDK 支持写在简介里：Arthas 4.x 支持 JDK 8+，并点名包括 JDK 17、JDK 21 和 JDK 25。系统覆盖 Linux / Mac / Windows。Maven Central 上 arthas-packaging 的 metadata 显示当前 latest/release 是 4.3.5。Docker 文档里 ephemeral debug / sidecar 场景举例用的是 4.3.4 及以后，要求调试容器里是完整 JDK，而不是只有 JRE。跨 mount namespace attach、共享 PID 的 sidecar 等细节也写在同一页。若目标还是 JDK 6/7，下载页指向旧的 Arthas 3 线，别和 4.x 混用。
下载页提供 Maven 仓库包、GitHub Releases，以及解压后的 as.sh / arthas-boot.jar 启动方式。选哪种都行，要紧的是确认拉到的是 4.x 而不是误下到给 JDK 6/7 用的 3.x。attach 成功后先跑只读命令建立现场，再决定要不要加深。
排查顺序可以先「看」再「改」
没有标准剧本，但生产上比较稳的习惯大概是这样：
- 先
dashboard、thread看整体负载、线程状态和 CPU 热点，确认是不是某条业务线程卡住或打满，而不是一上来改字节码。 - 再用
watch/trace盯具体方法的入参、返回值和子调用耗时。需要核对「线上跑的是不是我以为的那版」时，用jad反编译对照。 sc/classloader一类命令适合查类从哪个 jar 来、有没有冲突。火焰图、profiler 适合已经锁定热点、要看采样分布的时候。
redefine、热替换这类能改运行中类的能力，文档里有，但不该当成默认急救第一步。观察清楚之前就改线上字节码，排障记录难复盘，也容易和发布流程打架。权限、变更窗口、允不允许 attach，按你们公司生产规范来。容器场景还要确认镜像里有没有完整 JDK、PID 命名空间能不能看到目标进程，以及目标 JVM 有没有开 -XX:+DisableAttachMechanism。
Arthas 解决不了「根本没权限登录那台机器」或「进程已经 OOM 被杀」这类前提问题。它适合的是：进程还在、能 attach、需要当场看清调用和状态。版本号以简介页和 Maven metadata 为准，发版节奏会动，attach 前对一下自己拉到的包。
常见误区还有：把 Arthas 当成「可以随便在生产改代码的热补丁平台」。简介列的能力里确实有观察之外的手段，但官方反复强调的定位是诊断观察。排障记录里写清 attach 时间、用过的命令、有没有动过 redefine，比事后靠记忆复盘靠谱。多实例部署时只 attach 其中一台，也要意识到流量未必打到你正在看的那份进程。
你们线上现在卡在 JDK 几？4.x attach 有没有在某种发行版或容器里踩过坑，欢迎补充版本和现象（别贴敏感业务数据）。