01

引言

1.1背景

性能优化是一个Java程序员的必备技能，但是定位性能瓶颈或者是问题点是一个费时又费力的事情。在我们的实际项目中就碰到了这样的烦恼，某业务的一个接口，平均耗时很短，但是总有约1%的流量，波动较大。多次review代码，并没有发现明显的问题，查看业务日志和三方调用日志也没有明显的问题。所以定位小概率的耗时长成为了的关键。

1.2性能优化

定位问题首先想到的就是添加日志，但是在业务复杂的系统中，要想通过添加日志来定位问题，那就需要添加大量的日志，会陷入到加日志-重启服务-加日志的循环中。不仅导致代码混乱，服务不断重启更是不可接受的。Skywalking配合Arthas是一个比较好的定位问题的手段。使用Skywalking定位少数耗时长的接口，时间大概消耗在哪块，然后通过Arthas动态监控、添加日志和修改部分业务代码，来实时验证自己的优化结果。

为了更好地理解问题定位过程，我们深入分析一下Skywalking和Arthas的原理。Skywalking和Arthas共同使用的是Instrumentation JavaAgent机制、以及基于ASM为基础的字节码框架。其中Arthas还使用了Attach API 、OGNL等技术。下面我们从类加载机制、javaAgent机制、字节码技术、Arthas的实现四个方面详细阐述下。

2.1类加载机制

要理解类的动态修改和加载，我们先简单介绍下类的加载机制，这部分可能大家都比较熟悉，下图是一个完整的JVM系统。一个java类，通过编译生成class文件，然后class文件被类加载系统加载到java虚拟机中：

当jvm要加载某个类时，jvm会先指定一个类加载器，负责加载此类。而此指定的类加载器在尝试自己去根据某个类的二进制名字查找其相应的字节码文件并加载之前，会首先委托给其父亲（getParent方法返回的类加载器）尝试加载，如果加载失败，就会由自己来尝试加载此类。一般情况下，这个由jvm指定的类加载器就是AppClassLoader，jvm会自动调用其loadClass(String name)方法来开启类的加载过程（真正完成类加载工作的是通过调用defineClass方法来实现的），具体细节如下图：

不过无论是什么ClassLoader，它的根父类都是 java.lang.ClassLoader。loadClass()方法最终会调用到 ClassLoader.defineClass1()中，这是一个Native方法：

2.2Java Agent

2.2.1agent机制

JDK1.5版本开始，Java增加了Instrumentation(Java Agent API)和JVMTI(JVM Tool Interface)功能，该功能可以实现JVM再加载某个class文件对其字节码进行修改，也可以对已经加载的字节码进行一个重新的加载。

Java Agent有两种运行模式：

Java.lang.instrument.ClassFileTransformer是一个转换类文件的代理接口，我们可以在获取到Instrumentation对象后通过addTransformer方法添加自定义类文件转换器。我们可以使用addTransformer注册一个我们自定义的Transformer（实现接口ClassFileTransformer）到Java Agent，当有新的类被JVM加载时JVM会自动回调用我们自定义的Transformer类的transform方法，传入该类的transform信息（类名、类加载器、类字节码等），我们可以根据传入的类信息决定是否需要修改类字节码。修改完字节码后我们将新的类字节码返回给JVM，JVM会验证类和相应的修改是否合法，如果符合类加载要求JVM会加载我们修改后的类字节码。

大多数情况下，我们使用Instrumentation都是使用其字节码插桩的功能，或者笼统说就是类重定义（Class Redefine）的功能，但是有以下的局限性：premain和agentmain两种方式修改字节码的时机都是类文件加载之后，也就是说必须要带有Class类型的参数，不能通过字节码文件和自定义的类名重新定义一个本来不存在的类。类的字节码修改称为类转换（Class Transform），类转换其实最终都回归到类重定义Instrumentation#redefineClasses()方法，此方法有以下限制：

2.2.2Attach模式

Attach能做些什么，总结起来说，比如内存dump，线程dump，类信息统计（比如加载的类及大小以及实例个数等），动态加载agent，动态设置vm flag（但是并不是所有的flag都可以设置的，因为有些flag是在jvm启动过程中使用的，是一次性的），打印vm flag，获取系统属性等。

Attach机制的关键是Attach Listener和Signal Dispatcher两个线程。Signal Dispatcher是JVM启动的时候就有的，Attach Listener是在初始化socket,启动监听的时候创建的，就是从队列里不断取AttachOperation，然后找到请求命令对应的方法进行执行，比如我们一开始说的jstack命令，找到{ “threaddump”, thread_dump }的映射关系，然后执行thread_dump方法，我们通常使用的增强类是load命令。如果没有请求的话，会一直accept在那里，当来了请求，然后就会创建一个套接字，并读取数据，执行相关命令：

AttachOperation操作命令如下：

下面我们看一下通过Agent动态修改类的流程：

2.3字节码及相关技术

通过javaAgent机制可以修改类的字节码，不过上面章节介绍的都是通过一个已有的class文件来替换原来的字节码，是否可以做到实时按需修改字节码呢？通过字节码相关技术框架加上javaAgent机制就可以做到。

字节码文件结构是一组以8位为最小基础的十六进制数据流， 各个数据项按顺序紧密的从前向后排列， 相邻的项之间没有间隙， 这样可以使得class文件非常紧凑， 体积轻巧， 可以被JVM快速的加载至内存。

