Java技术专题-探针Agent底层运作原理和分析（2）

JavaAgent

启动时加载的 JavaAgent 是 JDK1.5 之后引入的新特性，此特性为用户提供了在 JVM 将字节码文件读入内存之后，JVM 使用对应的字节流在 Java 堆中生成一个 Class 对象之前，用户可以对其字节码进行修改的能力，从而JVM也将会使用用户修改过之后的字节码进行 Class 对象的创建。

JVM Tool Interface

• JVMTI 是 JVM 暴露出来的一些供用户进行自定义扩展的接口集合，每当 jvm 执行到一些特定的逻辑的时间，就会去进行触发这些回调接口，用户就恰好可以在此回调接口之中做一些自定义逻辑。

• 而对于此次所要描述的 JavaAgent 也恰恰是基于 JVMTI 的，JPLISAgent 就是用作实现 javaagent 功能的动态库。

JPLISAgent

JPLISAgent 实现了 Agent_OnLoad 方法，Agent_OnLoad 方法就是整个启动时加载的 JavaAgent 的入口方法，后续也会说明整个运行流程。

如何使用

虽然大多数同学可能已经使用过 JavaAgent 了，但是为了下面原理的平滑过渡，我这里还是大概写一下使用：

编写 premain 启动类

编写一个含有以下 premain 函数的类

public static void premain(String agentArgs, Instrumentation instrumentation);[1]
public static void premain(String agentArgs);[2]

• 上面的两个方法只需要实现一个即可，且 [1] 的优先级是高于 [2] 的，即如果上面的两个方法同时出现，则只会执行 [1] 方法。

• agentArgs是javaagent:xx.jar=yyy传入yyy字符串是java.lang.instrument.Instrumentation 实例，由本地方法实例化并由 jvm自动传入。

此类是 JavaAgent 的核心类。

public class Agent { 
 　　public static void premain(String args, Instrumentation inst){ 
 　　　　System.out.println("Hi, This is a agent!"); 
　　 　　inst.addTransformer(new TestTransformer());
　　　　// 将类转换器添加到此`agent`的`instrumentation`实例之中
 　　}
}

类转换器

类转换器的作用主要是在某个类的字节码被 JVM 读入之后，在 Java 堆上创建 Class 对象之前，JVM 会遍历所有的 instrumentation 实例并执行其中的所有的ClassFileTransformer 的 transform 方法，其中关于启动时加载的 javaAgent 重点需要关注的入参：

• className：当前类的限定类名。
• classfileBuffer：当前类的以 byte 数组呈现的字节码数据（可能跟 class 文件的数据不一致, 因为此处的 byte 数据是此类最新的字节码数据，即此数据可能是原始字节码数据被其他增强方法增强之后的自己买数据）

public class TestTransformer implements ClassFileTransformer { 
 　　@Override 
 　　public byte[] transform(ClassLoader classLoader, String className, Class classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) { 
 　　　　// 进行对应类字节码的操作，并返回新字节码数据的 byte 数组，如果返回 null，则代码不对此字节码作任何操作
　　　　 return null;
 　　} 
}

然后将上述的代码打成 jar 包并在 jvm 启动时增加 -javaagent:xx.jar 即可以完成 javaAgent 的生效。

实现原理

上面关于 JavaAgent 的使用有涉及到这么几个关键字：

premain,Instrumentation,ClassFileTransformer,MAINIFEST.MF 中的 Premain-Class

• 对于在启动命令添加的 -javaagent:xx.jar，如果有多个加载顺序就是从前往后，且每一个 -javaagent 都是独立的。

• 以下的加载流程仅仅只是针对其中的一个javaagent描述的。

• javaAgent 的入口方法就是 InvocationAdapter.c 中的 Agent_OnLoad 方法。经过查看 openjdk 源码，发现如下注释

• 由注释我们可以指定，每一个 -javaagent 都会有其自己的 agent 和 agent 数据，且每一个 javaagent 都会调用一次 Agent_OnLoad 方法就会被调用一次，且每一次的调用都是独立的。

在 Agent_OnLoad 方法中主要做的事情有下面三个：

• 1）初始化一个 JPLISAgent 对象，并给此对象设置 VMInit 事件的回调函数 eventHandlerVMInit.

• 2）找到 jvm 启动参数中 -javaagent:xx.jar=yyy 中的 xx.jar 文件添加到 classpath 之中，并获取 yyy

• 3）找到 xx.jar 包中的 MAINIFEST.MF 中定义的 premainClass 并作为此 Agent 的入口类

• 4）并将 premainClass 和 yyy 设置到步骤 1 初始化的 JPLISAgent 对象之中。

当 VMInit 事件完成以后，会回调 InvocationAdapter.c中的 eventHandlerVMInit 方法，eventHandlerVMInit 方法主要做的事情有下面：

• 1）实例化一个 InstrumentationImpl 对象，jvm 并依借此对象与 java 代码进行交互。

