1JavaAgent

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

1.1 JVM Tool Interface

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

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

1.2 JPLISAgent

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

2如何使用

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

2.1 编写premain启动类

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

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

上面的两个方法只需要实现一个即可，且[1]的优先级是高于[2]的，即如果上面的两个方法同时出现，则只会执行[1]方法
agentArgs是跟随javaagent:xx.jar=yyy传入的yyy字符串
instrumentation是一个java.lang.instrument.Instrumentation实例，由本地方法实例化并由jvm自动传入。此类是JavaAgent的核心类。

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

2.2 类转换器

类转换器的作用主要是在某个类的字节码被JVM读入之后，在Java堆上创建Class对象之前，JVM会遍历所有的instrumentation实例并执行其中的所有的ClassFileTransformer的transform方法，其中关于启动时加载的javaAgent重点需要关注的入参：
className：当前类的限定类名
classfileBuffer：当前类的以byte数组呈现的字节码数据（可能跟class文件的数据不一致,因为此处的byte数据是此类最新的字节码数据，即此数据可能是原始字节码数据被其他增强方法增强之后的自己买数据）

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

2.3 MAINIFEST.MF

1Manifest-Version: 1.0  
2Premain-Class: test.Agent

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

3实现原理

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

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

其实对于上面这些关键字就恰好组成了JavaAgent的实现原理

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

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

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

