写在文章开头

之前几篇文章笔者介绍arthas基础运维使用和线上问题技巧的使用，很多读者可能会感觉arthas指令记忆成本很高，好在市面上提供了一个不错的插件arthas idea，通过该插件我们即可快速基于现有项目代码段，生成线上排查指令。而本文也将从几个比较经典且常见的场景演示一下如何基于arthas idea快死生成排查指令快速完成java应用程序诊断。

因为这篇文章是完全基于arthas idea生成指令解决特定问题，所以，无论你是否先前是否具备arthas使用经验，都可以通过本文的学习，掌握arthas这款的工具的日常使用。

我是 SharkChili ，Java 开发者，Java Guide 开源项目维护者。欢迎关注我的公众号：写代码的SharkChili，也欢迎您了解我的开源项目 mini-redis：https://github.com/shark-ctrl/mini-redis (opens new window)。

为方便与读者交流，现已创建读者群。关注下方公众号获取我的联系方式，添加时备注加群即可加入。

准备工作

，在正式演示arthas idea前，读者务必到idea插件市场搜索并安装一下arthas命令生成插件arthas-idea：

同时，arthas idea也内置的下载arthas的快捷生成指令选项，我们只需右键选择install as.sh即可生成下载和启动指令：

我们将生成的指令粘贴到终端，对应指令如下图，可以看到该指令会通过curl完成下载，然后修改权限并将其启动，此时我们就可以通过进程的名称键入序号进入程序的管理：

详解arthas idea常见运维监控

查看类加载信息

没有插件之前我们查看某个类加载信息都需要手动编写sc命令，例如我们想查看TestController这个类元信息，有了arthas idea之后我们只需右键找到sc指令并点击：

最终就会生成如下指令，我们可以直接将该指令贴到

sc -d com.example.arthasExample.controller.TestController

此时arthas就会加载这个类的信息，通过输出结果就可以直观看到这个类各种元信息、继承关系、以及加载这个类的classLoader的hash码(重点，后续各种操作需要依赖这个类加载器唯一标识)：

需要补充的是，arthas idea给出的sc指令是相对基础的指令，如果我们想查看这个类的字段信息，可以补充一个参数-f(field)，以笔者为例，TestController存在如下字段：

private static int testVal = 2;

private static ExecutorService threadPool = Executors.newCachedThreadPool();

private Object lock1 = new Object();
private Object lock2 = new Object();

private static List<String> list = new ArrayList<>();

 @Autowired
private UserServiceImpl userService;

此时我们就可以基于arthas idea生成的指令基础上，添加一个-f指令：

c -d -f  com.example.arthasExample.controller.TestController

对应的输出结果如下，结合笔者的代码段可以字段是一一对应可印证的：

1. testVal为静态字段且值为2
2. 线程池当前线程数为0，并没有被使用
3. lock1和lock2两个锁变量是object类型
4. list为静态类型且没有添加任何元素：

查看静态变量实时动态变化

arhtas支持通过上一个示例中笔者提到一个静态的list，它会通过一个接口请求动态添加元素，对应代码如下所示：

private static List<String> list = new ArrayList<>();


    @RequestMapping("add")
    public void add() {
        for (int i = 0; i < 10; i++) {
            list.add("val" + i);
        }
    }

而arhtas是支持通过getstatic指令查看静态变量的实时变化，对应指令格式为getstatic class_name field_name选中字段之后，有了arthas idea之后，我们只需定位到list这个变量，通过右键点击get static field simple即可快速生成表达式：

于是我们就快速得出静态变量查询的指令：

getstatic com.example.arthasExample.controller.TestController list -x 3

对应输出结果如下，可以看到，在笔者通过接口请求动态元素后，通过arthas idea的指令是可以正确的观测到list的变化：

简单介绍这个指令后，笔者也就官方的说明做个科普，按照官网的说法，实际上对于静态变量的监控更推荐使用ongl表达式，因为该表达式比较复杂，所以在之前的文章中没有过多的展开，而本文是面向arhtas idea展开的，所以针对这个操作就可以更加详细直观的进行演示：

