阿里Arthas深度详解：从底层原理到生产实战，Java问题排查不再愁

果酱带你啃java

发布于 2026-04-14 13:50:09

890

在Java开发领域，线上问题排查一直是技术人的痛点——代码与线上运行逻辑不一致、CPU飙升找不到根源、内存泄漏定位困难、接口响应慢无从下手，传统调试工具要么需要重启应用，要么侵入性强，难以满足生产环境的高可用要求。而阿里巴巴开源的JVM诊断工具Arthas，凭借“无侵入式、动态增强、功能全面”的核心特性，成为解决这些问题的“神器”。本文将从底层原理出发，结合大量可直接运行的实战案例，全面拆解Arthas的核心功能与使用技巧，让你既能夯实底层基础，又能快速解决实际问题。

1. Arthas核心定位与解决的核心痛点

Arthas是阿里巴巴2018年开源的Java诊断工具，基于Java Instrumentation API和ASM字节码框架开发，支持JDK 6及以上版本，可运行在Linux、Mac、Windows等多种环境，兼容Spring Boot、Dubbo、Tomcat等主流Java框架。其核心定位是“运行时诊断”，无需修改代码、无需重启应用，即可实现对Java应用的动态监控、问题排查与热更新。

1.1 解决的核心痛点

线上代码与本地不一致，无法确认运行逻辑；
CPU利用率飙升、内存泄漏、死锁等问题难以定位；
接口响应慢，无法快速找到性能瓶颈；
生产环境无法直接调试，传统日志打印成本高、效率低；
紧急bug修复需重启应用，影响服务可用性。

1.2 核心优势

无侵入：无需修改应用代码，无需重启，直接附着到运行中的JVM进程；
动态增强：通过字节码增强技术实现方法插桩，实时监控与修改运行逻辑；
功能全面：覆盖类查询、方法监控、性能分析、JVM诊断、热更新等全场景；
易用性强：命令行交互支持Tab补全，语法简洁，文档完善；
可扩展：支持自定义命令插件，适配特殊业务场景。

2. Arthas环境准备与快速启动

2.1 环境要求

JDK版本：JDK 6+（推荐JDK 11+，本文基于JDK 17演示）；
操作系统：Linux/Mac/Windows（本文以Linux环境为例）；
网络：客户端与目标JVM进程需在同一网络（本地或局域网），支持远程附着（需配置端口）。

2.2 安装与启动步骤

2.2.1 下载Arthas

通过官方脚本快速下载最新稳定版（当前最新稳定版：3.7.6）：

# Linux/Mac环境
curl -O https://arthas.aliyun.com/arthas-boot.jar
# Windows环境直接访问链接下载：https://arthas.aliyun.com/arthas-boot.jar

2.2.2 启动Arthas并附着目标进程

# 启动arthas-boot.jar，自动识别当前运行的Java进程
java -jar arthas-boot.jar
# 输入进程对应的序号（如1、2），即可附着到目标JVM进程

启动成功后，将进入Arthas交互控制台，显示如下信息：

[INFO] arthas-boot version: 3.7.6
[INFO] Found existing java process, please choose one and input the serial number of the process, eg : 1. Then hit ENTER.
* [1]: 12345 com.jam.demo.ArthasDemoApplication
  [2]: 67890 org.apache.catalina.startup.Bootstrap
1
[INFO] Attach process 12345 success.
[INFO] arthas home: /root/.arthas/lib/3.7.6/arthas
[INFO] The target process already loaded arthas-agent, skip install.
[INFO] Arthas server already started on port 3658, let's connect it...
,---.  ,------. ,--------.,--.  ,--.  ,---.   ,---.
/  O  \ |  .--. ''--.  .--'|  '--'  | /  O  \ '   .-'
|  .-.  ||  '--'.'   |  |   |  .--.  ||  .-.  |`.  `-.
|  | |  ||  |\  \    |  |   |  |  |  ||  | |  |.-'    |
`--' `--'`--' '--'   `--'   `--'  `--'`--' `--'`-----'

2.2.3 基础命令验证

进入控制台后，可通过以下命令验证环境是否正常：

# 查看Arthas版本
version
# 查看当前附着的进程信息
process
# 查看帮助文档
help

2.3 远程连接配置（可选）

若需远程连接目标JVM进程，需在启动时指定端口：

# 目标进程所在机器启动Arthas，指定IP和端口（0.0.0.0表示允许所有IP访问）
java -jar arthas-boot.jar --host 0.0.0.0 --port 3658 12345
# 本地机器通过telnet/ssh连接
telnet 目标机器IP 3658
# 或通过arthas-client连接
java -jar arthas-client.jar 目标机器IP 3658

3. Arthas核心原理基础：Java Instrumentation与Attach机制

要理解Arthas的工作原理，必须先掌握两个核心技术：Java Instrumentation API和JVM Attach机制。这两个技术是Arthas实现“无侵入式诊断”的基础。

3.1 Java Instrumentation API

Java Instrumentation（简称Instrument）是JDK 5引入的一套API，允许外部程序在JVM运行时修改类的字节码，实现对类的增强。其核心能力包括：

注册字节码转换器（ClassFileTransformer），在类加载时或运行时修改字节码；
重定义已加载的类（redefineClasses），实现类的热更新；
获取JVM中已加载的所有类信息、内存使用情况等。

3.1.1 Instrument核心接口

Instrument的核心是java.lang.instrument.Instrumentation接口，关键方法如下：

/**
 * 注册字节码转换器，后续所有类加载都会经过该转换器
 * @param transformer 自定义的字节码转换器
 * @param canRetransform 是否支持重新转换（true表示可重复修改）
 */
void addTransformer(ClassFileTransformer transformer, boolean canRetransform);

/**
 * 重定义已加载的类，替换类的字节码
 * @param definitions 类定义数组，包含类对象和新的字节码
 * @throws ClassNotFoundException 类未找到
 * @throws UnmodifiableClassException 类无法修改（如final类）
 */
void redefineClasses(ClassDefinition... definitions) throws ClassNotFoundException, UnmodifiableClassException;

/**
 * 获取JVM中已加载的所有类
 * @return 已加载类的数组
 */
Class<?>[] getAllLoadedClasses();

3.1.2 Instrument工作流程

3.2 JVM Attach机制