1/*
2 *  This will be called once for every -javaagent on the command line.
3 *  Each call to Agent_OnLoad will create its own agent and agent data.
4 *

由注释我们可以指定，每一个-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，此方法主要做的事情有下面几件：

1）进行调用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类中可以看见

 1struct  _JPLISAgent;
 2
 3typedef struct _JPLISAgent        JPLISAgent;
 4typedef struct _JPLISEnvironment  JPLISEnvironment;
 5
 6
 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         "<init>"
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，PLISAgent.h，InvocationAdapter.c。
涉及到的java代码为sun.instrument.InstrumentationImpl。

4字节码工具

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

4.1 Javassist冲突

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

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

4.2 冲突根因

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

使用Javassist创建JavaAgent

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

其中对于Javassist是使用ClassPool对象来存储对应的class对象，对于默认的defaultPool是static属性，故如果有多个基于Javassist实现的JavaAgent，那么它们使用的ClassPool是同一个对象。
当使用classPool.getCtClass(className)方法获取一个CtClass对象，其中Javassist都做了哪些事情呢？
让我们进去看看

 1 protected synchronized CtClass get0(String classname, boolean useCache) throws NotFoundException {
 2        CtClass clazz = null;
 3        if (useCache) {
 4            clazz = this.getCached(classname);
 5            if (clazz != null) {
 6                return clazz;
 7            }
 8        }
 9
10        if (!this.childFirstLookup && this.parent != null) {
11            clazz = this.parent.get0(classname, useCache);
12            if (clazz != null) {
13                return clazz;
14            }
15        }
16
17        clazz = this.createCtClass(classname, useCache);
18        if (clazz != null) {
19            if (useCache) {
20                this.cacheCtClass(clazz.getName(), clazz, false);
21            }
22
23            return clazz;
24        } else {
25            if (this.childFirstLookup && this.parent != null) {
26                clazz = this.parent.get0(classname, useCache);
27            }
28
29            return clazz;
30        }
31    }

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

 1 protected CtClass createCtClass(String classname, boolean useCache) {
 2        if (classname.charAt(0) == '[') {
 3            classname = Descriptor.toClassName(classname);
 4        }
 5
 6        if (!classname.endsWith("[]")) {
 7            return this.find(classname) == null ? null : new CtClassType(classname, this);
 8        } else {
 9            String base = classname.substring(0, classname.indexOf(91));
10            return (!useCache || this.getCached(base) == null) && this.find(base) == null ? null : new CtArray(classname, this);
11        }
12    }

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

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

 1 public InputStream openClassfile(String classname) {
 2        try {
 3            char sep = File.separatorChar;
 4            String filename = this.directory + sep + classname.replace('.', sep) + ".class";
 5            return new FileInputStream(filename.toString());
 6        } catch (FileNotFoundException var4) {
 7            ;
 8        } catch (SecurityException var5) {
 9            ;
10        }
11
12        return null;
13    }

可以看出javassist获取到对应类的class文件，并以文件流的形式读入以获取到其class中所有的方法和属性并缓存在CtClassType对象之中（由此，我们可以明确一个问题，第一个javassist对于字节码的修改都是基于对应类的源字节码文件）
当javasist使用了ctMethod.insertBefore方法对某方法进行增强的之后，会刷新其对应ClassPool之中缓存的CtClassType的属性。
当第二个基于Javassist实现的JavaAgent对相同的类进行增强的时候，其也会去ClassPool中获取CtClass对象，而这个CtClass恰恰就是上一个JavaAgent对原始字节码增强之后刷新的结果，这样可以说明第二个JavaAgent在增强的时候使用的字节码的源文件跟第一个JavaAgent使用的字节码的源文件的获取方式不同。

这时候，问题已经有一点眉目了。

我们可以明确这么几个事情：

1）非Javassist的字节码工具中一定中不存在与Javassist相同的ClassPool对象

2）两个基于Javassist产生的JavaAgent增强的字节码的获取来源不同

这时候，就需要上Instrument的源码了！

下面代码对应于jdk8的openJdk源码的/src/share/instrumentJPLISAgent.c

 1void
 2transformClassFile(             JPLISAgent *            agent,
 3                                JNIEnv *                jnienv,
 4                                jobject                 loaderObject,
 5                                const char*             name,
 6                                jclass                  classBeingRedefined,
 7                                jobject                 protectionDomain,
 8                                jint                    class_data_len,
 9                                const unsigned char*    class_data,
10                                jint*                   new_class_data_len,
11                                unsigned char**         new_class_data,
12                                jboolean                is_retransformer) {
13    jboolean        errorOutstanding        = JNI_FALSE;
14    jstring         classNameStringObject   = NULL;
15    jarray          classFileBufferObject   = NULL;
16    jarray          transformedBufferObject = NULL;
17    jsize           transformedBufferSize   = 0;
18    unsigned char * resultBuffer            = NULL;
19    jboolean        shouldRun               = JNI_FALSE;
20
21    /* only do this if we aren't already in the middle of processing a class on this thread */
22    shouldRun = tryToAcquireReentrancyToken(
23                                jvmti(agent),
24                                NULL);  /* this thread */
25
26    if ( shouldRun ) {
27       .................
28
29        /*  now call the JPL agents to do the transforming */
30        /*  potential future optimization: may want to skip this if there are none */
31        if ( !errorOutstanding ) {
32            jplis_assert(agent->mInstrumentationImpl != NULL);
33            jplis_assert(agent->mTransform != NULL);
34            transformedBufferObject = (*jnienv)->CallObjectMethod(
35                                                jnienv,
36                                                agent->mInstrumentationImpl,
37                                                agent->mTransform,
38                                                loaderObject,
39                                                classNameStringObject,
40                                                classBeingRedefined,
41                                                protectionDomain,
42                                                classFileBufferObject,
43                                                is_retransformer);
44            errorOutstanding = checkForAndClearThrowable(jnienv);
45            jplis_assert_msg(!errorOutstanding, "transform method call failed");
46        }
47        ..................
48        ..........
49    }
50    return;
51}

我们可以看到CallObjectMethod()方法的后六个入参，这六个入参直接对应于sun.instrument.InstrumentationImpl.byte[] transform(ClassLoader var1, String var2, Class<?> var3, ProtectionDomain var4, byte[] var5, boolean var6)，其中byte[] var5对应于上面的classFileBufferObject，classFileBufferObject对象是对应类的字节码数据，方法transform的返回值是对应类改变之后的字节码数据，而改变之后的值也会将classFileBufferObject覆盖，然后进行下一个JavaAgent的增强或则进行载入，链接和初始化。