我们还是以list变量演示一下ongl表达式的使用，需要说明的是ongl表达式的参数是需要：

1. 执行表达式
2. 类加载器hashcode
3. 可选参数

按照笔者的使用经验，日常的spring boot指令用到的类加载器并非默认，所以我们的实践都是需要手动指定classloader的hash，所以笔者日常使用ongl表达式时的步骤都是：

1. 通过sc定位类加载器hash
2. 基于类加载器唯一hash通过arthas idea生成ongl表达式

所以本次的示例我们需要先通过arthas的sc获取到当前类的classLoader的哈希码，对应的操作还是针对这个类点击右键选择search classes loaded by jvm sc：

对应的指令和输出结果如下，可以看到classLoaderHash的结果为306a30c7，我们将其记录下文，后续会用到：

然后选中需要监控的字段list右键点击生成ongl表达式：

最后将之前得到的哈希码粘贴并点击copy command，后去list详情的ongl表达式就生成了：

最终表达式和结果如下，是不是很方便呢？

vmtool字段监控成员变量

arthas自持通过vmtool查询内存对象的信息，以下面这段代码为例，dateTimeStr这个字符串是跟随者接口请求而实时变化的，如果我们希望查看其及时数据就可以通过vmtool指令查阅：

 private String dateTimeStr = DateUtil.formatDateTime(new Date());

    @RequestMapping(value = "/getVal")
    public String getVal() {
        dateTimeStr = DateUtil.formatDateTime(new Date());
        return "success";
    }

对应指令生成步骤也是通过在对应字段即dateTimeStr右键选择vmtool get instance invoke method field：

然后传入上文留存的sc指令拿到的类加载器hash值，点击copy生成指令：

此时，我们就可以直观的看到成员变量的实时变化了：

方法执行情况监控

arhtas支持monitor指令进行方法监控，如下这段接口代码findUserById的示例，该接口设计id非法校验和查询(直接mock数据)，我们希望查询单位时间内这个方法的执行成功、失败、以及平均耗时等情况，也就是monitor监控指令，也可以直接通过插件快速生成：

  @GetMapping(value = {"/findUserById/{id}"})
    public JSONObject findUserById(@PathVariable Integer id) {
        log.info("id: {}", id);
        if (id != null && id < 2) {
            throw new IllegalArgumentException("id < 1");
        }
        //模拟查询返回数据
        return new JSONObject().putOnce("name", "user" + id).putOnce("age", 18);
    }

对应指令生成方式是在方法名称处右键点击monitor：

对应生成指令如下，可以看到，默认情况下，生成的指令为会执行10次，每10s进行一次输出：

monitor com.example.arthasExample.controller.TestController findUserById  -n 10  --cycle 10 

由此我们就可以实时且直观的监控到方法执行的成功、失败、平均耗时等参数信息：

运行耗时

之前的文章，我们介绍了trace命令，这个是定位接口耗时情况的有效武器，我们还是以下面这段代码为例,该接口要求传入用户id然后返回用户信息：

@GetMapping(value = "/user")
    public JSONObject queryUser(Integer uid) throws Exception {
        return userService.queryUser(uid);

    }

考虑到完整性我们给出queryUser的逻辑，其步骤比较简单：

1. 进行id校验，查看id是否是有效值。
2. 调用其他service。
3. 到redis缓存中查看是否有该用户信息。
4. 若步骤3没有结果，则调用MySQL查询。

public JSONObject queryUser(Integer uid) throws Exception {
        //入参校验
        check(uid);
        //调用其他service
        invokeOtherservice(uid);
        //redis查询
        JSONObject jsonObject = redis(uid);
        if (jsonObject != null) {
            return jsonObject;
        }
        //返回MySQL查询结果
        return mysql(uid);
    }

