工作六年，我学会了用 Arthas 来辅助我的日常工作 点击小卡片参与粉丝专属福利 工作六年，我学会了用 Arthas 来辅助我的日常工作很久就想写一篇介绍 Arthas 的文章，虽然 Arthas 已有大量文章介绍；但我依然想结合我的实际工作，来聊聊这款我喜爱的 Java 监控诊断产品。 ???一位 Java 开发者的使用总结，只谈使用经验，不聊原理。 ??? 那些辛酸的过往「历历在目的场景??」(?′??)(?′??) 客户线上问题，应该如何复现，让客户再点一下吗？异常被吃掉，手足无措，看是哪个家伙写的，竟然是自己！排查别人线上的 bug，不仅代码还没看懂，还没一行日志，捏了一把汗！预发 debug，稍微时间长点，群里就怨声载道！加日志重新部署，半个小时就没了，问题还没有找到，头顶的灯却早已照亮了整层楼......线上机器不能 debug，也不能开 debug 端口，重新部署会不会破坏现场呢?怀疑入参有问题，怀疑合并代码有问题，怀疑没有部署成功，全是问号......一个问题排查一天，被 Diss 排查问题慢......?直到我遇到了 Arthas，那些曾经束手无策的问题，都变得轻而易举。于是想把这些遇到的场景和用法做个总结。 ???一、通过命令执行方法--vmtool「vmtool 命令是我最喜欢用的，也是用最多的一个命令。通过这个命令执行方法，检查各种不符合预期的分支逻辑，入参出参，以及各种外部依赖接口，甚至还能修改数据等。」 1.1 场景解决过的场景具体描述发布导致线上的缓存 key 错误，需要清理，但过期时间还长，没有删除 key 的远程接口通过执行 service 方法，删除缓存 key；另外读取 redis 中的 key 也极其方便缺少日志，不知道上游是否返回数据合理通过执行方法，确定依赖返回数据不正确发布应用同时修改分布式配置，导致推送配置到该节点失败通过执行方法，查询配置信息不是最新常量值不符合预期，配置在 properties 中的免登 url 失效通过执行方法，查询当前常量值，判断读取不合理新增配置信息、删除脏数据通过接口执行方法，添加了配置、删除了脏数据集群环境，想要请求打在指定机器上查看日志需要反复请求多次才能命中特定机器查看日志，通过vmtool 执行方法，快速实现日志查看出参入参不符合预期在调用链路上执行所有可疑方法以前需要写 controller 调用触发的测试方法直接用这个命令，减少代码，还能测试上下游的各种二方接口，十分方便案例还有很多很多，因为真的可以拿着入参尽情的 invoke 提升了排查问题、解决问题的效率，也帮助其他人解决他们的问题。不再依赖打印大量日志反复部署服务，也不再申请 debug 端口进行远程 debug ，因为确实方便。 1.2 使用工欲善其事必先利其器，我在 IDEA 装上一个 Arthas 插件，用它来快速复制命令，想执行哪个方法拷贝即可。 ?上图是使用 Arthas 插件生成执行命令。光标放在执行方法上右击选择 vmtool 即可得到可运行命令。 ?「情景一：执行的方法是对象」：需要对参数对象赋值，以下图中的方法为例： queryIBCcContactConfig 方法参数是对象， 首先通过 Arthas 工具查找到参数 IbCcContactConfigParam 的「classLoaderHash」， 如下命令：（sc -d 路径） 对参数对象进行字段赋值,方式参考下面加粗部分（ognl方式）： ?vmtool -x 3 -c76707e36--actiongetInstances--classNamecom.xxx.impl.IbCcContactConfigServiceImpl--express'instances[0].queryIbCcContactConfig(「(#demo=newcom.xxx.param.IbCcContactConfigParam(),#demo.setContactBizCode('12345L'),#demo)」)' ?情景二、基础类型，比如String、Long、Int。直接填充数值即可 举例语句描述基础类型，比如String、Int、Long类型等vmtool -x 3 --action getInstances --className com.xxl.mq.admin.service.IXxlMqMessageService --express 'instances[0].delete(0)'执行 IXxlMqMessageService#delete 方法，参数为0 参数解释-x 3返回参数展开形式的，默认1，如果返回体是对象，建议设置3，方便观察返回结果-c xxx指定classLoaderHash，如果不指定，new 方法报错1.3 限制其一、尽量避开 ThreadLocal 。执行线程没有 ThreadLocal 的上下文； 其二、只能有一个端口，只支持一个arthas-server，用完及时关掉。 1.4 扩展使用 getstatic 命令查看静态变量 场景描述语句执行解释查看静态变量的实际值getstaticcom.xxx.xxx.interceptor.env.EnvIsolationInterceptorFILL_FIELD_NAME-x3查看 EnvIsolationInterceptor # FILL_FIELD_NAME 的静态变量值配置application.properties的免登 uri，发现没有生效getstaticcom.xxx.sso.filter.InitParamContextexcludeList-x3查看自己的免登 uri 是否在集合里面，从而快速定位问题修改静态变量值ognl -x 3 '#field=@com.xxl.mq.admin.conf.XxlMqBrokerImpl@class.getDeclaredField("ENV"),#field.setAccessible(true),#field.set(null," ")'???二、热部署 # redefine && retransform??「拍桌子拍大腿感叹发布的的代码少写或者漏写；拍脑门惋惜为啥不多打一行日志；口吐芬芳为什么把判断条件写死......，那些只能发布才能调试、部署一次要半小时的应用，真的会让生命变得廉价。」 2.1 场景解决过的场景描述加日志语句，入参出参观察联调查看参数将判断条件恒定成了 false，目标分支无法执行，阻塞进度修改判断逻辑漏写一行赋值代码对象自己赋值给自己，字段值为NULL研发、联调阶段，代码验证需要反复修改代码验证测试同学提Bug及时修复验证快速修复问题，不影响测试进度「热部署的优势用过的都说好」??。 2.2 使用IDEA 集成 ArthasHotSwap 插件，方便快捷： ?很多公司通过 API 方式已经集成了工具，定制化更好用??。 ?2.3 限制不允许新增加 field/method正在跑的函数，没有退出不能生效redefine 和 watch/trace/jad/tt 等命令冲突热部署能力，是一个很强大的能力，线上谨慎使用，属于高危操作。 ??三、OGNL && 条件过滤「顶流功能，可以使用 OGNL 解决很多复杂场景，其条件过滤属于绝佳。适用于 watch、trace、stack、monitor等，有大量请求、 for 场景等。」 3.1 场景条件过滤的适用场景实在太多，简单举例 解决过的场景描述想拦截特定参数值的方法入参出参，过滤其他参数请求只有特定参数才会被拦截，否则跳过，不影响其他人使用拦截特定参数，这个参数方法调用耗时长排查到了参数异常情况，特定账号数据量太大指定账号登录异常通过监控指定 userId 的调用栈，排查问题3.2 使用条件判断形式：形如 params[0]=="orgIdxxx726" （OGNL） 场景案例描述「watch 命令」：只监控特定组织的数据信息watchcom.xxx.controller.OrgServiceControllergetOrgInfo'{params,returnObj,throwExp}''params[0]=="orgIdxxx726"'-n5-x3通过“'「params[0]=="orgIdxxx726」"'”命令，判断只有当参数为“orgIdxxx726” watch 才生效「trace 命令」：只有特定组织的数据比较消耗时间tracecom.xxx.controller.OrgServiceControllergetOrgInfo'params[0]=="orgIdxxx726"'-n5--skipJDKMethodfalse查询只要特定组织耗时长，忽略其他参数，精准定位「stack 命令」：查看调用栈，非常适合代理调用、AOP、Filter等stackcom.xxx.controller.OrgServiceControllergetOrgInfo'params[0]=="orgIdxxx726"'-n5排查调用链路更多使用条件判断的案例如下 --判空 tracecom.xxx.controller.OrgServiceControllergetOrgInfo'params[0]!=null' --等于 trace*com.xxx.controller.OrgServiceControllergetOrgInfo'params[0]==1L' --字符串不等于 tracecom.xxx.controller.OrgServiceControllergetOrgInfo'params[1]!="AA"' OGNL 可以组合各种形式的条件判断。非常适合 watch、trace、stack 等场景。 3.3 扩展更多灵活的用法 ognl | arthas ?? 四、其他命令汇总4.1 logger在写代码的时候，也可以刻意加 log.debug 级别的日志。日志级别一般为 info ,当需要排查问题的时候，可以修改日志级别为 debug。 解决过的场景描述自定义日志失效，排查日志的实现类由哪个包引入或者提供排查间接引入的日志依赖包改变当前类的日志级别，查看日志将 info 级别修改成 debug 级别logger -n com.xxx.controller.OrgServiceControlle 通过sc 查看这个类的claasLoaderHash； logger --name ROOT --level debug -c 4839ebd 4.2 monitor监控某个方法的调用次数。包括调用次数，平均RT、成功率等信息。在性能调优使用： monitor com.XXXX.handler.HandlerManager process -n 10 --cycle 10 4.3 thread排查线程死锁，以及线程状态： 语句详细thread -b排查死锁情况，注意，当 Arthas 不能加载的时候，还是继续使用原来的 top 命令那一套排查问题thread -n 3查询当前最忙的 N 个线程4.4 jad 命令、反编译场景描述排查 jar 中的 class 文件加载是否符合预期。比如：突然发现某一台机器上的执行结果和其他的机器的结果不一致。怀疑机器部署异常依赖包冲突，加载类不符合预期或者支合并的时候出错检查运行的代码案例：springBoot 应用遇到 NoSuchMethodError 等问题，可以使用 Jad 反编译确认，看一下加载的类是否有问题。 4.5 watchwatch 用来查看入参出参，配合 OGNL 条件过滤非常实用： watch com.xxl.mq.admin.service.IXxlMqMessageService pageList '{params,returnObj,throwExp}' -n 5 -x 4 条件判断 #cost200(单位ms) 表示只有当耗时大于200ms才输出： watch demo... primeFactors '{params, returnObj}' '#cost200' -x 2 如果 x 设置超过 4 也就只展示4。使用 x=4 的情况比较常见，因为展开的信息最多。但需要注意线上数据量太大情况。 4.6 tt （Time Tunnel）tt 可以实现重做，实现方法调用；个人比较喜欢 vmtool，不过多介绍， tt 功能也十分强大。 4.7 用得不多的命令下面几个命令个人用得少，但很重要： 命令描述memory查看内存信息options全局开关，jvm 比较高级少用的命令sysprop / sysenv当前 JVM 的系统属性，环境属性profiler火焰图dashboard实时数据面板其他命令就不再赘述了??。 4.8 Arthas 插件功能Arthas 插件生成的命令如下： ?注：图片来源于 arthas 插件作者，插件和文章都很好?? ?针对插件的热部署配置详见：(Hot Swap) Redefine 热更新支持)；个人更推荐热部署用 ArthasHotSwap 插件。 ??五、一些限制 && 注意事项执行trace / tt 等命令时，本质上是在 method 的前后插入代码，会影响原来 JVM 里面 JIT 编译生成的代码。可能执行并发高的函数有抖动；只能有一个端口，只支持一个 arthas-server；热部署有限制且不一定能成功，线上属于高危操作；如果服务不能响应，可能 Arthas 不能启动使用，需要使用 Linux 相关命令排查问题。??六、好文推荐官网文档个人最推荐的学习资料：arthas idea plugin手册??七、最后的话??要成为 Arthas 使用的好手，一定多多练习：「纸上得来终觉浅，绝知此事要躬行」。 如果文章对你有帮助的话欢迎「关注+点赞+收藏」 阅读原文