• 2）通过 JNI 执行 MAINIFEST.MF 中定义的类中的 premain 方法（我们上面的例子之中在 premain 方法中给 Instrumentation 对象添加了一个 ClassFileTransformer）

• 3）去除 JPLISAgent 对象中的 VMInit 回调函数，转而设置一个 ClassFileLoadHook 事件的回调函数。

---

• 当 ClassFileLoadHook 事件 (在字节码文件被 jvm 读入之后，在 Class 对象创建之前) 完成后，进行触发 eventHandlerClassFileLoadHook，此方法主要做的事情有下面几件：

• 进行调用 InstrumentationImpl 对象中的 mTransform 方法，而对于 mTransform 方法，最终会调用到我们在 Agent 的 premain 方法中给 Instrumentation 增加的 ClassFileTransformer。

• 此时，JVM 会通过 JNI 调用 java 代码，对应的类就是 sun.instrument.InstrumentationImpl 类之中，而对应于 mTransform 的方法就是 byte[] transform(ClassLoader var1, String var2, Class var3, ProtectionDomain var4, byte[] var5, boolean var6)

• 方法是上述中 c 代码调用的地方，其中的 var5 是对应当前文件的字节码数据, 如果此接口返回的数据为 null，则认为 transform 方法并未对此 class 文件有过修改，如果返回的数据不为 null，则会使用返回的新字节码作为 jvm 中此类最新的字节码并进行下一个

Javaagent 的处理或者创建 Class 对象进行链接以及初始化。

其中对于 c 代码通过 JNI 反射调用 java 代码的方法声明都在 JPLISAgent.h 类中可以看见

struct _JPLISAgent;
typedef struct _JPLISAgent JPLISAgent;

typedef struct _JPLISEnvironment JPLISEnvironment;


7/* constants for class names and methods names and such
8 these all must stay in sync with Java code & interfaces
9*/
10#define JPLIS_INSTRUMENTIMPL_CLASSNAME "sun/instrument/InstrumentationImpl"
11#define JPLIS_INSTRUMENTIMPL_CONSTRUCTOR_METHODNAME ""
12#define JPLIS_INSTRUMENTIMPL_CONSTRUCTOR_METHODSIGNATURE "(JZZ)V"
13#define JPLIS_INSTRUMENTIMPL_PREMAININVOKER_METHODNAME "loadClassAndCallPremain"
14#define JPLIS_INSTRUMENTIMPL_PREMAININVOKER_METHODSIGNATURE "(Ljava/lang/String;Ljava/lang/String;)V"
15#define JPLIS_INSTRUMENTIMPL_AGENTMAININVOKER_METHODNAME "loadClassAndCallAgentmain"
16#define JPLIS_INSTRUMENTIMPL_AGENTMAININVOKER_METHODSIGNATURE "(Ljava/lang/String;Ljava/lang/String;)V"
17#define JPLIS_INSTRUMENTIMPL_TRANSFORM_METHODNAME "transform"
18#define JPLIS_INSTRUMENTIMPL_TRANSFORM_METHODSIGNATURE \
19 "(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/lang/Class;Ljava/security/ProtectionDomain;[BZ)[B"

对于启动时加载的 JavaAgent 涉及到的 c 代码主要为:

其中涉及到的 c 代码在 /src/share/instrument 目录下的 JPLISAgent.c，JPLISAgent.h，InvocationAdapter.c。

涉及到的 java 代码为 sun.instrument.InstrumentationImpl。

字节码工具

上面我们说过，javaAgent 提供了一些接口可以让我们在某些特定的时机进行对于 java 字节码的操作，在不改变代码的前提下，修改最终载入内存的字节码。但是由于直接操作字节码需要对 java 的字节码底层有较深入的研究。所以一些能帮助我们

不需要了解字节码底层也能修改字节码的工具就诞生了。其中较为流行的字节码操作工具有 byteBuddy 和 javassist 等等。

Javassist 冲突

使用了两种 JavaAgent（一种 JavaAgent 是基于 ByteBuddy，另外一种 JavaAgent 是基于 Javassist）同时去增强同一个类的同一个方法：

当两个 JavaAgent 的载入顺序为：Javassist-ByteBuddy，这两个 JavaAgent 对于同一个类的同一个方法的增强都生效了

当两个 JavaAgent 的载入顺序为：ByteBuddy-Javassist，Javassist 对应的增强生效了，而 ByteBuddy 对应的增强却没生效

当使用三个 JavaAgent（两个 Javassist，一个 ByteBuddy）的载入顺序为:Javassist-ByteBuddy-Javassist，两个 Javassist 的增强都生效了，而 ByteBuddy 对应的增强却没生效

冲突根因

针对上面结果的不同，我们来开始分析不同的 JavaAgent 的实现在不同加载顺序下为什么会造成如此大的差异呢？

使用 Javassist 创建 JavaAgent