如果我们想定位这个接口的耗时情况，可以直接在service的query方法处右键点击插件找到trace选项生成对应trace指令：

此时我们就会得到下面这样一条指令，他给出了我们要追踪的类的全路径以及方法名，默认情况下n为5，即执行5次，然后skipJDKMethod为false即不跳过jdk方法的执行追踪：

trace com.example.arthasExample.service.UserServiceImpl queryUser  -n 5 --skipJDKMethod false 

此时我们就可以很直观的看到的最耗时的方法，可以看到最好是的位置是mysql即数据库持久化操作，由此我们就可以根据这个信息去针对性调优：

监控方法出入参

我们以上述接口的MySQL方法为例，我们希望通过watch查看出入参详情，对应方法内容如下：

public JSONObject mysql(Integer uid) throws Exception {
        log.info("查询MySQL数据......");
        TimeUnit.SECONDS.sleep(RandomUtil.randomInt(3, 4));
        JSONObject jsonObject = new JSONObject();
        jsonObject.putOnce("name", "xiaoming");
        jsonObject.putOnce("age", 18);
        return jsonObject;
    }

生成指令的步骤还是一样的，对准方法然后右键通过插件快捷生成指令：

默认情况下指令的会打印出入参和异常，然后执行次数为5，输出的结果属性的遍历深度为3，对应的指令和执行结果如下：

定位方法调用路径

我们日常用stack追踪方法调用堆栈，我们还是以mysql方法为例，通过插件快速生成：

生成的指令默认情况下会给出我们选中的类的全路径和方法名，默认执行5次：

stack com.example.arthasExample.service.UserServiceImpl mysql  -n 5

这样我们就可以快速的得到当前调用的堆栈信息，也就mysql方法调用的来时路：

获取方法具体出入参

watch 虽然很方便和灵活，但需要提前想清楚观察表达式的拼写，这对排查问题而言要求太高，因为很多时候我们并不清楚问题出自于何方，只能靠蛛丝马迹进行猜测。 这个时候如果能记录下当时方法调用的所有入参和返回值、抛出的异常会对整个问题的思考与判断非常有帮助。 于是乎，TimeTunnel 命令就诞生了。

下面我们就用check方法为例，来演示一下uid小于0时出入参和错误信息我们如何定位的：

private boolean check(Integer uid) throws Exception {
        if (uid == null || uid < 0) {
            log.error("非法用户id，uid:{}", uid);
            throw new Exception("非法用户id");
        }
        return true;
    }

首先通过插件点击tt指令

然后点击第一行复制这个指令，可以看到这个指令会指明我们要监控的类和方法，默认情况下执行5次：

查看监控结果可以看到，第3次执行报错：

查看索引为1003，所以我们键入tt -i 1003,此时我们就可以直观的看到入参和错误详情执行堆栈：

注意:tt 相关功能在使用完之后，需要手动释放内存，否则长时间可能导致OOM。退出 arthas 不会自动清除 tt 的缓存 map。

tt --delete-all

详解arthas idea快速快速定位线上故障

线程CPU使用率与线程定位

第一个场景就是功能编写不当导致线程CPU使用率飙升，笔者使用如下接口模拟这种情况并发起http请求：

@RequestMapping("cpu-100")
    public void cpu() {
        //无限循环输出打印
        new Thread(() -> {
            while (true) {
                log.info("cpu working");
            }
        }, "thread-1").start();
    }

随着请求结束后，系统逐渐卡顿，CPU使用率飙升，明确定位到当前Java进程后，我们就可以通过arthas的thread指令定位问题线程执行堆栈。以笔者为例，为了更加简单快速的看到问题线程，笔者直接通过thread -n 3打印出最忙碌的前3个线程。 此时，我们就可以看到TestController第36行的代码段CPU使用率非常高：

此时我们就可以通过反编译的方式进行36行实际的代码，在没有arhtas idea插件之前，我们jad指令都需要手动进行输入，有了idea插件之后，只需找到对应的java文件右键找到arthas command点击jad反编译即可生成指令

