curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar
arithas> thread -b  # 檢測死鎖
arithas> dashboard  # 查看系統(tǒng)概況
arithas> trace com.example.MyClass myMethod  # 追蹤方法調(diào)用

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

# 直接獲得結(jié)構(gòu)化數(shù)據(jù)
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          # 綁定所有網(wǎng)卡，允許遠程訪問
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 年以上的生產(chǎn)環(huán)境排查經(jīng)驗。
## 當前診斷目標
{class_name} - {desc}
## 診斷原則
1. **觀察驅(qū)動**：首先觀察系統(tǒng)的整體狀態(tài)（JVM、線程、內(nèi)存），形成初步假設
2. **工具優(yōu)先級**：
   - 簡單查詢工具優(yōu)先（thread、jvm、memory、dashboard）
   - 如需流式工具（trace、monitor、watch），注意可能受認證限制
   - 使用 jad 反編譯源碼來理解代碼邏輯
3. **多角度驗證**：結(jié)合多個工具的結(jié)果交叉驗證，避免誤判
4. **根因?qū)?*：不只找到現(xiàn)象，要深入分析根本原因
5. **解決建議**：給出可操作的解決方案
## Arthas 工具速查
- `thread` / `thread -n 3` - 查看線程列表/CPU 最高線程
- `thread -b` - 檢測死鎖
- `thread <id>` - 查看特定線程的詳細堆棧
- `jvm` - JVM 運行時信息
- `memory` - 內(nèi)存使用情況
- `dashboard` / `dashboard -i 2000` - 系統(tǒng)概況/定期監(jiān)控
- `jad <ClassName>` - 反編譯類代碼
- `sysprop` - 系統(tǒng)屬性
- `logger` - 日志配置
## 認證說明
注意：部分流式工具（trace、monitor、watch）可能需要額外的會話認證。
如果遇到 401 錯誤，請改用其他工具組合（如 thread + jad）來達到同樣的診斷目標。
## 輸出要求
請按照以下格式輸出診斷結(jié)果：
1. **觀察發(fā)現(xiàn)**：通過工具看到的異?，F(xiàn)象
2. **問題定位**：問題的具體位置（類名、方法名、行號）
3. **根因分析**：為什么會出現(xiàn)這個問題
4. **解決方案**：具體的修復建議
開始診斷吧！
"""

# 3. 創(chuàng)建 MCP Client 和 Agent（使用通用系統(tǒng)提示詞）
arthas_mcp = MCPClient(
    lambda: streamablehttp_client(
        url="http://localhost:9999/mcp",
        headers={"Authorization": "Bearer S2TotROqw5zmTxxxxxpatPIJogSAX0v"}
    )
)
# 構(gòu)建通用系統(tǒng)提示詞
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飆高場景啟動...");
        // 創(chuàng)建一個死循環(huán)線程，執(zhí)行密集計算
        new Thread(() -> {
            while (true) {
                // 密集計算操作（冪運算）
                Math.pow(Math.random(), Math.random());
            }
        }, "cpu-busy-thread").start();  // ← 關(guān)鍵：線程名稱
        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. 觀察發(fā)現(xiàn)
通過使用 `dashboard` 和 `thread -n 5` 命令觀察到以下異?，F(xiàn)象：
- 線程 `cpu-busy-thread` (ID 27) 占用了高達 99.97% 的 CPU 使用率。
- 該線程處于 RUNNABLE 狀態(tài)，表明它正在執(zhí)行任務且沒有等待或阻塞。
- 其他線程的 CPU 使用率都很低，幾乎可以忽略不計。
### 2. 問題定位
問題的具體位置在 `CpuHighDemo` 類中，具體是第 12 行的代碼：
```java
Math.pow(Math.random(), Math.random());
這個無限循環(huán)的操作導致了 CPU 使用率飆升。
### 3. 根因分析
從反編譯的代碼可以看出，在主線程啟動后創(chuàng)建了一個名為 `cpu-busy-thread` 的新線程。此線程執(zhí)行一個無限循環(huán)，不斷地調(diào)用 `Math.pow(Math.random(), Math.random())` 方法。由于這是一個計算密集型操作，并且在無限循環(huán)中不斷執(zhí)行，因此會導致該線程持續(xù)占用大量的 CPU 資源，從而使得整個進程的 CPU 使用率達到接近 100% 的水平。
### 4. 解決方案
要解決這個問題，需要根據(jù)業(yè)務需求調(diào)整代碼邏輯：
1. **如果是測試場景**：可以在循環(huán)中添加適當?shù)男菝邥r間，例如使用 `Thread.sleep(1)` 來降低CPU利用率。
2. **如果是生產(chǎn)環(huán)境**：應該檢查是否有類似的死循環(huán)或者計算密集型任務未加控制地運行。
3. **長期優(yōu)化**：對于長時間運行的任務，考慮將其放入線程池中執(zhí)行，并設置合理的并發(fā)度以避免過度消耗系統(tǒng)資源。

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");  // 永遠不會執(zhí)行
                }
            }
        }, "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");  // 永遠不會執(zhí)行
                }
            }
        }, "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. 觀察發(fā)現(xiàn)
通過使用 `thread -b` 命令檢測到系統(tǒng)中存在死鎖：
- 線程 `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) 持有。
這形成了一個典型的循環(huán)依賴死鎖。
進一步的 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. 根因分析
出現(xiàn)死鎖的根本原因是兩個線程以不同的順序獲取相同的兩把鎖：
1. 線程1首先獲取 `lockA`，然后嘗試獲取 `lockB`。
2. 線程2首先獲取 `lockB`，然后嘗試獲取 `lockA`。
由于兩個線程都在等待對方釋放自己所需的鎖，而它們又都不釋放自己已經(jīng)持有的鎖，因此造成了永久性的阻塞，即死鎖。
這種經(jīng)典的"交叉鎖"問題是并發(fā)編程中最常見的死鎖形式之一。
### 4. 解決方案
為了避免此類死鎖的發(fā)生，可以采取以下幾種策略：
#### 方案一：統(tǒng)一加鎖順序
確保所有線程都以相同的順序獲取鎖。例如，在訪問這兩個資源時，總是先獲取 `lockA` 再獲取 `lockB`。
#### 方案二：使用超時機制
使用 `java.util.concurrent.locks.ReentrantLock` 的 `tryLock(long timeout, TimeUnit unit)` 方法。
#### 方案三：使用高級并發(fā)工具
考慮使用 `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. 觀察發(fā)現(xiàn)
通過一系列工具的綜合分析，我們發(fā)現(xiàn)了以下關(guān)鍵信息：

- **線程狀態(tài)**: `slow-method-thread` 線程處于 `TIMED_WAITING` 狀態(tài)，表明它正在執(zhí)行一個定時等待操作。
- **CPU 使用**: 整體系統(tǒng)負載不高，沒有明顯的CPU瓶頸。
- **內(nèi)存使用**: JVM 內(nèi)存使用正常，GC活動較少，沒有出現(xiàn)頻繁Full GC的情況。
- **代碼結(jié)構(gòu)**: 通過反編譯 `SlowMethodDemo` 類，我們看到了其主要邏輯結(jié)構(gòu)，特別是 `doSlowBusiness()` 方法及其調(diào)用的三個步驟方法。

### 2. 問題定位
具體的問題出現(xiàn)在 `SlowMethodDemo` 類的 `step2()` 方法中。
- **類名**: `SlowMethodDemo`
- **方法名**: `step2`
- **行號**: 第27行 (`Thread.sleep(500L);`)

### 3. 根因分析
通過對 `SlowMethodDemo` 的源碼分析，我們發(fā)現(xiàn)該類模擬了一個慢速業(yè)務處理流程：
```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
    }
}
```
這個人為添加的延遲是導致整個業(yè)務接口響應時間超過1秒的主要原因。雖然這不是真實業(yè)務場景中的性能問題，但確實反映了在開發(fā)或測試環(huán)境中如何模擬慢速服務的一種常見做法。

### 4. 解決方案

針對這種情況，可以采取以下幾種措施：
1. **如果是測試環(huán)境**: 可以根據(jù)需要調(diào)整延遲時間或者移除不必要的延遲?？梢允褂门渲庙梺砜刂七@些延遲。
2. **如果是生產(chǎn)環(huán)境問題**: 需要進一步分析 `step2()` 中實際執(zhí)行的業(yè)務邏輯，找出真正的性能瓶頸點。
3. **通用優(yōu)化建議**:
   - 將耗時操作分解為多個小任務并行處理
   - 引入緩存機制減少重復計算
   - 使用連接池管理數(shù)據(jù)庫和網(wǎng)絡連接
   - 定期進行性能壓測和代碼審查