看完Instrument的源码，我们回忆一下Javassist的增强过程：Javassist使用的是对应类的class文件进行读入并进行增强。

如果某一时刻，Javassist的JavaAgent接收到的某个类的字节码数据(原始字节码已经被其他非Javassist的方式增强之后的字节码)和此类对应的class文件的数据不一致，这时候Javassist就会废弃掉接收到的已经被改变的字节码数据，转而使用此类最原始的class文件进行增强。这种情况就是先使用ByteBuddy,后使用Javassist的情况。

当两个JavaAgent的载入顺序为：Javassist-ByteBuddy，这时候Javassist将此类进行增强之后，新的字节码数据传递给ByteBuddy，ByteBuddy会基于最新的字节码数据进行新的增强，这时候两个JavaAgent都可以正常增强。

当使用三个JavaAgent（两个Javassist，一个ByteBuddy）的载入顺序为：Javassist-ByteBuddy-Javassist

第一个Javassist读取对应类的class文件并存储在ClassPool之中,并进行增强并刷新，ByteBuddy获取到最新的字节码数据，也进行增强，第二个Javassist获取到第一个Javassist和ByteBuddy增强的数据之后，舍弃掉了，转而使用ClassPool只会中的数据，因为ClassPool之中的数据是第一个Javassist增强之后的字节码；所以结果之中保留着第一个Javassist的改动，但是对于ByteBuddy的改动就废弃掉了。

由上面的分析我们可以明确出两种JavaAgent顺序不同所导致的结果不同是由于javassist的内部实现机制所导致的，但是还是有个疑问？那么对于byteBuddy的agent，它操作的字节码数据是从哪里来的呢？

下面展示的方法是ByteBuddy的Agent之中对于transform方法的实现，binaryRepresentation此参数就是针对于当前类最新的字节码数据，ByteBuddy使用其生成了一个ClassFileLocator对象，然后经查看ClassFileLocator类的注释，可以得知，ByteBuddy则是使用最新的字节码数据进行自己其他的增强操作，这刚好也能印证了上面的结果。

以下代码对应的是

net.bytebuddy.agent.builder.AgentBuilder.java

 1 private byte[] transform(JavaModule module,
 2                          ClassLoader classLoader,
 3                          String internalTypeName,
 4                          Class<?> classBeingRedefined,
 5                          ProtectionDomain protectionDomain,
 6                          byte[] binaryRepresentation) {
 7     if (internalTypeName == null || !lambdaInstrumentationStrategy.isInstrumented(classBeingRedefined)) {
 8         return NO_TRANSFORMATION;
 9     }
10     String typeName = internalTypeName.replace('/', '.');
11     try {
12         ClassFileLocator classFileLocator = ClassFileLocator.Simple.of(typeName,
13                 binaryRepresentation,
14                 locationStrategy.classFileLocator(classLoader, module));
15         ......
16         ......
17     } catch (Throwable throwable) {
18         listener.onError(typeName, classLoader, module, throwable);
19         return NO_TRANSFORMATION;
20     } finally {
21         listener.onComplete(typeName, classLoader, module);
22     }
1/**
2 * Locates a class file or its byte array representation when it is given its type description.
3 */
4public interface ClassFileLocator extends Closeable {

4.3 冲突结论

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

作者介绍：
作者跳跳虎（企业代号名），目前负责贝壳找房JAVA 服务端研发工作。

本文转载自公众号贝壳产品技术（ID：gh_9afeb423f390）。

原文链接：

https://mp.weixin.qq.com/s/3hXyFCgclsuoznNQ2ulC4g

创作场景

JavaAgent 原理与实践