以笔者为例，本次通过快捷插件生成的指令为：

jad --source-only com.example.arthasExample.controller.TestController 

我们将生成的指令贴到arthas并执行，由此我们就可以精准定位到线上执行的java程序的问题代码段：

快速定位程序内存飙升

arthas可以说是定位这类疑难杂症的神奇，笔者将应用程序堆内存设置为128m启动：

java  -Xms128m -Xmx128m -jar arthasExample.jar

然后不断调用这个接口让每个线程threadlocal map填充4m的数组，让应用程序内存飙升：

@RequestMapping(value = "/oom")
    public String oom(HttpServletRequest request) {
        poolExecutor.execute(() -> {
            Byte[] c = new Byte[4 * 1024 * 1024];
            localVariable.set(c);// 为线程添加变量

        });
        return "success";
    }

随着时间推移，系统内存使用率飙升，明确定位到当前程序之后，先用memory指令观察一下程序当前的内存使用情况，可以看到堆内存使用率远超过业界设定的阈值即70%：

然后我们不断的请求该接口，随着时间推移，从dashboard中也直观看到这个，老年代在疯狂的gc平均一次gc耗时大约32ms，且单位时间内gc次数非常频繁：

此时我们就可以借助插件快速生成heapdump指令，导出该应用的内存快照：

从指令上看，默认情况下，内存快照会被dump到tmp目录下：

heapdump /tmp/dump.hprof

然后我们就可以通过MAT定位到出现问题的线程，点击with in incoming refrences查看这些对象被作为哪个对象的内部引用：

这里也补充说明一下Incomming Reference和Outgoing Reference 的区别：

Incomming Reference 指的是引用当前对象的对象，Outgoing Reference 指的是当前对象引用的对象。对象的incomming reference 保证对象处于 alive 从而免于被垃圾回收掉 ；Outgoing reference 则展示了对象内部的具体内容，有助于我们分析对象的属性 。

可以看到所有的byte数组都指向一个pool-3-thread开头的线程池，此时我们就可以基于本地开发代码定位对应的线程池了：

线上替换故障代码段

日常紧急需求上线难免会有些问题，这时候就需要保证服务不停机的情况下完成热点代码替换，可能大部分团队都会通过hotfix分支补丁结合灰度发布的方式完成紧急上线，实际上arthas是直接反编译修改代码完成热点替换的。

在正式介绍热点代码替换前，笔者还是需要有几个特殊说明：

1. 热点代码替换只支持已经加载的类，对于没有完成加载的类无法通过arthas完成替换
2. 完成替换后如果使用watch、trace等指令这个替换就会失效
3. 非必要不要在生产环境使用，存在风险

这里笔者就以下面这个接口为例，演示一下如何通过通过arthas 将id校验逻辑修改为小于0校验：

@GetMapping(value = {"/findUserById/{id}"})
    public JSONObject findUserById(@PathVariable Integer id) {
        log.info("id: {}", id);
        if (id != null && id < 2) {
            throw new IllegalArgumentException("id < 1");
        }
        return new JSONObject().putOnce("name", "user" + id).putOnce("age", 18);
    }

arthas热更新代码的步骤比较固定，大体分为三步：

1. jad反编译
2. mc编译生成字节码
3. redefine完成热点代码更新

有了arthas idea之后，这一切都无需我们操心，因为arthas idea内置了一个快捷指令，我们只需指明项目名称，并将修改的代码加以编译，即可通过快捷插件生成对应替换指令即可完成热点替换。

以上接口对应项目为例，笔者通过jps得知项目名称为com.example.arthasExample.ArthasExampleApplication，于是就在如下配置处选择手动配置项目名称：

完成功能代码修改后，点击编译生成最新字节码：

针对该代码右键点击选择refine，此时arthas idea就会针对这段代码生成一段指令完成：