ClassPool classPool = ClassPool.getDefault();
CtClass ctClass = classPool.getCtClass(className);
CtMethod[] ctMethods = ctClass.getDeclaredMethods();
for (int i = 0; i < ctMethods.length; i++) {
     CtMethod ctMethod = ctMethods[i];
     if (!ctMethod.getName().equalsIgnoreCase("main")) {
         continue
     }
 　ctMethod.insertBefore("System.out.println(\" 这是第 2 个 javassist Agent Before~~~~~\");");
 　ctMethod.insertAfter("System.out.println(\" 这是第 2 个 javassist Agent After~~~~~\");");
}
return ctClass.toBytecode();

其中对于 Javassist 是使用 ClassPool 对象来存储对应的 class 对象，对于默认的 defaultPool 是 static 属性，故如果有多个基于 Javassist 实现的 JavaAgent，那么它们使用的 ClassPool 是同一个对象。

当使用 classPool.getCtClass(className) 方法获取一个 CtClass 对象，其中 Javassist 都做了哪些事情呢？

让我们进去看看

 protected synchronized CtClass get0(String classname, boolean useCache) throws NotFoundException {
　　 CtClass clazz = null;
　　 if (useCache) {
　　　　 clazz = this.getCached(classname);
　　 　　if (clazz != null) {
　　　　 　　return clazz;
 　　　　}
 　　}
　　 if (!this.childFirstLookup && this.parent != null) {
 　　　　clazz = this.parent.get0(classname, useCache);
 　　　　if (clazz != null) {
 　　　　　　return clazz;
 　　　　}
 　　}
　　 clazz = this.createCtClass(classname, useCache);
　　 if (clazz != null) {
　　 　　if (useCache) {
 　　　　　　this.cacheCtClass(clazz.getName(), clazz, false);
 　　　　}
　　　　 return clazz;
　　 }else {
　　 　　if (this.childFirstLookup && this.parent != null) {
　　 　　　　clazz = this.parent.get0(classname, useCache);
　　 　　}
　　 　　return clazz;
 　　}
 }

由上面源码可以当 ClassPool 的 Cache 中不存在对应的 class 的时候，javassist 会调用 this.createCtClass(classname, useCache) 来实例化一个 CtClass 对象，那它是如何创建的呢？

 protected CtClass createCtClass(String classname, boolean useCache) {
　　 if (classname.charAt(0) == '[') {
　　　　 classname = Descriptor.toClassName(classname);
 　　}

　　 if (!classname.endsWith("[]")) {
 　　　　return this.find(classname) == null ? null : new CtClassType(classname, this);
 　} else {
　　 　　String base = classname.substring(0, classname.indexOf(91));
　　　　 return (!useCache || this.getCached(base) == null) && this.find(base) == null ? null : new CtArray(classname, this);
　　 }
 }

可以看出，对于此次，javassist 仅仅只是使用 className 用实例化了个 CtClassType 对象。

当获取了 CtClass 对象之后，我们想知道其中都有哪些方法，接下来使用 ctClass.getDeclaredMethods() 来获取其中的方法，我们看看他是如何获取的呢？

getDeclaredMethods()–>getMembers()–>makeBehaviorCache(cache)–>getClassFile2()–>openClassfile(classname)

 public InputStream openClassfile(String classname) {
　　 try {
 　　　　char sep = File.separatorChar;
 　　　　String filename = this.directory + sep + classname.replace('.', sep) + ".class";
 　　　　return new FileInputStream(filename.toString());
 　　} catch (FileNotFoundException var4) {
 　　　　;
 　　} catch (SecurityException var5) {
 　　　　;
 　 }
　　　 return null;
 }

可以看出 javassist 获取到对应类的 class 文件，并以文件流的形式读入以获取到其 class 中所有的方法和属性并缓存在 CtClassType 对象之中（由此，我们可以明确一个问题，第一个 javassist 对于字节码的修改都是基于对应类的源字节码文件）

当 javasist 使用了 ctMethod.insertBefore 方法对某方法进行增强的之后，会刷新其对应 ClassPool 之中缓存的 CtClassType 的属性。

当第二个基于 Javassist 实现的 JavaAgent 对相同的类进行增强的时候，其也会去 ClassPool 中获取 CtClass 对象，而这个 CtClass 恰恰就是上一个 JavaAgent 对原始字节码增强之后刷新的结果，这样可以说明第二个 JavaAgent 在增强的时候使用的字节码的源文件跟第一个 JavaAgent 使用的字节码的源文件的获取方式不同。

冲突结论

根据上述现象与原理的分析，我们可以得出：

如果同时使用基于 Javassist 和基于其他字节码工具的 JavaAgent 去增强同一个类，Javassist 的加载顺序一定要在其他字节码的 JavaAgent 之前，这样才能保证两个字节码工具都可以进行完整的增强。如果基于 Javassist 的 JavaAgent 最后增强，那么之前的非Javassist 的 JavaAgent 对于字节码的增强都会被丢弃掉，这也能会带来不小的麻烦。