Java问题排查：Arthas工具使用教程

本文深入解析了Java线上问题排查中Arthas工具的实战痛点与避坑指南，涵盖JDK版本兼容性（如JDK 11+缺失sun.misc.Signal导致启动失败）、watch命令失效的底层原因（代理类、泛型擦除、字节码增强限制）、内网离线部署方案（禁用更新检查、使用完整离线包）、高CPU问题的精准定位逻辑（区分Java线程状态与真实CPU消耗源，结合native栈分析），并强调Arthas输出仅为瞬时线索，需联动heapdump、async-profiler等工具穿透表象——帮你避开90%的误判陷阱，真正用好这把JVM诊断利器。

Arthas 启动失败：找不到 java 或提示 NoClassDefFoundError: sun/misc/Signal

Arthas 依赖目标 JVM 的运行时类，不是所有 JDK 版本都默认包含 sun.misc.Signal（尤其 JDK 11+ 默认移除了该类）。启动报这个错，基本是 JDK 版本不兼容或 Arthas 自身版本太老。

• 用 java -version 确认线上 JDK 是 OpenJDK 还是 Oracle JDK，以及具体版本（如 17.0.2）
• Arthas 3.6.0+ 才完整支持 JDK 17；JDK 11~16 推荐用 3.5.5；JDK 8 必须用 3.4.x 或更早
• 别直接下载官网首页的“最新版”——它可能已放弃对旧 JDK 的兼容；去 GitHub Releases 按 JDK 版本选 tag
• 启动命令别写成 ./as.sh pid 就完事，加 -v 看详细日志：./as.sh -v -p 12345

watch 命令返回空或超时：方法没被命中？参数没抓到？

watch 不是万能监听器，它依赖 JVM 的字节码增强（bytecode retransformation），而很多框架（Spring AOP、Lombok、CGLIB 代理）会让实际执行的方法和你写的源码不一致。

• 先用 sc -d *YourService* 确认类是否已被加载，再用 sm *YourService* methodName 看方法签名是否匹配（注意泛型擦除后是 Object 还是 String）
• 如果方法在代理类里（比如 com.example.YourService$$EnhancerBySpringCGLIB$$abc123），就得 watch 那个代理类，而不是原始类名
• 避免用通配符过度匹配：watch com.example.* * * -n 5 可能触发大量增强，导致应用卡顿甚至 OOM
• 加 -x 3 展开深度，否则嵌套对象只显示 toString() 结果，看不出真实值

线上不能连公网，怎么离线部署 Arthas？

Arthas 启动时默认会检查更新、下载附加组件（如 arthas-spring-boot-starter），但内网环境没外网权限就会卡住或失败。

• 下载完整离线包：arthas-bin.zip（不是 arthas-boot.jar），解压后所有脚本和 jar 都在本地
• 启动前设环境变量禁用远程行为：export ARTHAS_DISABLE_UPDATE_CHECK=true
• 用 ./as.sh --no-update-notifier -p 12345 强制跳过检查
• 如果目标进程开了 SecurityManager，需确认 RuntimePermission("accessDeclaredMembers") 和 ReflectPermission("suppressAccessChecks") 已授权，否则 ognl、watch 全部失效

thread -n 5 显示的线程全是 WAITING，但 CPU 却飙高

CPU 高 ≠ 线程在 RUNNABLE，Java 线程状态是 JVM 层面的视图，而 CPU 使用可能来自 JNI 调用、GC、锁竞争、或 native 代码（比如 Netty 的 epoll_wait、Log4j2 的异步日志队列）。

• 先用 dashboard 看整体 GC 频率和耗时，vmtool --action getInstances --className java.lang.Thread --limit 10 查原生线程 ID（nid）
• 配合系统命令定位：top -Hp 找出高 CPU 的线程，再用 printf "%x\n" 转为十六进制，去 thread 输出里搜 nid
• 如果高 CPU 线程对应的是 Unsafe.park 或 epollWait，大概率是 I/O 等待或锁争用，不是 Java 方法本身耗 CPU
• 别迷信 thread -n，它只看 Java 栈；真要深挖得结合 async-profiler 或 perf 抓 native stack

Arthas 是把好刀，但它的输出只是线索，不是结论。最常被忽略的是：它看到的永远是“快照”，而问题往往藏在两次快照之间的状态漂移里——比如一个被反复创建又丢弃的临时对象，在 watch 里一闪而过，但在 heapdump 里能看清引用链。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。