1. 下载arhtas
2. select进入我们配置的项目
3. 将修改后的代码通过refine完成热更新

我们直接通过终端运行指令，可以看到arthas本质就是将修改后的字节码转为base64作为参数传入一个HotSwap脚本并执行完成热点代码更新：

这里笔者也给出生成的arthas-idea-plugin-hot-swap.sh的核心代码段，可以看到其本质就是select进程后，将我们修改后的base64字节码替换到运行进程的字节码完成动态加载更新：

此时我们执行curl就可以看到id为1的查询是正常的：

➜  github curl http://localhost:8848/findUserById/1
{"name":"user1","age":18}%

同时，基于边界值进行验证，可以发现日志打印输出的是小于0才抛出校验异常：

这里笔者仅仅演示了热更新中的最简单的剪切板替换，因为https://www.yuque.com/arthas-idea-plugin/help/pwxhb4#1vlwC (opens new window)

arthas idea进阶操作

基于arthas idea快速操纵spring容器上下文

我们都知道spring中有个上下文叫applicationContext，它记录着所有的bean的信息，通过该容器我们可以得到所有的bean进行各种操作。

这意味着如果我们在spring项目中如果有什么特殊的执行操作，完全可以通过tt定位到包含上下文的类，然后获取其applicationContext完成特殊操作。

举个例子,我们的TestController有一个方法findUserById，我们希望通过tt指令定位到这个bean对应的上下文applicationContext并完成对这个方法的调用：

@GetMapping(value = {"/user/{id}"})
    public JSONObject findUserById(@PathVariable Integer id) {
        log.info("id: {}", id);
        if (id != null && id < 2) {
            throw new IllegalArgumentException("id < 1");
        }
        return new JSONObject().putOnce("name", "user" + id).putOnce("age", 18);
    }

读过Spring MVC源码的读者可能都知道，每当有HTTP请求发送到web容器时请求进行映射转发处理时都会经过RequestMappingHandlerAdapter，从下面的类图不难看出它继承了WebApplicationObjectSupport，而该类有一个方法getWebApplicationContext可以让我们获取到spring容器的上下文，进而去分析管理spring容器：

所以我们通过插件生成RequestMappingHandlerAdapter的tt指令：

然后等待用户请求后，定位到这个类的执行记录，如下图对应1001索引就是笔者的请求：

基于这个索引对应的target，其实就是我们的RequestMappingHandlerAdapter，我们通过-w 像写java代码一样获取到applicationContext从而得到testController最终完成调用：

tt -i 1000 -w 'target.getApplicationContext().getBean("testController").findUserById(3)'

最终我们如愿完成了调用：

小结

本文笔者直接通过IDEA插件快速生成Arthas指令快速完成日常JVM运维和故障定位工作，可以看到有了插件的配合我们只需大概记住指令的作用即可，每当我们需要使用的时候，只需要结合插件生成一下指令进行相应简单调整即可快速得到想要的指令。

自此本文讲解结束，希望对你有帮助。

我是 SharkChili ，Java 开发者，Java Guide 开源项目维护者。欢迎关注我的公众号：写代码的SharkChili，也欢迎您了解我的开源项目 mini-redis：https://github.com/shark-ctrl/mini-redis (opens new window)。

为方便与读者交流，现已创建读者群。关注下方公众号获取我的联系方式，添加时备注加群即可加入。

参考

arthas 执行ognl表达式ClassNotFoundException:https://blog.csdn.net/w605283073/article/details/106535170 (opens new window)

arthas idea使用手册:https://www.yuque.com/arthas-idea-plugin (opens new window)

jvm参数配置:https://blog.csdn.net/wang379275614/article/details/78471604 (opens new window)

Java诊断神器Arthas：https://blog.csdn.net/sundehui01/article/details/121921481 (opens new window)

Java内存分析工具MAT(Memory Analyzer Tool)的介绍与使用:https://juejin.cn/post/7030664794843660302#heading-6 (opens new window)