Arthas 4: Live JVM Surgery, Wall-Clock Flame Graphs, and AI-Driven Diagnostics

Why are more and more people using Arthas 4?

A few days ago, an old service that had been running for three years suddenly started lagging around 3 p.m. every day.

CPU was low, memory was normal, and GC logs showed nothing wrong.

There were no exceptions in the logs, and all monitoring metrics looked "normal."

But users could feel the slowness; the P99 of an endpoint went from 50ms to 800ms.

The team spent two days investigating with no clues.

Someone suggested restarting, but this was a core service, and the maintenance window was hard to get approved. Even if we restarted, the problem would probably come back—since we hadn't found the root cause, restarting just hides the issue.

I told them not to restart. Then I attached Arthas and ran a few commands.

The first one, thread -n 5, looks at the five threads with the highest CPU usage. We found a thread named pool-7-thread-3 was using CPU for a long time, but its stack trace showed it was always doing HashMap.get().

The second command, trace, traced the method that thread was running to see the call chain. We found that a place that should have used a local cache was, because of a wrong cache key, making a synchronous remote call every time. When the remote service was slow, the thread got stuck there.

The whole investigation took less than fifteen minutes. No restart, no code changes, no added logs.

That is the value of Arthas.

It is not "just another monitoring tool"; it is a probe that lets you perform "surgery" directly on a live JVM.

Without changing code, restarting, or waiting for the next release window, you can see what threads are doing, who calls a method, what the return values are, and where the time goes.

And Arthas 4 is a major version upgrade of this tool in 2026.

It pushed JDK support up to 25, completed the flame graph capability, and did something very interesting—it lets you use natural language to ask an AI to run diagnostic commands for you.

In this article, I'll break down what Arthas 4 is better at, how to use it, and what scenarios it fits.

I hope it helps.

More project practice: Java Commando Squad at susan.net.cn/project

1. What exactly is Arthas?

Some might say: "Can't I use jstack, jmap, jstat to debug issues?"

Yes, you can.

But those are command-line tools that come with the JDK. They share a common problem: you need to plan ahead before starting the application, or at least know which tool to use and what metrics to look at.

Arthas is different.

It 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 can run commands in its interactive terminal, diagnosing the JVM like you would with a shell.

Its core capabilities can be categorized as follows:

Global view: dashboard for threads, memory, GC, system load; jvm for JVM parameters and class loading statistics.

Threads: thread for thread stacks, thread -n for the highest CPU threads, thread -b for deadlocks.

Methods: watch for parameters and return values, trace for call-chain latency, monitor for periodic statistics, tt for recording invocation snapshots for later replay.

Classes: sc to search loaded classes, jad to decompile runtime bytecode, classloader to inspect class loaders.

Hot update: jad + mc + redefine pipeline to change method bodies without restart.

Performance analysis: profiler for flame graphs, jfr for JVM flight recordings.

2. What is actually new in Arthas 4?

Arthas 3.x was already a mature tool.

I think the 4.x upgrade focuses on three directions: catching up with JDK evolution, completing performance analysis capabilities, and embracing the AI workflow.

2.1 JDK support: from 8 to 25

Arthas 4 requires JDK 8 or above, and officially supports JDK 17, 21, 25. This means if your team has already moved the runtime to JDK 21 or even newer versions, Arthas 4 can attach directly without needing to keep an old JDK for diagnostic tools.

Dependencies were also upgraded. Jackson, Fastjson2, OGNL, and Netty were all bumped to newer versions.

Diagnostic tools are also software; their own dependency security matters.

2.2 Flame graphs: from "watching CPU" to "watching wall-clock time"

The profiler command embeds async-profiler, and version 4.2.0 upgraded to 4.4. More importantly, starting with 4.0.2 it supports the --wall parameter to look at wall-clock time.

This capability solves a very painful category of problems: when CPU isn't high but the endpoint is still slow.

Typical scenarios include lock waiting, network IO blocking, and database connection pool exhaustion. In these cases, threads are "waiting," not consuming CPU, so traditional CPU flame graphs can't show it.

Wall-clock flame graphs expose these "waiting times" and tell you where the time actually went.

Additionally, the session default timeout was extended from 30 minutes to 3 hours. No more being kicked off in the middle of sampling.

2.3 MCP Server: letting AI run diagnostic commands for you

This is the most interesting change in Arthas 4.

MCP (Model Context Protocol) is a protocol that allows AI assistants to call external tools.

Arthas 4 implements an MCP Server on its own HTTP service, so an AI client can execute Arthas diagnostic commands like calling a function.

The documentation lists 29 diagnostic tools, including dashboard, thread, trace, jad, profiler. Clients like Cherry Studio, Cline, and Claude Desktop can be configured so you can say "see which thread is busiest" or "trace this method's call chain" in natural language, and the AI will run the corresponding commands and present the results.

