Arthas：问题排查神器，满满的骚操作，这些功能赶紧学起来

场景 1：定位压测时的性能瓶颈

平时服务器请求都很正常。压测时，依赖的服务、数据库也都没有到达瓶颈，但是机器的 CPU 全部飘红，why？

通过 jstack 命令，只能看到某一时刻的堆栈，没有抓到真凶。

thread 查看当前线程信息，查看线程的堆栈。

thread -n 3 -i 10000 可以统计 10 秒内最忙的 3 个线程，并且打印它们的堆栈，很容易发现问题。最终发现的问题比较简单：日志中打印了 location 的信息，包括 类名、方法名和行号。

动态获取代码的方法名、行号等信息，通常是通过 new Throwable() -> 打印 Throwable 的堆栈 -> 截取堆栈中最顶层的业务代码 -> 拆分字符串获取类、方法、行号等信息, 打印堆栈对性能损耗是比较大的。

场景 2：检测偶发的超时

有段时间，总是碰到几次偶尔的超时，但是看日志都正常，鹰眼的调用链路都完全 ok，没有哪一步数据库操作或者 HSF 调用是特别慢的。

各种监控统计的时间维度的耗时，都十分正常，无法找到那个 rt 的尖刺。

想到了可能是日志的问题，但是没有证据支撑。

trace 命令能监控每一步的耗时，并且可以配合条件表达式，当耗时超过 xx ms 时打印详细日志。

找台机器，输入命令，后面的就是静等了。再次出现 rt 尖刺时，能够捕捉到耗时的分布情况。

通过 Arthas 拿到的结果，定位到是日志打印的问题。同步日志改为异步日志后，问题解决。

场景3：debug？那要是动态字节码生成咋办？

之前碰到过一个 json 序列化时输出的数字带不带引号的问题。当时各种 debug、看代码，发现是通过 ASM 动态字节码的方式生成的序列化类。到这完全放弃了，debug 已经无法定位问题了。当时通过另外一种方式避免了这种问题。

反过来看这个问题的时候，我们可以通过 Arthas 的 jad 命令，反编译动态字节码生成的类，结合 watch 等命令，定位排查问题。

jad——反编译指定已加载类的源码

还可以通过 mc(menory compiler), redefine 命令线上热更新代码，欢迎探索。

有了这些能力就算万能了？不不，接着往下看。

场景 4：搞点事情

在问题排查过程中，发现了日志输出到了控制台，这个对性能的损耗是比较大的。有什么办法，在不发布的情况下紧急解决它？

首先找到对应的 class：

sc -d ch.qos.logback.core.ConsoleAppender

class-info ch.qos.logback.core.ConsoleAppender
code-source /home/admin/…/lib/logback-core-1.2.3.jar
name
ch.qos.logback.core.ConsoleAppender
isInterface false
isAnnotation false
isEnum false
isAnonymousClass false
isArray false
isLocalClass false
isMemberClass false
isPrimitive false
isSynthetic false
simple-name ConsoleAppender
modifier public
annotation
interfaces
super-class ±ch.qos.logback.core.OutputStreamAppender
±ch.qos.logback.core.UnsynchronizedAppenderBase
±ch.qos.logback.core.spi.ContextAwareBase
±java.lang.Object
class-loader ±com.taobao…LaunchedURLClassLoader@58dad04a
±sun.misc.Launcher$AppClassLoader@18b4aac2+-sun.misc.Launcher$ExtClassLoader@58ceff1
classLoaderHash 5f205aa

然后获取 class 的属性信息，找到 appender 列表：

ognl -c 5f205aa ‘@org.slf4j.LoggerFactory@getLogger(“root”).aai.appenderList’

删除标准输出的 appender：

1ognl -c 5f205aa ‘@org.slf4j.LoggerFactory@getLogger(“root”).aai.appenderList.remove(0)’

l -c 5f205aa ‘@org.slf4j.LoggerFactory@getLogger(“root”).aai.appenderList.remove(0)’