在一些特殊的场景，我们需要修改类的字节码来达到一些业务需求。比如在项目优化的时候，需要查看具体方法的执行时间，通过字节码操作就可以达到要求，不需要每个方法都加日志。目前有多种操作类字节码的工具，具体工具依赖图如下：

其中skywalking使用的字节码框架是ByteBuddy，Arthas使用的框架是ByteKit。

具体如何使用字节码工具修改字节码，我们在这里就不详细描述了。

2.4Arthas原理分析

Arthas主要基于上面的描写的基础技术实现的。在不停止应用服务的情况下，将Arthas的jar包代码动态加载到应用的JVM中，再配合Instrumentation类，动态修改应用JVM中运行的字节码，实现对目标应用增强，如获取某方法的参数、返回值、耗时等信息、调用JVM相关类获取JVM运行时信息，最后再通过OGNL过滤、存取对象属性。

2.4.1Attach到JVM

Arthas使用的是attach方式连接到JVM，核心代码如下：

2.4.2类隔离和增强

因为ArthasBootstrap是由ArthasClassLoader加载器加载的，ArthasBootstrap负责初始化arthas-core，按照加载当前类的加载器，也会用于加载其所依赖的类原则，ArthasBootstrap依赖的类也会由ArthasClassLoader加载，所以就是实现了Arthas与应用的隔离。

Arthas类加载结构如下：

根据类加载器的双亲委派原则，父类加载器加载的类对子类加载器是可见的，而子类加载器加载的类对父类加载器是不可见的，兄弟类加载器加载的类互相是不可见的。也就是说Arthas和应用JVM之间共享了JMX等底层API（由BootstrapClassLoader和ExtClassLoader加载的类），所以Arthas可以通过调用JDK的一些API获取应用JVM相应的运行时数据，比如dashboard/thread/mbean等命令。但是对于增强型命令如watch/trace/tt，Arthas会对应用代码注入一些代码，当被增强的应用代码执行时，会执行到Arthas注入的代码，从而实现功能的增强。但是由于ApplicationClassLoader和ArthasClassLoader加载器的类之间是不可见的，也就是说应用代码是不能直接调用Arthas代码的，会有ClassNotFoundException或者ClassCastException。

Arthas采用了一种很巧的方案，引入了一个arthas-spy模块，相当于在应用和Arthas之间架起了一座桥梁。arthas-spy模块中只有一个SpyAPI类文件。ApyAPI类由BoostrapClassLoader加载，所以SpyAPI对于ApplicationClassLoader和ArthasClassLoader都是可见的，应用通过SpyAPI实现对Arthas的调用，从而实现功能的增强：

因为AbstractSpy是SpyAPI的内部静态类，并且在SpyAPI中定义了一个静态属性，所以AbstractApy也会由BoostrapClassLoader加载。而SpyImpl在arthas-core模块中实现，所以会被ArthasClassLoader加载。所以Arthas可以通过调用SpyAPI的setSpy方法设置增强代码的具体执行逻辑。因为AbstractApy由BoostrapClassLoader加载，SpyImpl由ArthasClassLoader加载，所以SpyImpl实例可以向上类型转换成AbstractApy实例，完成赋值操作。应用代码在调用Arthas的增强代码时，是通过调用SpyAPI的静态方法，然后调用AbstractSpy实例实现方法增强。

2.4.3Arthas服务端实现

Arthas设计架构，主要分为4个大的模块，

1.服务器的抽象

这个领域抽象的主要是arthas命令的执行环境，arthas采用的是传统的client-server的架构，但是server层的环境也是比较复杂的，为了兼容不同的网络传输协议，以及统一整个命令的执行流程，对这一层进行了抽象，这一层的作用是，在一个client-server架构下，大家敲击的命令如何到server中，然后如何返回显示执行结果。

2.命令的抽象

Arthas所支持的命令有两类:

一类是纯观察JVM信息或者操作arthas的命令如：VersionCommand，JvmCommand， QuitCommand等

一类是要对目标方法进行插装，如watchCommand，TraceCommand等，这些命令是arthas的核心。

3.命令执行模块

Arthas支持这么多的命令，如果不用一个好的设计组织起来，任由if-else横行是万万不行的，为此，arthas在接受到命令后会生成一个Job，具体的命令执行交由Job来做，也因此形成了命令执行的这个子模块。命令执行这个子领域是依赖于命令触发的。

4.代码插装模块

对于一些需要插装才能获取到的信息，比如方法的执行时长，方法的trace等，Arthas使用了bytekit框架，bytekit是基于ASM框架的，可以方便的做字节码操作，主要通过注解的方式，对ASM做了封装：

2.4.4Arthas支持OGNL

Arthas是支持OGNL表达式的，所以使用Arthas的时候非常灵活。Arthas会将增强执行的结果全部放在Advice实例中，主要包括增强的方法名、参数、执行结果、耗时等数据，在返回是先判断是否有OGNL表达式，如果有OGNL表达式，会执行OGNL表达式，针对OGNL设置的条件进行过滤或者数值筛选。主要依赖了OGNL对应的jar包。

2.4.5Arthas命令及分类

2.4.6Arthas应用

当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决：