JVM Attach机制是JDK提供的一种进程间通信能力，允许一个Java进程（如Arthas客户端）附着到另一个运行中的Java进程（目标应用），并加载代理程序（agent）。其核心类是com.sun.tools.attach.VirtualMachine。

3.2.1 Attach机制核心流程

3.2.2 关键注意事项

Attach机制依赖JDK工具包中的tools.jar（JDK 9+已模块化，需引入模块依赖）；
附着进程与目标进程需运行在同一用户下，或拥有足够的权限（如root）；
部分JVM（如嵌入式JVM）可能不支持Attach机制。

3.3 Arthas核心原理整合

Arthas的工作原理本质是“Attach机制注入代理 + Instrumentation实现字节码增强”的组合，整体流程如下：

4. Arthas核心架构解析

Arthas采用“客户端-服务端”架构，分为三大核心模块：客户端、服务端、代理端，各模块职责清晰，协同工作实现诊断功能。

4.1 架构图

4.2 各模块核心职责

4.2.1 客户端

提供命令行交互界面，接收用户输入的命令；
与服务端建立TCP连接，发送命令并接收返回结果；
支持命令补全、历史记录、结果格式化展示。

4.2.2 服务端

运行在目标JVM进程中，接收客户端命令；
解析命令，生成对应的字节码增强策略；
协调代理端完成字节码修改和数据采集；
将采集到的数据格式化后返回客户端。

4.2.3 代理端

基于Instrumentation API实现，是字节码增强的核心；
注册ClassFileTransformer，根据服务端指令修改目标类字节码；
采集方法执行数据（如入参、出参、耗时、异常）；
支持类重定义、类卸载等核心操作。

4.3 通信机制

Arthas客户端与服务端通过TCP协议通信，默认端口3658，采用自定义的消息格式：

消息头：包含消息长度、类型、状态码；
消息体：命令内容或返回结果（JSON格式）；
支持心跳检测，确保连接稳定性。

5. Arthas核心能力预热：字节码增强技术详解

字节码增强是Arthas所有核心功能（如监控、追踪、热更新）的基础。Arthas底层采用ASM框架操作字节码，相比Javassist等框架，ASM更高效、轻量，直接操作字节数组，无反射开销。

5.1 字节码增强核心概念

5.1.1 字节码与Class文件结构

Java源码编译后生成Class文件，Class文件是一组8字节的二进制流，包含类的基本信息（类名、父类、接口）、字段信息、方法信息、常量池等。字节码增强本质是修改Class文件中的方法体指令，实现插桩逻辑。

5.1.2 ASM框架核心作用

ASM框架提供了一套API，可直接读取、修改、生成Class文件的字节码，核心类包括：

ClassReader：读取Class文件的字节码，解析为抽象语法树；
ClassWriter：根据抽象语法树生成修改后的字节码；
ClassVisitor：遍历抽象语法树，在指定位置插入自定义指令（如方法入口、出口）。

5.1.3 插桩方式分类

Arthas支持两种核心插桩方式：

前置插桩：在方法执行前插入监控逻辑（如记录开始时间、入参）；
后置插桩：在方法执行后（正常返回或抛出异常）插入逻辑（如记录结束时间、计算耗时、收集出参/异常）。

5.1.4 字节码增强示例（简化版）

以下是一个简化的ASM插桩示例，实现方法耗时统计（Arthas监控命令的底层核心逻辑）：

package com.jam.demo.arthas.asm;

import org.objectweb.asm.ClassReader;
import org.objectweb.asm.ClassVisitor;
import org.objectweb.asm.ClassWriter;
import org.objectweb.asm.MethodVisitor;
import org.objectweb.asm.Opcodes;

/**
 * 字节码增强工具类，为方法添加耗时统计
 * @author ken
 */
