Arthas
- 5 installs
- 37.5k repo stars
- Updated July 24, 2026
- alibaba/arthas
arthas is a Claude skill for online diagnosis of Java applications and JVM problems using the Alibaba Arthas tool.
About
arthas is a Claude skill for online diagnosis of Java applications and JVM problems using Alibaba Arthas. A developer uses it to match a production symptom to one of three sub-scenarios and follow the diagnostic steps. It stresses collecting information with low-risk read-only commands first and always setting an execution limit on invasive watch, trace, tt, and stack commands.
- Umbrella Arthas guide for online diagnosis of Java/JVM problems in production
- Indexes three sub-scenarios: CPU spikes, EagleEye traceId retrieval, and Spring Context/Bean issues
- Enforces low-risk read-only commands first and mandatory -n execution limits on watch/trace/tt
Arthas by the numbers
- 5 all-time installs (skills.sh)
- Ranked #441 of 596 Debugging skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
arthas capabilities & compatibility
Free; open-source Arthas tooling, no API keys.
- Capabilities
- jvm diagnostics · cpu profiling · spring context inspection
- Use cases
- debugging
- Pricing
- Free
What arthas says it does
Arthas 是 Java 应用在线诊断工具，本 Skill 包含多个子场景的诊断指南。
arthas 诊断 java应用，jvm问题 skill
npx skills add https://github.com/alibaba/arthas --skill arthasAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 5 |
|---|---|
| repo stars | ★ 37.5k |
| Last updated | July 24, 2026 |
| Repository | alibaba/arthas ↗ |
What it does
Diagnose live Java/JVM problems with Alibaba Arthas by matching the user's symptom to a documented sub-scenario and following its steps.
Who is it for?
Diagnosing live Java/JVM issues in production with Arthas
Skip if: Non-JVM runtimes or offline static analysis
When should I use this skill?
A running Java application shows CPU spikes, bean/config issues, or you need a request traceId
What you get
The JVM issue is localized with low-risk Arthas commands and a diagnostic conclusion with evidence.
- A diagnostic conclusion with command-output evidence and next steps
By the numbers
- Indexes 3 diagnostic sub-scenarios (CPU-high, traceId, Spring Context)
Files
JVM CPU 飙高排查指南（Arthas）
适用场景：机器 CPU 飙高、应用响应变慢、负载异常升高。
原则：先用低风险工具定位「哪个线程在忙」，再逐步缩小到「哪个方法/代码路径」。
1) 先确认当前 JVM 整体状态（低风险）
- 使用
dashboard查看 CPU/线程/GC 概况（建议设置有限次数）： - 关注：CPU、线程数、GC 次数/耗时是否异常。
2) 定位最忙线程（关键步骤）
- 使用
thread找出最忙的前 N 个线程并打印堆栈： - 例如：
topN=3或topN=5 - 记录每个热点线程的
threadId与堆栈关键方法名（可用take_notes记录证据）。
判断方向：
- 如果堆栈显示在
java.util.regex、JSON 序列化、日志格式化等：可能是 CPU 密集计算。 - 如果堆栈显示在锁竞争：继续看是否有大量
BLOCKED，并考虑用thread(blocking=true)找出阻塞源头线程。
3) 进一步确认热点方法的调用路径（按需、有限制）
当热点线程堆栈指向某个「可疑方法」时：
- 优先使用
stack/trace针对该方法做路径确认（避免宽泛匹配）。 - 如果需要观测入参/返回值，再考虑
watch或tt，并设置合理的执行次数与超时，避免对线上造成压力。
4) 输出诊断结论
报告至少包含：
- 现象与证据：dashboard 摘要 + topN 线程堆栈关键片段
- 初步结论：CPU 主要消耗在什么类型的逻辑（计算/锁/GC/日志等）
- 下一步：建议进一步 trace/watch 的目标方法（给出类名+方法名的精确范围），或建议用户提供主包名/关键接口信息以继续收敛
Related skills
Azure DiagnosticsSystematically diagnose and resolve production issues on Microsoft Azure using official Microsoft guidance.495k1.3kAzure MessagingQuickly diagnose and fix connection, authentication, and message-processing failures when using Azure Event Hubs or Service Bus SDKs.483k1.3k
Diagnosing BugsGet a systematic, step-by-step process that surfaces the real root cause instead of guessing at bugs.291k200k
Use My BrowserWhen their agent task requires access to the live browser session, rendered DOM state, authenticated dashboards, localhost apps, or DevTools-selected elements instea269k71
Systematic DebuggingFollow a repeatable four-phase process that forces root-cause discovery before any code changes.210k265k
Safe DebugGet conservative, non-destructive diagnosis of deep learning and agent errors before any code changes are made.185k512FAQ
What sub-scenarios does the arthas skill cover?
CPU spikes (cpu-high), EagleEye traceId retrieval (eagleeye-traceid), and Spring Context/Bean issues (spring-context).
What is the safety principle?
Use low-risk read-only commands first, and always set -n execution limits on watch/trace/tt/stack to avoid pressuring production.