使用Arthas MCP对Java应用进行线上诊断的实践指南

curl -o https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar
arithas> thread -b  # 检测死锁
arithas> dashboard  # 查看系统概况
arithas> trace com.example.myclass mymethod  # 追踪方法调用

# javaagent 方式
$ java -javaagent:arthas-agent.jar -jar app.jar

# 直接获得结构化数据
tools = await session.list_tools()
result = await session.call_tool("thread", arguments={"arguments": ["-b"]})

# 配置文件路径
~/.arthas/lib/4.1.9/arthas/arthas.properties
# mcp endpoint 配置
arthas.mcpendpoint=/mcp
# http server 配置
arthas.ip=0.0.0.0          # 绑定所有网卡，允许远程访问
arthas.httpport=9999        # http api 端口
arthas.telnetport=0         # 禁用 telnet（0 表示禁用）
# 认证配置
arthas.password=s2totroqw5zmt8po7m7aiifdzxuzresrkndslxe5tibjmwln5yrpatpijogsax0v

$ java -javaagent:~/.arthas/lib/4.1.9/arthas/arthas-agent.jar -xmx256m -cp out <java-class> 
# 测试 mcp server，上个命令启动后会自动输出bearer认证token
$ curl -h "authorization: bearer s2totroqw5zmt8po7m7aiifdzxuzresrkndslxe5tibjmwln5yrpatpijogsax0v" \
        http://localhost:9999/mcp
# 返回 sse 流
event: endpoint
data: {"method": "initialize", ...}

generic_system_prompt = """你是一个资深的 java 应用诊断专家，拥有 10 年以上的生产环境排查经验。
## 当前诊断目标
{class_name} - {desc}
## 诊断原则
1. **观察驱动**：首先观察系统的整体状态（jvm、线程、内存），形成初步假设
2. **工具优先级**：
   - 简单查询工具优先（thread、jvm、memory、dashboard）
   - 如需流式工具（trace、monitor、watch），注意可能受认证限制
   - 使用 jad 反编译源码来理解代码逻辑
3. **多角度验证**：结合多个工具的结果交叉验证，避免误判
4. **根因导向**：不只找到现象，要深入分析根本原因
5. **解决建议**：给出可操作的解决方案
## arthas 工具速查
- `thread` / `thread -n 3` - 查看线程列表/cpu 最高线程
- `thread -b` - 检测死锁
- `thread <id>` - 查看特定线程的详细堆栈
- `jvm` - jvm 运行时信息
- `memory` - 内存使用情况
- `dashboard` / `dashboard -i 2000` - 系统概况/定期监控
- `jad <classname>` - 反编译类代码
- `sysprop` - 系统属性
- `logger` - 日志配置
## 认证说明
注意：部分流式工具（trace、monitor、watch）可能需要额外的会话认证。
如果遇到 401 错误，请改用其他工具组合（如 thread + jad）来达到同样的诊断目标。
## 输出要求
请按照以下格式输出诊断结果：
1. **观察发现**：通过工具看到的异常现象
2. **问题定位**：问题的具体位置（类名、方法名、行号）
3. **根因分析**：为什么会出现这个问题
4. **解决方案**：具体的修复建议
开始诊断吧！
"""

# 3. 创建 mcp client 和 agent（使用通用系统提示词）
arthas_mcp = mcpclient(
    lambda: streamablehttp_client(
        url="http://localhost:9999/mcp",
        headers={"authorization": "bearer s2totroqw5zmtxxxxxpatpijogsax0v"}
    )
)
# 构建通用系统提示词
system_prompt = generic_system_prompt.format(
    class_name=class_name,
    desc=scenario['desc']
)
agent = agent(
    model=model,
    system_prompt=system_prompt,
    tools=[arthas_mcp], # 将mcp注册到agent中
)

public class cpuhighdemo {
    public static void main(string[] args) throws exception {
        system.out.println("pid: " + processhandle.current().pid());
        system.out.println("[cpuhighdemo] cpu飙高场景启动...");
        // 创建一个死循环线程，执行密集计算
        new thread(() -> {
            while (true) {
                // 密集计算操作（幂运算）
                math.pow(math.random(), math.random());
            }
        }, "cpu-busy-thread").start();  // ← 关键：线程名称
        thread.currentthread().join();
    }
}

启动命令: java -javaagent:/home/ec2-user/.arthas/lib/4.1.9/arthas/arthas-agent.jar -xmx256m -cp /home/ec2-user/workspace/java-diagnosis-demo/out cpuhighdemo
进程启动 pid: 238433
等待 arthas mcp server 启动...
✓ arthas mcp server 已就绪 (端口 9999)

