Arthas 4: Live JVM Surgery, Wall-Clock Flame Graphs, and AI-Driven Diagnostics
Java teams no longer need to restart production services or wait for a release window to diagnose slow endpoints, and the new MCP integration means the diagnostic command syntax becomes something an AI assistant can handle. But the AI layer is experimental and the article wisely keeps the final judgment about business logic with the engineer.
Arthas, the Java agent that attaches to a running JVM to inspect threads, methods, classes, and performance without restarting or modifying code, has reached version 4. The upgrade adds JDK 25 support, brings async-profiler to 4.4, and introduces a `--wall` flag so flame graphs can show wall-clock time, exposing where latency goes when CPU is idle but endpoints are slow.
The headline feature is an experimental MCP server. It exposes 29 diagnostic tools through a streamable HTTP endpoint, so AI clients like Cline or Claude Desktop can translate natural-language requests such as "which thread is busiest" into real `thread`, `trace`, or `watch` commands and summarize the output. The author argues this lowers the diagnostic learning curve, but notes the AI still can't judge whether a conclusion fits the actual business context, and recommends keeping production usage read-only.
The article walks through practical commands for the most common scenarios, including `thread -n 5` for hot threads, `trace` with cost thresholds, `watch` with expansion limits, `tt` time tunnels for replaying invocations, and `profiler` for both CPU and wall-clock sampling. It also warns about overhead on hot methods, the 100-record limit and manual cleanup of `tt`, and restrictions around hot-updating method bodies.
The move from CPU flame graphs to wall-clock flame graphs addresses a real gap: many slow endpoints are caused by waiting, not by CPU consumption, and traditional tools miss that entirely.
Offering an MCP server for a mature diagnostic tool signals a shift in how developers interact with infrastructure: the command syntax becomes an implementation detail, and the operator's skill moves from remembering flags to describing symptoms accurately.
The author's caveat that AI cannot judge whether a diagnosis fits the business logic is the right boundary. An AI can tell you an RPC timed out, but deciding whether the cause is a dead service, a network issue, or a call spike still requires human judgment.
The experimental MCP module and the recommendation to keep production read-only show a sensible caution: letting an AI trigger hot code replacement on a live service is a risk most teams won't want to take.