Arthas 4: JDK 25 Support, Wall-Clock Flame Graphs & AI-Assisted Java Diagnostics

What Is Arthas?

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

Core capabilities fall into several categories:

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

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

Method inspection : watch (parameters and return values), trace (call-chain latency), monitor (periodic stats), tt (record and replay invocation snapshots).

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

Hot reload : jad + mc + redefine — modify method bodies and apply instantly without restart.

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

What's New in Arthas 4

2.1 JDK Support: 8 through 25

Arthas 4 requires JDK 8+ and officially 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 to Wall-Clock Time

The profiler command bundles async-profiler, upgraded to version 4.4 in Arthas 4.2.0. Crucially, from 4.0.2 it supports the --wall flag to profile wall-clock time instead of only CPU time.

This solves the classic "CPU looks low but latency is high" problem. Typical causes — lock contention, network I/O blocks, exhausted DB connection pools — leave threads waiting without consuming CPU, invisible to traditional CPU flame graphs. Wall-clock flame graphs expose where the waiting time actually goes.

Session timeout was also extended from 30 minutes to 3 hours , preventing mid-profiling disconnects.

2.3 MCP Server: Natural-Language AI Diagnostics

Arthas 4 implements an MCP (Model Context Protocol) Server on its HTTP endpoint. AI clients (Cherry Studio, Cline, Claude Desktop, etc.) can connect and invoke 29 diagnostic tools — dashboard, thread, trace, jad, profiler, etc. — as functions. You describe the symptom in natural language ("show me the busiest threads" or "trace OrderService.submitOrder"), the AI translates it to the right Arthas commands, executes them, and summarizes the results.

This module is still experimental. The direction is clear: lowering the diagnosis barrier so engineers describe phenomena instead of memorizing command syntax and OGNL expressions.

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 sticks in a method (e.g., HashMap.get()), follow up with trace.

4.2 Trace Method Call-Chain Latency

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

trace

by default traces only one level of internal calls; use --maxDepth for deeper tracing (caution: high overhead). Gotcha: JIT-inlined methods may not appear — this is expected, not an Arthas 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 add -n to limit invocations or use condition filters, otherwise CPU spikes. Keep -x ≤ 3; expanding large objects triggers heavy reflection.

4.4 Time Tunnel (tt) — Post-Mortem Debugging

# Record invocations
tt -t com.example.OrderService createOrder

# List recorded invocations
tt -l

# Replay invocation #10
tt -i 10 -p

tt

stores full context per invocation (params, return, exceptions, timestamp). Unlike real-time watch, you can replay repeatedly, inspect slowly, even modify parameters and re-execute. Critical pitfalls: Default capacity is 100 records; stored as object references — if the object mutates later, replayed values may be stale. Exiting Arthas does NOT auto-clear the tt cache — run tt --delete-all or risk memory leaks.

4.5 Generate Flame Graphs

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

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

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

AI-Assisted Troubleshooting in Action

5.1 MCP Configuration

In arthas.properties:

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

Verify: curl http://localhost:8563/mcp should return MCP handshake info.

AI client config (Claude Desktop / Cline example):

{
  "mcpServers": {
    "arthas-mcp": {
      "type": "streamableHttp",
      "url": "http://localhost:8563/mcp",
      "headers": {
        "Authorization": "Bearer your-secure-password"
      }
    }
  }
}

5.2 Example AI Interactions

Scenario 1: CPU spike — locate hot threads

"Show me the current highest-CPU threads and what they're doing."

AI calls thread via MCP, returns: "Top thread is pool-7-thread-3, stuck in HashMap.get() inside OrderService.calculateDiscount. Suggest trace on that method." Done in ~30 seconds vs 3–8 minutes manually.

Scenario 2: Intermittent timeout — trace method latency

"Order submit P99 timeout. Trace OrderService.submitOrder internal steps, focus on DB and downstream RPC."

AI runs trace com.example.OrderService submitOrder -n 10, finds inventoryClient.deduct() taking 3.2s (normal 50ms), concludes: "Inventory service RPC timeout — check its health and timeout config."

Scenario 3: Suspected memory leak — heap dump

"Frequent old-gen GC, possible leak. Generate heap dump and analyze."

AI invokes heapdump, shows memory region breakdown, advises using MAT on the hprof, focusing on byte[] and HashMap retained heap.

5.3 Boundaries of AI Assistance

AI can: translate symptoms → command sequences; raw output → structured conclusions; eliminate manual lookup of syntax.

AI cannot: judge whether a conclusion matches business logic. "Inventory RPC timeout" — root cause (service down? network? traffic spike?) still requires human analysis.

Safety: MCP Server is experimental. In production, restrict AI to read-only diagnostics ( trace, watch, thread); do NOT allow redefine hot-swaps.

Pros & Cons

Pros

Zero-intrusion: Attach to live JVM, no restart, no code change.

JDK 8–25 coverage: No need to keep legacy JDK for tooling.

Complete flame graphs: async-profiler 4.4 + wall-clock sampling covers both CPU-bound and wait-bound issues.

Time Tunnel (tt): Record, replay, modify-and-replay for intermittent bugs.

MCP + AI: 29 tools callable via natural language (experimental but promising).

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

Cons

Overhead on hot paths: watch / trace without -n or filters can saturate CPU.

tt requires manual cleanup: Cache persists after detach; forget tt --delete-all → memory leak.

Hot-reload limits: Method bodies only; no field/method addition/removal. Conflicts with watch / trace — must reset first. Suitable only for emergency tiny fixes.

MCP still experimental: Protocol and client support evolving; production adoption needs caution.

Applicability Matrix

Production intermittent issues — ✅✅✅ Strong: No code change/restart; live inspection

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

Latency up but CPU normal — ✅✅✅ Strong: profiler --wall reveals wait-time breakdown

Class conflicts / NoSuchMethodError — ✅✅✅ Strong: sc + jad + classloader for root cause

Emergency hot-fix — ✅✅ Recommended: Method-body only; good 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-time hot-reload in prod — ❌ Not recommended: Practice in test first; prod risk high

Conclusion

Arthas 4 shifts production diagnostics from "guessing" to "seeing" and now to "asking." You no longer infer thread behavior from logs, guess latency distribution from metrics, or add logging + redeploy + wait for reproduction to catch a flaky bug. Attach Arthas, run a few commands, the live state is visible.

The 4.x roadmap is deliberate: track JDK evolution (25 support), close the flame-graph gap (wall-clock for wait-time), and embrace AI workflows (MCP Server). JDK 25 support means new projects qualify; wall-clock flame graphs solve "low CPU but slow"; MCP hints at a future where you describe the symptom and AI drives the investigation.

GitHub: https://github.com/alibaba/arthas

Official docs: https://arthas.aliyun.com