Arthas 4: Live JVM Diagnostics with AI-Powered Flame Graphs

What Is Arthas?

Arthas is a Java Agent that attaches to a running JVM via the attach mechanism — no restart, no code changes, no pre-instrumentation required. Once attached, you interact with it through a shell-like terminal to diagnose the JVM in real time.

Its core capabilities fall into several categories:

Global view : dashboard (threads, memory, GC, system load), jvm (JVM parameters, class-loading stats).

Thread analysis : thread (stack traces), thread -n (top CPU threads), thread -b (deadlocks).

Method-level diagnostics : watch (parameters/return values), trace (call-chain latency), monitor (periodic stats), tt (record/replay call snapshots).

Class operations : sc (search loaded classes), jad (decompile runtime bytecode), classloader (inspect classloaders).

Hot code replacement : jad + mc + redefine to modify method bodies on the fly.

Performance profiling : profiler (flame graphs via async-profiler), jfr (JDK Flight Recorder).

What's New in Arthas 4

2.1 JDK Support: 8 through 25

Arthas 4 requires JDK 8+ and explicitly supports JDK 17, 21, and 25. Teams running on newer JDKs no longer need to keep an old JDK just for diagnostics. Dependencies (Jackson, Fastjson2, OGNL, Netty) were also upgraded for security.

2.2 Flame Graphs: From CPU Time to Wall-Clock Time

The profiler command bundles async-profiler, upgraded to version 4.4 in Arthas 4.2.0. Starting with 4.0.2, the --wall flag enables wall-clock profiling, which captures time spent waiting (lock contention, network I/O, DB pool exhaustion) — scenarios where CPU appears low but latency is high. Session timeout was extended from 30 minutes to 3 hours to prevent mid-profiling disconnects.

2.3 MCP Server: AI-Assisted Diagnostics

Arthas 4 implements an MCP (Model Context Protocol) Server on its HTTP endpoint. AI clients (Cherry Studio, Cline, Claude Desktop) can connect and invoke 29 diagnostic tools ( dashboard, thread, trace, jad, profiler, etc.) via natural language. This experimental module lowers the barrier: instead of memorizing command syntax and OGNL expressions, you describe the symptom and the AI translates it into the appropriate command sequence.

Practical Scenarios

4.1 Find the Busiest Threads

# Show top 5 CPU-consuming threads
thread -n 5

Output includes thread name, CPU%, and current stack. If a thread (e.g., pool-7-thread-3) stays in HashMap.get(), follow up with trace.

4.2 Trace Method Call Latency

# Trace createOrder, only show calls >100ms, limit to 5 invocations
trace com.example.OrderService createOrder '#cost>100' -n 5

trace

defaults to one level of internal calls; use --maxDepth for deeper tracing (caution: overhead grows quickly). JIT-inlined methods may not appear — this is expected, not a bug.

4.3 Observe Parameters and Return Values

# Watch params and return object, expand 2 levels
watch com.example.OrderService createOrder '{params, returnObj}' -x 2

Caveats : watch matches subclasses/implementations by default — scope may be larger than intended. On high-frequency methods, always limit with -n or conditional filters to avoid CPU saturation. Keep -x ≤ 3; expanding large objects triggers heavy reflection.

4.4 Time Tunnel (tt) for Post-Mortem Analysis

# Record invocations
tt -t com.example.OrderService createOrder
# List recordings
tt -l
# Replay the 10th invocation
tt -i 10 -p

tt

stores full call context (up to 100 entries by default) for later replay, even with modified parameters. Critical : records hold object references; if the object mutates later, replayed values may be stale. Exiting Arthas does not clear the tt cache — run tt --delete-all to avoid memory leaks.

4.5 Generate Flame Graphs

# CPU sampling
profiler start
profiler stop --file /tmp/cpu-flame.svg

# Wall-clock sampling (wait time)
profiler start --wall
profiler stop --file /tmp/wall-flame.svg

Open the SVG in a browser; frame width = time consumption.

AI-Assisted Diagnostics in Practice

5.1 Enable MCP

In arthas.properties:

arthas.mcpEndpoint=/mcp
arthas.httpPort=8563
arthas.password=your-secure-password

Verify with curl http://localhost:8563/mcp.

Configure AI client (e.g., Claude Desktop, Cline) with streamable HTTP transport pointing to http://localhost:8563/mcp and Bearer token authentication.

5.2 Example Interactions

Scenario 1: CPU spike — User asks: "Show me the highest-CPU threads and what they're doing." AI calls thread, returns: "Top thread is pool-7-thread-3 stuck in HashMap.get() inside OrderService.calculateDiscount; suggest trace on that method." Completed in ~30 seconds vs. 3–8 minutes manually.

Scenario 2: Intermittent timeout — User: "Order submit P99 spikes; trace OrderService.submitOrder focusing on DB and RPC calls." AI runs trace com.example.OrderService submitOrder -n 10, finds inventoryClient.deduct() at 3.2s (normal 50ms), advises checking inventory service health and timeout config.

Scenario 3: Suspected memory leak — User: "Frequent old-gen GC, possible leak; generate heap dump and analyze." AI invokes heapdump, shows memory region breakdown, recommends MAT analysis focusing on byte[] and HashMap retained heap.

5.3 Boundaries of AI Assistance

AI can : translate symptoms to command sequences, summarize raw output into conclusions, reduce manual lookup time.

AI cannot : judge whether a conclusion matches business logic (e.g., why inventory service timed out — root cause still requires human investigation).

Safety : MCP is experimental; restrict production use to read-only diagnostics ( trace, watch, thread). Avoid letting AI execute redefine hot-swaps.

Pros and Cons

Pros

Zero-intrusion live diagnostics via attach.

JDK 8–25 coverage — no legacy JDK retention needed.

Complete flame graph support: CPU + wall-clock (async-profiler 4.4). tt time tunnel for elusive, intermittent bugs.

MCP Server opens AI-driven workflow (experimental but promising).

Mature ecosystem: open-sourced 2018, maintained by Alibaba, active community, solid docs.

Cons

High-frequency methods need -n /filters; unrestricted watch / trace can saturate CPU. tt cache persists after exit — manual tt --delete-all required to prevent leaks.

Hot swap ( redefine) limited to method bodies; no field/method addition; conflicts with watch / trace (must reset first); only for emergency fixes.

MCP Server still experimental; protocol and client support evolving.

Applicability Matrix

Production intermittent issues — ✅✅✅ Strong: No code change/restart; inspect live state.

CPU spike diagnosis — ✅✅✅ Strong: thread -n + trace quickly pinpoints hotspots.

Latency high but CPU low — ✅✅✅ Strong: profiler --wall reveals wait-time breakdown.

Class conflicts / NoSuchMethodError — ✅✅✅ Strong: sc + jad + classloader for resolution.

Emergency hot fix — ✅✅ Recommended: Method-body only; suitable for urgent patches, not routine releases.

Post-mortem of rare exceptions — ✅✅✅ Strong: tt snapshots enable replay after the fact.

AI-assisted onboarding — ✅✅ Recommended: MCP + AI client lowers command-learning curve.

First production hot swap — ❌ Not recommended: Practice in test first; production risk high.

Conclusion

Arthas 4 transforms production diagnostics from "guessing" to "seeing" and now to "asking." JDK 25 support ensures compatibility with modern runtimes; wall-clock flame graphs solve the "CPU low but slow" blind spot; MCP Server points toward a future where describing the symptom is enough to trigger the right diagnostic commands. References: https://github.com/alibaba/arthas, https://arthas.aliyun.com.