tool #1: dashboard
tool #2: thread
tool #3: jad
tool #4: thread

### 1. 观察发现
通过使用 `dashboard` 和 `thread -n 5` 命令观察到以下异常现象：
- 线程 `cpu-busy-thread` (id 27) 占用了高达 99.97% 的 cpu 使用率。
- 该线程处于 runnable 状态，表明它正在执行任务且没有等待或阻塞。
- 其他线程的 cpu 使用率都很低，几乎可以忽略不计。
### 2. 问题定位
问题的具体位置在 `cpuhighdemo` 类中，具体是第 12 行的代码：
```java
math.pow(math.random(), math.random());
这个无限循环的操作导致了 cpu 使用率飙升。
### 3. 根因分析
从反编译的代码可以看出，在主线程启动后创建了一个名为 `cpu-busy-thread` 的新线程。此线程执行一个无限循环，不断地调用 `math.pow(math.random(), math.random())` 方法。由于这是一个计算密集型操作，并且在无限循环中不断执行，因此会导致该线程持续占用大量的 cpu 资源，从而使得整个进程的 cpu 使用率达到接近 100% 的水平。
### 4. 解决方案
要解决这个问题，需要根据业务需求调整代码逻辑：
1. **如果是测试场景**：可以在循环中添加适当的休眠时间，例如使用 `thread.sleep(1)` 来降低cpu利用率。
2. **如果是生产环境**：应该检查是否有类似的死循环或者计算密集型任务未加控制地运行。
3. **长期优化**：对于长时间运行的任务，考虑将其放入线程池中执行，并设置合理的并发度以避免过度消耗系统资源。

public class deadlockdemo {
    private static final object locka = new object();
    private static final object lockb = new object();
    public static void main(string[] args) throws exception {
        system.out.println("pid: " + processhandle.current().pid());
        system.out.println("[deadlockdemo] 死锁场景启动...");
        // 线程 1：先获取 locka，再等待 lockb
        new thread(() -> {
            synchronized (locka) {              // ← 获取 locka
                try { thread.sleep(100); } catch (interruptedexception e) {}
                system.out.println("[thread-1] 已获取 locka，等待 lockb...");
                synchronized (lockb) {          // ← 等待 lockb（被 thread-2 持有）
                    system.out.println("[thread-1] 已获取 lockb");  // 永远不会执行
                }
            }
        }, "deadlock-thread-1").start();
        // 线程 2：先获取 lockb，再等待 locka
        new thread(() -> {
            synchronized (lockb) {              // ← 获取 lockb
                try { thread.sleep(100); } catch (interruptedexception e) {}
                system.out.println("[thread-2] 已获取 lockb，等待 locka...");
                synchronized (locka) {          // ← 等待 locka（被 thread-1 持有）
                    system.out.println("[thread-2] 已获取 locka");  // 永远不会执行
                }
            }
        }, "deadlock-thread-2").start();
        thread.currentthread().join();
    }
}

agent 开始自主诊断...
tool #1: thread
tool #2: thread
tool #3: jad
tool #4: jvm
tool #5: memory
tool #6: sysprop

### 1. 观察发现
通过使用 `thread -b` 命令检测到系统中存在死锁：
- 线程 `deadlock-thread-2` (id: 28) 被阻塞，等待获取锁 `java.lang.object@26d694600`，该锁被线程 `deadlock-thread-1` (id: 27) 持有。
- 线程 `deadlock-thread-1` (id: 27) 被阻塞，等待获取锁 `java.lang.object@26d65717`，该锁被线程 `deadlock-thread-2` (id: 28) 持有。
这形成了一个典型的循环依赖死锁。
进一步的 jvm 信息确认了这一点：
- `jvm` 命令输出显示 `deadlock-count` 为 2，证实了存在两个线程参与了死锁。
### 2. 问题定位
通过对 `deadlockdemo` 类进行反编译 (`jad` 命令)，我们找到了问题的具体位置：
- **类名**: `deadlockdemo`
- **涉及对象**:
  - `locka` (在代码第10行定义)
  - `lockb` (在代码第11行定义)
- **线程1** (`deadlock-thread-1`)：
  - 获取了 `locka` (第14行)
  - 尝试获取 `lockb` (第16行) 时被阻塞
- **线程2** (`deadlock-thread-2`)：
  - 获取了 `lockb` (第21行)
  - 尝试获取 `locka` (第23行) 时被阻塞
### 3. 根因分析
出现死锁的根本原因是两个线程以不同的顺序获取相同的两把锁：
1. 线程1首先获取 `locka`，然后尝试获取 `lockb`。
2. 线程2首先获取 `lockb`，然后尝试获取 `locka`。
由于两个线程都在等待对方释放自己所需的锁，而它们又都不释放自己已经持有的锁，因此造成了永久性的阻塞，即死锁。
这种经典的"交叉锁"问题是并发编程中最常见的死锁形式之一。
### 4. 解决方案
为了避免此类死锁的发生，可以采取以下几种策略：
#### 方案一：统一加锁顺序
确保所有线程都以相同的顺序获取锁。例如，在访问这两个资源时，总是先获取 `locka` 再获取 `lockb`。
#### 方案二：使用超时机制
使用 `java.util.concurrent.locks.reentrantlock` 的 `trylock(long timeout, timeunit unit)` 方法。
#### 方案三：使用高级并发工具
考虑使用 `java.util.concurrent` 包中的高级同步工具，如 `semaphore`、`countdownlatch` 或者 `blockingqueue`。

public class slowmethoddemo {
    public static void main(string[] args) throws exception {
        system.out.println("pid: " + processhandle.current().pid());
        system.out.println("[slowmethoddemo] 慢方法场景启动...");

        new thread(() -> {
            while (true) {
                doslowbusiness();  // ← 慢方法
                try { thread.sleep(1000); } catch (interruptedexception e) { break; }
            }
        }, "slow-method-thread").start();

        thread.currentthread().join();
    }

    // 慢方法：总耗时约 1 秒
    static void doslowbusiness() {
        step1();  // 200ms
        step2();  // 500ms
        step3();  // 300ms
    }

    static void step1() {
        try { thread.sleep(200); } catch (interruptedexception e) {}
    }

    static void step2() {
        try { thread.sleep(500); } catch (interruptedexception e) {}
    }

    static void step3() {
        try { thread.sleep(300); } catch (interruptedexception e) {}
    }
}

tool #1: thread

tool #2: jvm

tool #3: memory

tool #4: dashboard

tool #5: sc

tool #6: sm

tool #7: jad

tool #8: thread

tool #9: thread

### 1. 观察发现
通过一系列工具的综合分析，我们发现了以下关键信息：

- **线程状态**: `slow-method-thread` 线程处于 `timed_waiting` 状态，表明它正在执行一个定时等待操作。
- **cpu 使用**: 整体系统负载不高，没有明显的cpu瓶颈。
- **内存使用**: jvm 内存使用正常，gc活动较少，没有出现频繁full gc的情况。
- **代码结构**: 通过反编译 `slowmethoddemo` 类，我们看到了其主要逻辑结构，特别是 `doslowbusiness()` 方法及其调用的三个步骤方法。

### 2. 问题定位
具体的问题出现在 `slowmethoddemo` 类的 `step2()` 方法中。
- **类名**: `slowmethoddemo`
- **方法名**: `step2`
- **行号**: 第27行 (`thread.sleep(500l);`)

### 3. 根因分析
通过对 `slowmethoddemo` 的源码分析，我们发现该类模拟了一个慢速业务处理流程：
```java
static void doslowbusiness() {
    slowmethoddemo.step1(); // 耗时200ms
    slowmethoddemo.step2(); // 耗时500ms
    slowmethoddemo.step3(); // 耗时300ms
}

其中，`step2()` 方法包含了长达500毫秒的睡眠操作：

```java
static void step2() {
    try {
        thread.sleep(500l);
    } catch (interruptedexception e) {
        // empty catch block
    }
}
```
这个人为添加的延迟是导致整个业务接口响应时间超过1秒的主要原因。虽然这不是真实业务场景中的性能问题，但确实反映了在开发或测试环境中如何模拟慢速服务的一种常见做法。

### 4. 解决方案

针对这种情况，可以采取以下几种措施：
1. **如果是测试环境**: 可以根据需要调整延迟时间或者移除不必要的延迟。可以使用配置项来控制这些延迟。
2. **如果是生产环境问题**: 需要进一步分析 `step2()` 中实际执行的业务逻辑，找出真正的性能瓶颈点。
3. **通用优化建议**:
   - 将耗时操作分解为多个小任务并行处理
   - 引入缓存机制减少重复计算
   - 使用连接池管理数据库和网络连接
   - 定期进行性能压测和代码审查