This capability is still an experimental module, but the direction is clear: the barrier to diagnosis is lowering. Previously you needed to remember trace parameters and OGNL expressions; in the future you might only need to describe the symptoms.

3. A diagram to understand Arthas 4's core capabilities

This figure shows the full capability map of Arthas 4.

From attaching to a JVM, to global views, method-level diagnostics, class operations, performance analysis, and then MCP's AI integration, every layer has corresponding commands.

4. Practical examples: several most common scenarios

4.1 Scenario 1: Find the busiest threads

# Look at the 5 threads with the highest CPU usage
thread -n 5

The output shows thread names, CPU usage, and current stack information. If you see a thread stuck on a particular method, use trace to chase it.

4.2 Scenario 2: Trace method call chain latency

# Trace method calls, only show those with latency > 100ms
trace com.example.OrderService createOrder '#cost>100' -n 5

trace by default only traces one level of internal calls, not recursively. Use --maxDepth for multiple levels, but don't set it too deep; performance overhead becomes large.

A common pitfall: Methods that have been inlined by the JIT may not be traceable. That is normal, not a bug in Arthas.

4.3 Scenario 3: Observe parameters and return values

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

Note: watch by default matches subclasses and implementation classes, which may be broader than you expect. On high-frequency methods, always add -n to limit the count, or add a condition filter, otherwise you will blow up the CPU.

Don't set -x too large either; at most 3 levels. Expanding large objects triggers lots of reflection, which carries significant overhead.

4.4 Scenario 4: `tt` time tunnel for post-hoc investigation

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

# View the list of records
tt -l

# Replay the 10th invocation
tt -i 10 -p

tt is my personal favorite. watch is real-time; if you miss it, it's gone. tt stores the full context of each invocation, so you can review it slowly, replay it repeatedly, and even modify parameters to re-execute.

But you must remember one pitfall: tt stores at most 100 records by default, and it stores object references. If objects are later modified, the values you see may be wrong. Also, exiting Arthas doesn't automatically clean the tt cache; remember to run tt --delete-all after you're done, or you could hit a memory leak.

4.5 Scenario 5: Generate flame graphs

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

# Wall-clock sampling (see where waiting time went)
profiler start --wall
profiler stop --file /tmp/wall-flame.svg

Open the generated SVG file in a browser to view it. The width of the flame graph represents the time spent; the wider, the more resource consumed.

5. AI in practice: use natural language to let AI troubleshoot for you

This is the part of Arthas 4 that deserves special mention.

The MCP Server lets AI call Arthas's diagnostic tools. You only need to describe the symptom; the AI handles translating it into commands, executing them, and summarizing the results.

5.1 Configure MCP

Open the MCP endpoint in arthas.properties:

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

Verify the service is reachable:

curl http://localhost:8563/mcp

A return of MCP protocol handshake info means it works.

AI client configuration (using Claude Desktop or Cline as an example):

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

5.2 How AI locates problems for you

Scenario 1: High CPU, locate hot threads

Traditional way: You need to know to run dashboard first, then thread -n 5, then analyze the output line by line. It takes 3-8 minutes.

AI way: You type in the chat box—

"Help me see which threads have the highest CPU usage right now, and what they are doing."

The AI calls the thread tool via MCP and says: "The highest one is pool-7-thread-3, which has been executing HashMap.get(). The stack shows it's stuck in OrderService.calculateDiscount. I suggest using trace on that method."

The entire interaction takes less than 30 seconds.

Scenario 2: Intermittent endpoint timeouts, trace method latency

You say—

"The order submission endpoint's P99 is timing out. Help me trace the internal step-by-step latency of OrderService.submitOrder, focusing on database calls and downstream RPC."

AI automatically runs:

trace com.example.OrderService submitOrder -n 10

From the trace results it finds inventoryClient.deduct() takes 3.2 seconds (normally ~50ms), then tells you: "The inventory service RPC is timing out. Check the inventory service's health status and timeout configuration."

Scenario 3: Memory leak, generate heap dump

You say—

"Old gen GC is frequent; I suspect an object leak. Help me generate a heap dump and analyze it."

AI calls heapdump to generate the file, then shows the memory usage for each region and suggests using MAT to analyze the hprof, focusing on byte[] and HashMap retained heap.

5.3 Where are the limits of AI troubleshooting?

What AI can do for you: translate "symptoms" into "command sequences," turn "raw output" into "conclusions," and reduce the time you spend flipping through manuals or checking syntax.

What AI cannot do for you: judge whether the conclusion actually fits your business logic. AI says "inventory RPC timeout," but why is it timing out? Did the inventory service go down, a network issue, or a sudden spike in calls? That judgment is still up to you.