publicclass TimeCostTransformer {

    /**
     * 增强指定类的指定方法，添加耗时统计
     * @param className 类名（全限定名）
     * @param methodName 方法名
     * @param originalBytes 原始类字节码
     * @return 增强后的类字节码
     */
    publicstaticbyte[] enhance(String className, String methodName, byte[] originalBytes) {
        // 1. 读取原始字节码
        ClassReader classReader = new ClassReader(originalBytes);
        ClassWriter classWriter = new ClassWriter(ClassWriter.COMPUTE_FRAMES);
        // 2. 创建自定义ClassVisitor，遍历类结构
        ClassVisitor classVisitor = new ClassVisitor(Opcodes.ASM9, classWriter) {
            @Override
            public MethodVisitor visitMethod(int access, String name, String descriptor, String signature, String[] exceptions) {
                MethodVisitor mv = super.visitMethod(access, name, descriptor, signature, exceptions);
                // 只增强目标方法
                if (name.equals(methodName)) {
                    returnnew MethodVisitor(Opcodes.ASM9, mv) {
                        @Override
                        public void visitCode() {
                            // 前置插桩：记录开始时间
                            mv.visitFieldInsn(Opcodes.GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;");
                            mv.visitLdcInsn("方法开始执行");
                            mv.visitMethodInsn(Opcodes.INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V", false);
                            mv.visitMethodInsn(Opcodes.INVOKESTATIC, "java/lang/System", "currentTimeMillis", "()J", false);
                            mv.visitVarInsn(Opcodes.LSTORE, 1);
                            super.visitCode();
                        }

                        @Override
                        public void visitInsn(int opcode) {
                            // 后置插桩：计算耗时（正常返回时）
                            if (opcode == Opcodes.RETURN || opcode == Opcodes.ARETURN || opcode == Opcodes.IRETURN) {
                                mv.visitMethodInsn(Opcodes.INVOKESTATIC, "java/lang/System", "currentTimeMillis", "()J", false);
                                mv.visitVarInsn(Opcodes.LLOAD, 1);
                                mv.visitInsn(Opcodes.LSUB);
                                mv.visitVarInsn(Opcodes.LSTORE, 3);

                                mv.visitFieldInsn(Opcodes.GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;");
                                mv.visitLdcInsn("方法执行耗时：");
                                mv.visitMethodInsn(Opcodes.INVOKEVIRTUAL, "java/io/PrintStream", "print", "(Ljava/lang/String;)V", false);
                                mv.visitVarInsn(Opcodes.LLOAD, 3);
                                mv.visitMethodInsn(Opcodes.INVOKEVIRTUAL, "java/io/PrintStream", "println", "(J)V", false);
                            }
                            super.visitInsn(opcode);
                        }
                    };
                }
                return mv;
            }
        };
        // 3. 遍历并修改字节码
        classReader.accept(classVisitor, ClassReader.EXPAND_FRAMES);
        // 4. 返回修改后的字节码
        return classWriter.toByteArray();
    }
}

5.1.5 字节码增强关键约束

不能修改类的结构（如新增字段、方法，修改方法参数/返回值类型），否则会抛出UnsupportedOperationException；
不支持修改final类、final方法（JVM限制）；
增强逻辑需保证线程安全，避免使用非线程安全的共享变量；
增强后的字节码需符合JVM规范，否则会导致类加载失败。

5.2 动态字节码增强实现流程

Arthas的核心能力依赖动态字节码增强技术，其底层基于Java Instrumentation API（JDK 5+引入）和ASM字节码操作框架，通过“Attach机制注入代理 -> 注册ClassFileTransformer -> 重定义目标类”的流程实现无侵入式监控。以下是详细实现流程和原理拆解：

5.2.1 字节码增强核心流程（flowchart TD）

5.2.2 关键技术组件解析

Java Attach API：允许外部进程（Arthas客户端）附着到目标JVM进程，核心类为com.sun.tools.attach.VirtualMachine，通过attach(pid)方法建立连接，再通过loadAgent(agentJarPath)注入代理。
Instrumentation API：代理程序的核心接口，提供addTransformer(ClassFileTransformer)注册字节码转换器，redefineClasses(ClassDefinition...)触发类重定义，支持在类加载时或运行时修改字节码。
ClassFileTransformer接口：字节码转换的核心接口，通过实现transform(ClassLoader loader, String className, Class<?> classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer)方法，对目标类的字节码进行修改后返回。
ASM框架：轻量级字节码操作库，直接操作Class文件的字节数组，相比Javassist更高效（无反射开销），Arthas通过ASM实现方法插桩（如在方法入口/出口添加监控逻辑）。

5.2.3 实战：动态修改方法逻辑（字节码增强实例）

以下通过“修改用户服务的getUserById方法，添加耗时统计和日志输出”为例，演示Arthas字节码增强的实际效果：

步骤1：编写原始服务类（符合阿里开发手册规范）

package com.jam.demo.arthas.service;

import com.jam.demo.arthas.entity.User;
import com.jam.demo.arthas.mapper.UserMapper;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;
import org.springframework.util.ObjectUtils;

import javax.annotation.Resource;

/**
 * 用户服务类
 * @author ken
 */
@Slf4j
@Service
publicclass UserService {

    @Resource
    private UserMapper userMapper;

    /**
     * 根据用户ID查询用户信息
     * @param userId 用户ID（非空）
     * @return 用户实体
     * @throws IllegalArgumentException 当userId为空时抛出
     */
    public User getUserById(Long userId) {
        // 入参校验（符合阿里开发手册：入参非空校验）
        if (ObjectUtils.isEmpty(userId)) {
            thrownew IllegalArgumentException("用户ID不能为空");
        }
        log.info("开始查询用户信息，用户ID：{}", userId);
        // 模拟业务耗时（实际场景为数据库查询）
        try {
            Thread.sleep(200);
        } catch (InterruptedException e) {
            log.error("查询用户信息时线程中断", e);
            Thread.currentThread().interrupt();
        }
        return userMapper.selectById(userId);
    }
}

步骤2：启动应用并验证原始逻辑

应用启动后，通过接口调用getUserById(1L)，日志输出如下：

2024-05-20 14:30:00.123  INFO 12345 --- [nio-8080-exec-1] c.j.d.arthas.service.UserService        : 开始查询用户信息，用户ID：1

步骤3：使用Arthas动态增强方法（添加耗时统计）

启动Arthas并附着到目标进程：

# 启动Arthas（最新稳定版3.7.2）
java -jar arthas-boot.jar
# 选择目标进程（输入对应序号）

反编译UserService类，确认方法结构：

jad com.jam.demo.arthas.service.UserService getUserById

编写修改后的字节码逻辑（添加耗时统计），创建UserServiceEnhanced.java：

package com.jam.demo.arthas.service;

import com.jam.demo.arthas.entity.User;
import com.jam.demo.arthas.mapper.UserMapper;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;
import org.springframework.util.ObjectUtils;

import javax.annotation.Resource;

/**
 * 用户服务类（Arthas增强版）
 * @author ken
 */
@Slf4j
@Service
publicclass UserService {

    @Resource
    private UserMapper userMapper;

    public User getUserById(Long userId) {
        // 增强逻辑：添加耗时统计
        long start = System.currentTimeMillis();
        try {
            if (ObjectUtils.isEmpty(userId)) {
                thrownew IllegalArgumentException("用户ID不能为空");
            }
            log.info("开始查询用户信息，用户ID：{}", userId);
            try {
                Thread.sleep(200);
            } catch (InterruptedException e) {
                log.error("查询用户信息时线程中断", e);
                Thread.currentThread().interrupt();
            }
            return userMapper.selectById(userId);
        } finally {
            long cost = System.currentTimeMillis() - start;
            log.info("查询用户信息结束，用户ID：{}，耗时：{}ms", userId, cost);
        }
    }
}

编译增强类（需指定classpath，确保依赖可用）：

# 编译命令（需JDK17环境，指定依赖包路径）
javac -cp "arthas-boot.jar:spring-boot-starter.jar:lombok-1.18.30.jar:mybatis-plus-boot-starter.jar:${CLASSPATH}" com/jam/demo/arthas/service/UserServiceEnhanced.java

使用redefine命令加载增强后的字节码：

# 重定义类（替换原始UserService）
redefine com/jam/demo/arthas/service/UserServiceEnhanced.class

验证增强效果：再次调用getUserById(1L)，日志输出如下（新增耗时统计）：

2024-05-20 14:35:00.456  INFO 12345 --- [nio-8080-exec-2] c.j.d.arthas.service.UserService        : 开始查询用户信息，用户ID：1
2024-05-20 14:35:00.658  INFO 12345 --- [nio-8080-exec-2] c.j.d.arthas.service.UserService        : 查询用户信息结束，用户ID：1，耗时：202ms

5.2.4 字节码增强注意事项

类结构兼容性：重定义类时，不能修改类的结构（如新增字段、方法，修改方法参数/返回值类型），仅能修改方法体逻辑，否则会抛出UnsupportedOperationException。
线程安全：增强逻辑需保证线程安全，避免在方法中使用非线程安全的共享变量。
性能开销：字节码增强会带来少量性能开销（如插桩逻辑的执行），生产环境建议仅在排查问题时启用，问题解决后立即卸载代理。
热更新限制：redefine命令不支持修改final方法、static方法（部分JVM版本），且修改后的类不会持久化到磁盘，应用重启后失效。

6. Arthas核心命令实战（按功能分类）

Arthas提供了数十个命令，覆盖类查询、方法监控、性能分析、JVM诊断等场景。以下是生产环境最常用的核心命令，结合实例详细讲解其用法、底层原理和最佳实践：

6.1 类相关命令（ jad/sc/sm ）

6.1.1 jad：反编译类

功能：将已加载的类反编译为Java代码，支持指定方法名，用于查看类的实际运行逻辑（解决“代码与线上不一致”问题）。
底层原理：通过Class.getResourceAsStream(".class")获取类的字节码，再通过ASM框架反编译为Java代码。
语法：jad [选项] 类名 [方法名]
选项：
- -c <classLoaderHash>：指定类加载器（多个类加载器加载同一类时使用）
- -E：开启正则表达式匹配方法名
实例：

# 反编译UserService类的所有方法
jad com.jam.demo.arthas.service.UserService

# 仅反编译getUserById方法
jad com.jam.demo.arthas.service.UserService getUserById

# 当存在多个类加载器时，指定类加载器（通过sc命令获取hash值）
jad -c 1b6d3586 com.jam.demo.arthas.service.UserService

6.1.2 sc：搜索已加载的类

功能：搜索JVM中已加载的类，支持模糊匹配，可查看类的加载器、实例数等信息。
底层原理：通过Instrumentation.getAllLoadedClasses()获取所有已加载类，再根据条件过滤。
语法：sc [选项] 类名表达式
选项：
- -d：显示详细信息（类加载器、父类、接口、实例数等）
- -f：显示类的字段信息
- -m：显示类的方法信息
- -c <classLoaderHash>：指定类加载器
实例：

# 搜索所有包含User的类（模糊匹配）
sc *User*

# 查看UserService的详细信息（包括类加载器）
sc -d com.jam.demo.arthas.service.UserService

# 查看UserService的字段和方法信息
sc -f -m com.jam.demo.arthas.service.UserService

6.1.3 sm：查看方法信息

功能：查看类的方法列表及签名，支持指定方法名模糊匹配。
底层原理：通过Class.getDeclaredMethods()获取类的所有方法，解析方法的访问修饰符、参数类型、返回值类型。
语法：sm [选项] 类名 [方法名表达式]
选项：
- -d：显示详细信息（方法签名、访问修饰符、异常类型等）
- -E：开启正则表达式匹配方法名
实例：

# 查看UserService的所有方法
sm com.jam.demo.arthas.service.UserService

# 查看getUserById方法的详细签名
sm -d com.jam.demo.arthas.service.UserService getUserById

6.2 方法监控命令（ monitor/watch/trace ）

6.2.1 monitor：方法执行监控

功能：统计方法的执行次数、成功次数、失败次数、平均耗时、最大耗时等指标，支持指定监控周期。
底层原理：通过字节码增强在方法入口和出口插桩，记录方法执行开始时间、结束时间、异常状态，周期性汇总统计结果。
语法：monitor [选项] 类名方法名
选项：
- -c <周期>：指定监控周期（单位：秒，默认10秒）
- -b：监控方法调用前的参数
- -e：监控方法抛出的异常
实例：监控UserService.getUserById方法，每5秒输出一次统计结果

# 监控getUserById方法，周期5秒
monitor -c 5 com.jam.demo.arthas.service.UserService getUserById

输出结果说明：

 timestamp           class                          method       total  success  fail  avg(ms)  max(ms)
-----------------------------------------------------------------------------------------------
 2024-05-20 15:00:05  com.jam.demo.arthas.service.UserService  getUserById  3      2        1    205      300

字段含义：total（总调用次数）、success（成功次数）、fail（失败次数）、avg(ms)（平均耗时）、max(ms)（最大耗时）。

6.2.2 watch：方法入参/出参/异常监控

功能：实时观察方法的入参、出参、返回值、异常信息，支持条件过滤（如仅监控入参为特定值的请求）。
底层原理：字节码增强在方法入口记录入参，在方法出口记录返回值，在异常抛出点记录异常信息，通过OGNL表达式解析并展示数据。
语法：watch [选项] 类名方法名表达式 [条件表达式]
核心选项：
- -x <深度>：指定对象展开深度（默认1，如-x 2展开对象的二级属性）
- -b：在方法调用前触发（仅显示入参）
- -e：在方法抛出异常时触发（仅显示异常）
- -s：在方法返回时触发（仅显示返回值）
- -f：在方法调用前后都触发（显示入参+返回值）
OGNL表达式说明：
- params：方法入参数组（如params[0]表示第一个参数）
- returnObj：方法返回值
- throwExp：方法抛出的异常对象
- target：当前实例对象
- args：同params，兼容旧版本
实例1：监控方法入参和返回值

# 观察getUserById的入参和返回值，对象展开深度2
watch -x 2 -f com.jam.demo.arthas.service.UserService getUserById "{'userId':params[0], 'result':returnObj}"

输出结果：

method=com.jam.demo.arthas.service.UserService.getUserById location=before
args=[1]
returnObj=null
expression={"userId":1, "result":null}
--------------------------------------
method=com.jam.demo.arthas.service.UserService.getUserById location=after
args=[1]
returnObj=User(id=1, username="zhangsan", age=25, email="zhangsan@example.com")
expression={"userId":1, "result":{"id":1, "username":"zhangsan", "age":25, "email":"zhangsan@example.com"}}

实例2：条件过滤（仅监控userId=1的请求）

# 仅当第一个参数等于1时，显示入参和返回值
watch -x 2 -f com.jam.demo.arthas.service.UserService getUserById "{'userId':params[0], 'result':returnObj}" "params[0]==1"

实例3：监控方法抛出的异常

# 观察方法抛出的异常信息，对象展开深度3
watch -x 3 -e com.jam.demo.arthas.service.UserService getUserById "{'userId':params[0], 'exception':throwExp}"

6.2.3 trace：方法调用链路追踪

功能：追踪方法的调用链路，展示每个子方法的执行耗时，用于定位方法内部的性能瓶颈（如“哪个子方法耗时最长”）。
底层原理：字节码增强在方法的每个子方法调用前后插桩，记录子方法的执行时间，最终生成调用链路耗时树。
语法：trace [选项] 类名方法名 [条件表达式]
核心选项：
- -d <深度>：指定调用链路深度（默认5，避免递归调用导致栈溢出）
- -n <次数>：指定追踪次数（如-n 3仅追踪3次调用）
- -E：开启正则表达式匹配方法名
实例：追踪getUserById的调用链路

# 追踪getUserById的调用链路，显示每个子方法耗时，仅追踪2次调用
trace -n 2 com.jam.demo.arthas.service.UserService getUserById

输出结果说明：

`---ts=2024-05-20 15:10:00;thread_name=nio-8080-exec-3;id=10;is_daemon=true;priority=5;TCCL=org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedWebappClassLoader@1b6d3586
    `---[205ms] com.jam.demo.arthas.service.UserService:getUserById()
        `---[0ms] org.springframework.util.ObjectUtils:isEmpty()
        `---[1ms] lombok.extern.slf4j.Slf4j:info()
        `---[200ms] java.lang.Thread:sleep()
        `---[3ms] com.jam.demo.arthas.mapper.UserMapper:selectById()

结果中[205ms]表示总耗时，子方法耗时之和等于总耗时，可快速定位到Thread.sleep()是耗时瓶颈。

6.3 性能分析命令（ profiler/heapdump/jvm ）

6.3.1 profiler：生成性能分析火焰图

功能：基于AsyncProfiler（无采样偏差的性能分析工具），生成CPU、内存、锁等维度的火焰图，直观展示性能瓶颈。
底层原理：通过JVM的AsyncGetCallTrace接口获取方法调用栈，基于采样机制（默认10ms采样一次）统计方法的CPU占用率，最终生成SVG格式的火焰图。
语法：profiler [选项] [命令]
核心命令：
- start：开始性能分析（默认CPU维度）
- stop：停止分析并生成火焰图
- status：查看分析状态
- list：列出支持的分析维度
核心选项：
- -d <时长>：指定分析时长（单位：秒，如-d 60分析60秒）
- -e <事件>：指定分析事件（如cpu、alloc（内存分配）、lock（锁竞争））
- -o <格式>：指定输出格式（默认svg，支持html、jfr）
实例1：生成CPU火焰图（排查CPU飙升问题）

# 开始CPU分析，持续60秒
profiler start -d 60

# 60秒后停止分析，生成火焰图（默认保存到arthas-output目录）
profiler stop

火焰图解读：
- 横轴：方法的CPU占用时间（越长表示占用CPU越多）
- 纵轴：方法调用栈（从上到下是调用关系，最底层是被调用的方法）
- 颜色：无特殊含义，仅用于区分不同方法
- 核心结论：找到横轴最长的“火焰”，其对应的方法即为CPU占用最高的瓶颈方法。
实例2：生成内存分配火焰图（排查内存泄漏）

# 分析内存分配情况，持续30秒，输出SVG格式
profiler start -d 30 -e alloc -o svg

# 停止分析并生成火焰图
profiler stop

6.3.2 heapdump：导出堆内存快照

功能：导出JVM堆内存快照（.hprof文件），用于分析内存泄漏、大对象占用等问题。
底层原理：通过HotSpotDiagnosticMXBean.dumpHeap(filePath, live)接口导出堆快照，live=true表示仅导出存活对象（过滤垃圾对象，减小快照体积）。
语法：heapdump [选项] 输出文件路径
选项：
- -live：仅导出存活对象（推荐生产环境使用，减少文件大小）
- -format=b：指定输出格式为二进制（默认，兼容MAT等分析工具）
实例：

# 导出存活对象的堆快照到/tmp目录
heapdump -live /tmp/arthas-heap-20240520.hprof

后续分析：使用MAT（Memory Analyzer Tool）或JProfiler打开.hprof文件，分析大对象、内存泄漏疑点（如未释放的线程池、静态集合）。

6.3.3 jvm：查看JVM运行状态

功能：查看JVM的基本信息（进程ID、JDK版本、虚拟机名称）、内存使用情况、线程状态、类加载统计等。
底层原理：通过JMX的ManagementFactory获取JVM的各种MXBean（如MemoryMXBean、ThreadMXBean、ClassLoadingMXBean），汇总并展示关键指标。
语法：jvm
实例输出（核心部分）：

JAVA_HOME: /usr/local/jdk-17.0.11
JVM Version: 17.0.11+9-LTS-194
JVM Vendor: Oracle Corporation
JVM Name: OpenJDK 64-Bit Server VM
Input Arguments: -Xms2g -Xmx2g -XX:+UseG1GC
...
Memory Usage:
heap            used  [786.4MB]  total  [1.2GB]  max  [1.8GB]  usage[43.7%]
non-heap        used  [256.3MB]  total  [272.0MB]  max  [--]  usage[94.2%]
...
Thread Count: 56 (DAEMON: 48, NON-DAEMON: 8)
Peak Thread Count: 62
...
Class Loading:
loadedClassCount: 12345
totalLoadedClassCount: 12345
unloadedClassCount: 0

6.4 热更新命令（ redefine/retransform ）

6.4.1 redefine：重定义类（热更新）

功能：加载修改后的字节码文件，替换JVM中已加载的类，实现无重启热更新（仅支持修改方法体）。
底层原理：通过Instrumentation.redefineClasses(ClassDefinition...)方法，将新的字节码替换旧的类定义，JVM会重新加载类并更新所有实例的方法逻辑。
语法：redefine <class文件路径> [多个class文件]
注意事项：
- 不能修改类的结构（字段、方法签名、继承关系），仅能修改方法体。
- 不支持final类、final方法、static方法（部分JVM版本）。
- 热更新后的类不会持久化到磁盘，应用重启后失效。
实例：热更新UserService类（见5.2.3节实例）

6.4.2 retransform：类转换（支持修改类结构）

功能：与redefine类似，但支持修改类结构（如新增方法、字段），但需配合自定义的ClassFileTransformer，使用门槛较高。
语法：retransform <class文件路径>
使用场景：仅在特殊场景下使用（如紧急修复需要新增方法的bug），生产环境建议优先使用redefine。

6.5 线程诊断命令（ thread/jstack ）

6.5.1 thread：查看线程状态

功能：查看JVM中所有线程的状态（RUNNABLE、BLOCKED、WAITING、TIMED_WAITING）、CPU占用率、调用栈等，用于排查线程阻塞、死锁等问题。
底层原理：通过ThreadMXBean获取线程信息，包括线程ID、名称、状态、CPU时间、调用栈等。
语法：thread [选项] [线程ID]
核心选项：
- -n <数量>：显示CPU占用率最高的前N个线程
- -b：查找阻塞其他线程的线程（死锁或锁竞争场景）
- -i <间隔>：指定刷新间隔（单位：秒，如-i 2每2秒刷新一次）
- -state <状态>：过滤指定状态的线程（如-state BLOCKED仅显示阻塞线程）
实例1：查看CPU占用最高的前3个线程

thread -n 3

输出结果：

THREAD ID: 10 | NAME: nio-8080-exec-3 | STATE: RUNNABLE | CPU%: 90.5 | TIME: 120s
THREAD ID: 12 | NAME: AsyncTaskExecutor-1 | STATE: RUNNABLE | CPU%: 8.2 | TIME: 30s
THREAD ID: 8 | NAME: GC Thread#0 | STATE: RUNNABLE | CPU%: 1.3 | TIME: 5s

实例2：查找阻塞线程的根源

thread -b

输出结果（死锁场景）：

Found one blocking thread:
THREAD ID: 15 | NAME: OrderService-Thread-1 | STATE: BLOCKED
Blocked on: com.jam.demo.arthas.service.OrderService@12345678
Blocked by thread: 16 (PaymentService-Thread-1)
Call Stack:
com.jam.demo.arthas.service.OrderService.processOrder(OrderService.java:50)
com.jam.demo.arthas.service.OrderService$1.run(OrderService.java:20)

THREAD ID: 16 | NAME: PaymentService-Thread-1 | STATE: BLOCKED
Blocked on: com.jam.demo.arthas.service.PaymentService@87654321
Blocked by thread: 15 (OrderService-Thread-1)
Call Stack:
com.jam.demo.arthas.service.PaymentService.processPayment(PaymentService.java:30)
com.jam.demo.arthas.service.PaymentService$1.run(PaymentService.java:15)

结论：线程15和16相互持有对方需要的锁，导致死锁。

6.5.2 jstack：导出线程栈快照

功能：导出所有线程的调用栈快照到文件，用于离线分析线程问题（如生产环境无法实时连接Arthas时）。
语法：jstack [选项] 输出文件路径
选项：
- -F：强制导出（当JVM无响应时使用）
- -l：显示锁相关信息（推荐使用）
实例：

jstack -l /tmp/arthas-thread-20240520.txt

7. 生产环境问题排查实战（3个经典案例）

以下结合生产环境高频问题，完整演示如何使用Arthas排查并解决问题，覆盖CPU飙升、内存泄漏、接口响应慢3类场景，每个案例包含“问题现象->排查步骤->解决方案->优化效果”全流程。

7.1 案例1：CPU飙升问题排查（死循环导致）

7.1.1 问题现象

生产环境应用CPU使用率持续高达95%以上，应用响应缓慢，监控告警触发。

7.1.2 排查步骤

定位CPU高占用进程：通过top命令找到CPU占用最高的Java进程（PID：12345）。

top -p 12345

启动Arthas并附着到目标进程：

java -jar arthas-boot.jar 12345

查找CPU高占用线程：使用thread -n 1命令找到CPU占用最高的线程（THREAD ID：10）。

thread -n 1

输出结果：

THREAD ID: 10 | NAME: ProductSync-Thread-1 | STATE: RUNNABLE | CPU%: 98.7 | TIME: 3600s

查看线程调用栈：使用thread 10命令查看线程10的调用栈，定位到具体方法。

thread 10

输出结果（核心部分）：

Call Stack:
com.jam.demo.arthas.service.ProductSyncService.syncProductData(ProductSyncService.java:45)
com.jam.demo.arthas.service.ProductSyncService$1.run(ProductSyncService.java:25)
java.lang.Thread.run(Thread.java:833)

反编译目标方法：使用jad命令反编译syncProductData方法，查看逻辑是否存在死循环。

jad com.jam.demo.arthas.service.ProductSyncService syncProductData

反编译结果（问题代码）：

public void syncProductData() {
    List<Product> productList = productMapper.selectAll();
    int i = 0;
    // 问题：循环条件错误（i < productList.size() 写成了 i > productList.size()）
    while (i > productList.size()) {
        Product product = productList.get(i);
        syncToEs(product);
        i++;
    }
}

验证死循环：使用watch命令监控方法执行，确认循环是否无限执行。

watch -n 1 com.jam.demo.arthas.service.ProductSyncService syncProductData "{'i':target.i, 'listSize':params[0].size()}"

输出结果：{'i':0, 'listSize':1000}（i始终为0，循环条件永远成立，导致死循环）。

7.1.3 解决方案

修复循环条件：将i > productList.size()改为i < productList.size()。
使用redefine命令热更新修复后的类，无需重启应用。

# 编译修复后的类
javac -cp "arthas-boot.jar:spring-boot-starter.jar:mybatis-plus-boot-starter.jar:${CLASSPATH}" com/jam/demo/arthas/service/ProductSyncService.java

# 热更新
redefine com/jam/demo/arthas/service/ProductSyncService.class

7.1.4 优化效果

CPU使用率从98.7%降至5%以下。
应用响应时间恢复正常（接口平均响应时间从5000ms降至200ms）。

7.2 案例2：内存泄漏问题排查（静态集合未清理）

7.2.1 问题现象

应用运行一段时间后（约24小时），出现OOM（OutOfMemoryError），堆内存使用率持续上升，无法自动回收。

7.2.2 排查步骤

查看JVM内存状态：使用jvm命令查看堆内存使用情况，发现老年代内存使用率高达99%。

jvm

输出结果：

Memory Usage:
heap            used  [1.7GB]  total  [1.8GB]  max  [1.8GB]  usage[94.4%]
  eden_space     used  [200MB]  total  [300MB]  max  [300MB]  usage[66.7%]
  survivor_space used  [30MB]   total  [30MB]   max  [30MB]   usage[100%]
  old_gen        used  [1.5GB]  total  [1.5GB]  max  [1.5GB]  usage[99.8%]

导出堆内存快照：使用heapdump命令导出存活对象的堆快照。

heapdump -live /tmp/arthas-heap-oom.hprof

分析堆快照（MAT工具）：
- 打开MAT工具，导入arthas-heap-oom.hprof文件。
- 执行“Leak Suspects”分析，发现com.jam.demo.arthas.service.UserCacheService类的static List<User>集合占用了1.2GB内存，且集合大小持续增长。
查看目标类逻辑：使用jad命令反编译UserCacheService类，定位内存泄漏点。

jad com.jam.demo.arthas.service.UserCacheService

反编译结果（问题代码）：

@Service
public class UserCacheService {
    // 问题：静态集合未清理，所有查询的用户对象都被缓存，无法回收
    private static final List<User> USER_CACHE = Lists.newArrayList();

    /**
     * 查询用户并缓存到静态集合
     */
    public List<User> queryAllUser() {
        List<User> userList = userMapper.selectList(null);
        USER_CACHE.addAll(userList); // 只添加不清理，导致集合无限增长
        return userList;
    }
}

监控集合大小变化：使用watch命令监控USER_CACHE的大小，确认是否持续增长。

watch com.jam.demo.arthas.service.UserCacheService queryAllUser "{'cacheSize':target.USER_CACHE.size()}"

输出结果：每次调用后cacheSize均增加（如从1000→2000→3000），确认内存泄漏。

7.2.3 解决方案

修复缓存逻辑：将静态集合改为带过期时间的缓存（如使用Caffeine缓存），避免无限增长。
引入Caffeine依赖（Maven）：

<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.1.8</version> <!-- 最新稳定版 -->
</dependency>

重构UserCacheService类：

package com.jam.demo.arthas.service;

import com.github.benmanes.caffeine.cache.Caffeine;
import com.github.benmanes.caffeine.cache.LoadingCache;
import com.jam.demo.arthas.entity.User;
import com.jam.demo.arthas.mapper.UserMapper;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;
import javax.annotation.Resource;
import java.util.List;
import java.util.concurrent.TimeUnit;

/**
 * 用户缓存服务（修复内存泄漏）
 * @author ken
 */
@Slf4j
@Service
publicclass UserCacheService {

    @Resource
    private UserMapper userMapper;

    // 缓存配置：过期时间1小时，最大容量10000
    privatefinal LoadingCache<String, List<User>> USER_CACHE = Caffeine.newBuilder()
            .expireAfterWrite(1, TimeUnit.HOURS)
            .maximumSize(10000)
            .build(key -> userMapper.selectList(null));

    /**
     * 查询用户（带过期缓存）
     */
    public List<User> queryAllUser() {
        return USER_CACHE.get("allUser");
    }
}

热更新修复后的类（或重启应用，生产环境建议灰度发布）。

7.2.4 优化效果

堆内存使用率稳定在40%左右，无OOM问题。
老年代内存回收正常，缓存自动过期清理。

7.3 案例3：接口响应慢问题排查（数据库索引缺失）

7.3.1 问题现象

用户查询接口/api/user/query响应时间长达3-5秒，远超正常阈值（500ms），监控显示接口P99延迟过高。

7.3.2 排查步骤

监控接口对应的方法耗时：使用monitor命令监控UserService.queryUserByCondition方法（接口对应的服务方法）。

monitor -c 3 com.jam.demo.arthas.service.UserService queryUserByCondition

输出结果：方法平均耗时3200ms，成功次数100，失败次数0。

追踪方法调用链路：使用trace命令查看方法内部子调用的耗时分布。

trace -n 5 com.jam.demo.arthas.service.UserService queryUserByCondition

输出结果：

`---[3200ms] com.jam.demo.arthas.service.UserService:queryUserByCondition()
    `---[0ms] org.springframework.util.StringUtils:hasText()
    `---[3198ms] com.jam.demo.arthas.mapper.UserMapper:selectByCondition()
    `---[2ms] com.google.common.collect.Lists:newArrayList()

结论：UserMapper.selectByCondition()方法耗时占比99.9%，是性能瓶颈。

查看Mapper方法的SQL：使用jad命令反编译UserMapper接口，获取SQL语句。

jad com.jam.demo.arthas.mapper.UserMapper selectByCondition

反编译结果（MyBatis-Plus XML）：

<select id="selectByCondition" resultType="com.jam.demo.arthas.entity.User">
    SELECT id, username, age, email FROM user WHERE age = #{age} AND status = #{status}
</select>

分析SQL执行计划：在MySQL中执行EXPLAIN分析SQL，确认是否缺少索引。

EXPLAIN SELECT id, username, age, email FROM user WHERE age = 25 AND status = 1;

执行结果：type=ALL（全表扫描），key=NULL（未使用索引），rows=100000（扫描10万行数据）。

验证索引缺失：使用watch命令查看SQL的查询条件和扫描行数（需结合MyBatis-Plus的日志）。

watch -x 2 com.jam.demo.arthas.mapper.UserMapper selectByCondition "{'age':params[0].age, 'status':params[0].status}"

输出结果：查询条件为age=25、status=1，扫描行数10万+，确认全表扫描导致响应慢。

7.3.3 解决方案

为user表添加联合索引（覆盖查询条件）：

ALTER TABLE `user` ADD INDEX idx_age_status (age, status); -- MySQL 8.0支持

验证索引效果：再次执行EXPLAIN，确认使用索引。

EXPLAIN SELECT id, username, age, email FROM user WHERE age = 25 AND status = 1;

执行结果：type=ref（索引查找），key=idx_age_status（使用新增索引），rows=100（扫描100行数据）。

监控方法耗时变化：使用monitor命令再次监控，确认性能提升。

monitor -c 3 com.jam.demo.arthas.service.UserService queryUserByCondition

输出结果：方法平均耗时从3200ms降至80ms，满足性能要求。

7.3.4 优化效果

接口响应时间从3-5秒降至80ms以内。
P99延迟从4.5秒降至150ms，满足业务需求。

8. Arthas高级特性与最佳实践

8.1 自定义Arthas命令（基于Arthas Plugin）

Arthas支持通过插件机制扩展自定义命令，满足特殊业务场景的监控需求（如自定义指标统计、业务日志采集）。以下是自定义命令的开发步骤：

8.1.1 环境准备（Maven依赖）

<dependencies>
    <!-- Arthas核心依赖 -->
    <dependency>
        <groupId>com.taobao.arthas</groupId>
        <artifactId>arthas-core</artifactId>
        <version>3.7.2</version>
        <scope>provided</scope>
    </dependency>
    <!-- Arthas命令API -->
    <dependency>
        <groupId>com.taobao.arthas</groupId>
        <artifactId>arthas-common</artifactId>
        <version>3.7.2</version>
        <scope>provided</scope>
    </dependency>
    <!-- Lombok -->
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.30</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

8.1.2 自定义命令实现（统计用户订单数）

package com.jam.demo.arthas.plugin;

import com.taobao.arthas.core.command.CommandProcess;
import com.taobao.arthas.core.command.annotation.Command;
import com.taobao.arthas.core.command.annotation.Option;
import com.taobao.arthas.core.command.parser.CommandLine;
import com.taobao.arthas.core.shell.cli.Completion;
import com.taobao.arthas.core.shell.cli.CompletionUtils;
import com.taobao.arthas.core.util.ClassLoaderUtils;
import com.taobao.arthas.core.util.ThreadUtils;
import lombok.extern.slf4j.Slf4j;
import org.springframework.util.CollectionUtils;

import java.lang.reflect.Method;
import java.util.List;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

/**
 * 自定义Arthas命令：统计指定用户的订单数
 * @author ken
 */
@Slf4j
@Command(name = "count-order", description = "统计指定用户的订单数")
publicclass CountOrderCommand extends com.taobao.arthas.core.command.AbstractCommand {

    @Option(name = "-u", longName = "username", required = true, description = "用户名")
    private String username;

    @Option(name = "-c", longName = "classLoader", description = "类加载器Hash值")
    private String classLoaderHash;

    privatefinal Map<String, Integer> orderCountCache = new ConcurrentHashMap<>();

    @Override
    public void execute(CommandProcess process) {
        try {
            // 1. 获取类加载器
            ClassLoader classLoader = ClassLoaderUtils.getClassLoaderByHash(classLoaderHash);
            if (classLoader == null) {
                classLoader = Thread.currentThread().getContextClassLoader();
            }

            // 2. 加载OrderService类
            Class<?> orderServiceClass = classLoader.loadClass("com.jam.demo.arthas.service.OrderService");

            // 3. 获取Spring容器中的OrderService实例（假设使用Spring上下文）
            Class<?> applicationContextClass = classLoader.loadClass("org.springframework.context.ApplicationContext");
            Method getApplicationContextMethod = classLoader.loadClass("org.springframework.web.context.ContextLoader")
                    .getMethod("getCurrentWebApplicationContext");
            Object applicationContext = getApplicationContextMethod.invoke(null);
            Object orderService = applicationContextClass.getMethod("getBean", Class.class)
                    .invoke(applicationContext, orderServiceClass);

            // 4. 调用OrderService的countOrderByUsername方法
            Method countMethod = orderServiceClass.getMethod("countOrderByUsername", String.class);
            Integer orderCount = (Integer) countMethod.invoke(orderService, username);

            // 5. 缓存结果并输出
            orderCountCache.put(username, orderCount);
            process.write(String.format("用户名：%s，订单数：%d%n", username, orderCount));
        } catch (Exception e) {
            log.error("统计订单数失败", e);
            process.write("统计失败：" + e.getMessage() + "\n");
        } finally {
            process.end();
        }
    }

    @Override
    public void complete(Completion completion) {
        CommandLine commandLine = completion.commandLine();
        if (commandLine.isOptionCompleted("-u") && commandLine.isOptionCompleted("-c")) {
            // 自动补全用户名（假设从数据库查询）
            List<String> usernames = Lists.newArrayList("zhangsan", "lisi", "wangwu");
            CompletionUtils.completeCandidates(completion, usernames);
        }
    }
}

8.1.3 打包与部署

将自定义命令打包为JAR文件（如arthas-count-order-plugin.jar）。
将JAR文件放入Arthas的plugins目录（默认~/.arthas/plugins）。
启动Arthas，即可使用自定义命令：

# 统计用户zhangsan的订单数
count-order -u zhangsan

8.2 Arthas生产环境最佳实践

权限控制：Arthas附着到目标进程需要root或目标进程所属用户权限，生产环境建议创建专用用户，避免使用root。
安全防护：
- 限制Arthas客户端的访问IP（通过防火墙或网络策略）。
- 启用Arthas的认证功能（--username和--password参数）。
- 问题排查完成后，立即执行stop命令卸载代理，避免残留。
性能影响控制：
- 避免长时间启用trace、watch等插桩命令（会增加CPU和内存开销）。
- 使用profiler时，建议设置较短的采样时长（如30-60秒），避免影响应用性能。
日志管理：Arthas的日志默认保存在~/.arthas/logs目录，生产环境建议定期清理日志文件，避免磁盘空间占用过高。
版本选择：使用最新稳定版（如3.7.2），避免使用测试版，确保兼容性和稳定性。

8.3 常见问题与解决方案

问题现象	解决方案
无法附着到目标进程（Attach failed）	1. 确认目标进程的PID正确；2. 确认当前用户有目标进程的访问权限；3. 确认目标JVM版本与Arthas兼容（JDK 6+）；4. 关闭目标进程的安全管理器（若启用）。
反编译类失败（Decompile failed）	1. 确认类名正确（包含完整包名）；2. 确认类已被JVM加载（通过sc命令验证）；3. 若类被混淆，反编译结果可能不完整。
热更新失败（Redefine failed）	1. 检查修改后的类是否与原始类结构兼容（仅修改方法体）；2. 确认类未被final修饰；3. 确认JVM支持类重定义（部分嵌入式JVM可能不支持）。
火焰图生成失败	1. 确认目标JVM支持AsyncProfiler（JDK 8+）；2. 检查磁盘空间是否充足；3. 避免在高负载场景下长时间采样。