One security suggestion: The official docs explicitly mark MCP Server as an experimental module, and recommend using it mainly for read-only diagnostics in production, avoiding letting AI trigger hot replacement operations like redefine. AI can run trace, watch, thread, but don't let it run redefine.

6. Pros and cons

Advantages

1. No restart, no code changes
Attaches to a running JVM via the attach mechanism, making the diagnostic process zero-intrusion on business logic. This is Arthas's core value.

2. Full coverage from JDK 8 to 25
Arthas 4 supports JDK 8 and above, including 17, 21, 25. No need to keep an old JDK for diagnostic tools.

3. Complete flame graph capability
async-profiler 4.4 + wall-clock sampling covers both "high CPU" and "CPU isn't high but it's slow" problems.

4. tt time tunnel
A gem for post-hoc investigation of intermittent issues. Records invocation snapshots, supports replay, and lets you modify parameters to retry.

5. MCP Server embraces AI
29 diagnostic tools can be called through natural language. Still experimental, but the direction is clear.

6. Mature ecosystem
Open-sourced since 2018, maintained by Alibaba, active community, well-documented.

Disadvantages

1. Be careful on high-frequency methods
Commands like watch and trace themselves have performance overhead. Using them without limits on hot methods can saturate the CPU. Must add -n or condition filters.

2. tt needs manual cleanup
Exiting Arthas doesn't automatically clear the tt cache. Forgetting to clean up can cause memory leaks.

3. Hot update has many restrictions
Only method bodies can be changed; you cannot add or remove fields or methods. It conflicts with commands like watch/trace; you must run reset before executing. For complex logic, hot update is not recommended; use it only for emergency small bugs.

4. MCP Server is still experimental
The 29 tools cover the core capabilities, but the protocol and client support are still evolving. Large-scale production usage still needs observation.

7. Applicable scenarios

Scenario	Recommendation	Reason
Investigating intermittent online issues	✅✅✅ Highly recommended	No code changes, no restart, see the scene directly
Locating high CPU	✅✅✅ Highly recommended	`thread -n` + `trace` quickly locate hot spots
Endpoint slow but CPU low	✅✅✅ Highly recommended	`profiler --wall` shows where waiting time goes
Class conflicts / NoSuchMethodError	✅✅✅ Highly recommended	`sc` + `jad` + `classloader` to investigate
Hot fixing small bugs	✅✅ Recommended	Only method bodies can be changed; good for emergencies, not for regular releases
Post-hoc investigation of intermittent exceptions	✅✅✅ Highly recommended	`tt` records snapshots, replay later
Getting started with AI-assisted troubleshooting	✅✅ Recommended	MCP + AI clients lower the cost of learning commands
Using hot update for the first time in production	❌ Not recommended	Practice in a test environment first; production risk is high

More project practice: Java Commando Squad at susan.net.cn/project

8. Final thoughts

Back to the opening question: Why are more and more people using Arthas 4?

Because it turns "online diagnosis" from "guessing" into "seeing," and now from "seeing" into "asking."

You no longer rely on logs to guess what threads are doing, no longer rely on monitoring to guess where method latency goes, and no longer add logs, release, and wait for a recurrence just to track down an intermittent issue. Attach Arthas, run a few commands, and the scene is right in front of you.

The direction of the Arthas 4 upgrade is also clear: keep pace with JDK evolution, complete the flame graph capability, embrace the AI workflow.

JDK 25 support means newer projects can use it, wall-clock flame graphs solve the "CPU isn't high but it's slow" problem, and MCP Server means in the future you might only need to describe the symptom while the AI runs the commands.

Reference resources

GitHub: https://github.com/alibaba/arthas
Official docs: https://arthas.aliyun.com

Arthas 4: Live JVM Surgery, Wall-Clock Flame Graphs, and AI-Driven Diagnostics

1. What exactly is Arthas?

2. What is actually new in Arthas 4?

2.1 JDK support: from 8 to 25

2.2 Flame graphs: from "watching CPU" to "watching wall-clock time"

2.3 MCP Server: letting AI run diagnostic commands for you

3. A diagram to understand Arthas 4's core capabilities

4. Practical examples: several most common scenarios

4.1 Scenario 1: Find the busiest threads

4.2 Scenario 2: Trace method call chain latency

4.3 Scenario 3: Observe parameters and return values

4.4 Scenario 4: tt time tunnel for post-hoc investigation

4.5 Scenario 5: Generate flame graphs

5. AI in practice: use natural language to let AI troubleshoot for you

5.1 Configure MCP

5.2 How AI locates problems for you

5.3 Where are the limits of AI troubleshooting?

6. Pros and cons

Advantages

Disadvantages

7. Applicable scenarios

8. Final thoughts

4.4 Scenario 4: `tt` time tunnel for post-hoc investigation