JAVA Instrumentation

什么是Instrumentation？

java Instrumentation指的是可以用独立于应用程序之外的代理（agent）程序来监测和协助运行在JVM上的应用程序。这种监测和协助包括但不限于获取JVM运行时状态，替换和修改类定义等。 Java SE5中使用JVM TI替代了JVM PI和JVM DI。提供一套代理机制，支持独立于JVM应用程序之外的程序以代理的方式连接和访问JVM。java.lang.instrument是在JVM TI的基础上提供的Java版本的实现。 Instrumentation提供的主要功能是修改jvm中类的行为。 Java SE6中由两种应用Instrumentation的方式，premain（命令行）和agentmain（运行时）

premain方式

在Java SE5时代，Instrument只提供了premain一种方式，即在真正的应用程序（包含main方法的程序）main方法启动前启动一个代理程序。例如使用如下命令：

java -javaagent:agent_jar_path[=options] java_app_name

可以在启动名为java_app_name的应用之前启动一个agent_jar_path指定位置的agent jar。 实现这样一个agent jar包，必须满足两个条件：

1. 在这个jar包的manifest文件中包含Premain-Class属性，并且改属性的值为代理类全路径名。
2. 代理类必须提供一个public static void premain(String args, Instrumentation inst)或 public static void premain(String args) 方法。

当在命令行启动该代理jar时，VM会根据manifest中指定的代理类，使用于main类相同的系统类加载器（即ClassLoader.getSystemClassLoader()获得的加载器）加载代理类。在执行main方法前执行premain()方法。如果premain(String args, Instrumentation inst)和premain(String args)同时存在时，优先使用前者。其中方法参数args即命令中的options，类型为String（注意不是String[]），因此如果需要多个参数，需要在方法中自己处理（比如用";"分割多个参数之类）；inst是运行时由VM自动传入的Instrumentation实例，可以用于获取VM信息。

premain实例-打印所有的方法调用

下面实现一个打印程序执行过程中所有方法调用的功能，这个功能可以通过AOP其他方式实现，这里只是尝试使用Instrumentation进行ClassFile的字节码转换实现：

构造agent类

premain方式的agent类必须提供premain方法，代码如下：

package test;import java.lang.instrument.Instrumentation;public class Agent {    public static void premain(String args, Instrumentation inst){        System.out.println("Hi, I'm agent!");        inst.addTransformer(new TestTransformer());    }}

premain有两个参数，args为自定义传入的代理类参数，inst为VM自动传入的Instrumentation实例。 premain方法的内容很简单，除了标准输出外，只有

inst.addTransformer(new TestTransformer());

这行代码的意思是向inst中添加一个类的转换器。用于转换类的行为。

构造Transformer

下面来实现上述过程中的TestTransformer来完成打印调用方法的类定义转换。

package test;import java.lang.instrument.ClassFileTransformer;import java.lang.instrument.IllegalClassFormatException;import java.security.ProtectionDomain;import org.objectweb.asm.ClassReader;import org.objectweb.asm.ClassWriter;import org.objectweb.asm.Opcodes;import org.objectweb.asm.tree.ClassNode;import org.objectweb.asm.tree.FieldInsnNode;import org.objectweb.asm.tree.InsnList;import org.objectweb.asm.tree.LdcInsnNode;import org.objectweb.asm.tree.MethodInsnNode;import org.objectweb.asm.tree.MethodNode;public class TestTransformer implements ClassFileTransformer {    @Override    public byte[] transform(ClassLoader arg0, String arg1, Class<?> arg2,            ProtectionDomain arg3, byte[] arg4)            throws IllegalClassFormatException {        ClassReader cr = new ClassReader(arg4);        ClassNode cn = new ClassNode();        cr.accept(cn, 0);        for (Object obj : cn.methods) {            MethodNode md = (MethodNode) obj;            if ("<init>".endsWith(md.name) || "<clinit>".equals(md.name)) {                continue;            }            InsnList insns = md.instructions;            InsnList il = new InsnList();            il.add(new FieldInsnNode(Opcodes.GETSTATIC, "java/lang/System",                    "out", "Ljava/io/PrintStream;"));            il.add(new LdcInsnNode("Enter method-> " + cn.name+"."+md.name));            il.add(new MethodInsnNode(Opcodes.INVOKEVIRTUAL,                    "java/io/PrintStream", "println", "(Ljava/lang/String;)V"));            insns.insert(il);            md.maxStack += 3;        }        ClassWriter cw = new ClassWriter(0);        cn.accept(cw);        return cw.toByteArray();    }}

TestTransformer实现了ClassFileTransformer接口，该接口只有一个transform方法，参数传入包括该类的类加载器，类名，原字节码字节流等，返回被转换后的字节码字节流。 TestTransformer主要使用ASM实现在所有的类定义的方法中，在方法开始出添加了一段打印该类名和方法名的字节码。在转换完成后返回新的字节码字节流。详细的ASM使用请参考ASM手册。

设置MANIFEST.MF

设置MANIFEST.MF文件中的属性，文件内容如下：

Manifest-Version: 1.0Premain-Class: test.AgentCreated-By: 1.6.0_29

测试

代码编写完成后将代码编译打成agent.jar。 编写测试代码：

public class TestAgent {    public static void main(String[] args) {        TestAgent ta = new TestAgent();        ta.test();    }    public void test() {        System.out.println("I'm TestAgent");    }}

从命令行执行该类，并设置agent.jar

java -javaagent:agent.jar TestAgent

将打印出程序运行过程中实际执行过的所有方法名：

Hi, I'm agent!Enter method-> test/TestAgent.mainEnter method-> test/TestAgent.testI'm TestAgentEnter method-> java/util/IdentityHashMap$KeySet.iteratorEnter method-> java/util/IdentityHashMap$IdentityHashMapIterator.hasNextEnter method-> java/util/IdentityHashMap$KeyIterator.nextEnter method-> java/util/IdentityHashMap$IdentityHashMapIterator.nextIndexEnter method-> java/util/IdentityHashMap$IdentityHashMapIterator.hasNextEnter method-> java/util/IdentityHashMap$KeySet.iteratorEnter method-> java/util/IdentityHashMap$IdentityHashMapIterator.hasNextEnter method-> java/util/IdentityHashMap$KeyIterator.nextEnter method-> java/util/IdentityHashMap$IdentityHashMapIterator.nextIndexEnter method-> com/apple/java/Usage$3.run。。。

从输出中可以看出，程序首先执行的是代理类中的premain方法（不过代理类自身不会被自己转换，所以不能打印出代理类的方法名），然后是应用程序中的main方法。

agentmain方式

premain时Java SE5开始就提供的代理方式，给了开发者诸多惊喜，不过也有些须不变，由于其必须在命令行指定代理jar，并且代理类必须在main方法前启动。因此，要求开发者在应用前就必须确认代理的处理逻辑和参数内容等等，在有些场合下，这是比较苦难的。比如正常的生产环境下，一般不会开启代理功能，但是在发生问题时，我们不希望停止应用就能够动态的去修改一些类的行为，以帮助排查问题，这在应用启动前是无法确定的。 为解决运行时启动代理类的问题，Java SE6开始，提供了在应用程序的VM启动后在动态添加代理的方式，即agentmain方式。 与Permain类似，agent方式同样需要提供一个agent jar，并且这个jar需要满足：

1. 在manifest中指定Agent-Class属性，值为代理类全路径
2. 代理类需要提供public static void agentmain(String args, Instrumentation inst)或public static void agentmain(String args)方法。并且再二者同时存在时以前者优先。args和inst和premain中的一致。

不过如此设计的再运行时进行代理有个问题——如何在应用程序启动之后再开启代理程序呢？ JDK6中提供了Java Tools API，其中Attach API可以满足这个需求。

Attach API中的VirtualMachine代表一个运行中的VM。其提供了loadAgent()方法，可以在运行时动态加载一个代理jar。具体需要参考《Attach API》

agentmain实例-打印当前已加载的类

构造agent类

agentmain方式的代理类必须提供agentmain方法：

package loaded;import java.lang.instrument.Instrumentation;public class LoadedAgent {    @SuppressWarnings("rawtypes")    public static void agentmain(String args, Instrumentation inst){        Class[] classes = inst.getAllLoadedClasses();        for(Class cls :classes){            System.out.println(cls.getName());        }    }}

agentmain方法通过传入的Instrumentation实例获取当前系统中已加载的类。

设置MANNIFEST.MF

设置MANIFEST.MF文件，指定Agent-Class:

Manifest-Version: 1.0Agent-Class: loaded.LoadedAgentCreated-By: 1.6.0_29

绑定到目标VM

将agent类和MANIFEST.MF文件编译打成loadagent.jar后，由于agent main方式无法向pre main方式那样在命令行指定代理jar，因此需要借助Attach Tools API。

package attach;import java.io.IOException;import com.sun.tools.attach.AgentInitializationException;import com.sun.tools.attach.AgentLoadException;import com.sun.tools.attach.AttachNotSupportedException;import com.sun.tools.attach.VirtualMachine;public class Test {    public static void main(String[] args) throws AttachNotSupportedException,            IOException, AgentLoadException, AgentInitializationException {        VirtualMachine vm = VirtualMachine.attach(args[0]);        vm.loadAgent("/Users/jiangbo/Workspace/code/java/javaagent/loadagent.jar");    }}

该程序接受一个参数为目标应用程序的进程id，通过Attach Tools API的VirtualMachine.attach方法绑定到目标VM，并向其中加载代理jar。

构造目标测试程序

构造一个测试用的目标应用程序：

package attach;public class TargetVM {    public static void main(String[] args) throws InterruptedException{        while(true){            Thread.sleep(1000);        }    }}

这个测试程序什么都不做，只是不停的sleep。:) 运行该程序，获得进程ID=33902。 运行上面绑定到VM的Test程序，将进程id作为参数传入：

java attach.Test 33902

观察输出，会打印出系统当前所有已经加载类名

java.lang.NoClassDefFoundErrorjava.lang.StrictMathjava.security.SignatureSpijava.lang.Runtimejava.util.Hashtable$EmptyEnumeratorsun.security.pkcs.PKCS7java.lang.InterruptedExceptionjava.io.FileDescriptor$1java.nio.HeapByteBufferjava.lang.ThreadGroup[Ljava.lang.ThreadGroup;java.io.FileSystem。。。

Java SE 6 新特性：本地方法的 Instrumentation

在 1.5 版本的 instumentation 里，并没有对 Java 本地方法（Native Method）的处理方式，而且在 Java 标准的 JVMTI 之下，并没有办法改变 method signature， 这就使替换本地方法非常地困难。一个比较直接而简单的想法是，在启动时替换本地代码所在的动态链接库 —— 但是这样，本质上是一种静态的替换，而不是动态的 Instrumentation。而且，这样可能需要编译较大数量的动态链接库 —— 比如，我们有三个本地函数，假设每一个都需要一个替换，而在不同的应用之下，可能需要不同的组合，那么如果我们把三个函数都编译在同一个动态链接库之中，最多我们需要 8 个不同的动态链接库来满足需要。当然，我们也可以独立地编译之，那样也需要 6 个动态链接库——无论如何，这种繁琐的方式是不可接受的。

在 Java SE 6 中，新的 Native Instrumentation 提出了一个新的 native code 的解析方式，作为原有的 native method 的解析方式的一个补充，来很好地解决了一些问题。这就是在新版本的 java.lang.instrument 包里，我们拥有了对 native 代码的 instrument 方式 —— 设置 prefix。假设我们有了一个 native 函数，名字叫 nativeMethod，在运行中过程中，我们需要将它指向另外一个函数（需要注意的是，在当前标准的 JVMTI 之下，除了 native 函数名，其他的 signature 需要一致）。比如我们的 Java 代码是：

 package nativeTester;  class nativePrefixTester{ … native int nativeMethod(int input); … }

那么我们已经实现的本地代码是 :

 jint Java_nativeTester_nativeMethod(jclass thiz, jobject thisObj, jint input);

现在我们需要在调用这个函数时，使之指向另外一个函数。那么按照 J2SE 的做法，我们可以按他的命名方式，加上一个 prefix 作为新的函数名。比如，我们以 "another_" 作为 prefix，那么我们新的函数是 :

 jint Java_nativeTester_another_nativePrefixTester(jclass thiz, jobject thisObj,  jint input);

然后将之编入动态链接库之中。现在我们已经有了新的本地函数，接下来就是做 instrument 的设置。正如以上所说的，我们可以使用 premain 方式，在虚拟机启动之时就载入 premain 完成 instrument 代理设置。也可以使用 agentmain 方式，去 attach 虚拟机来启动代理。而设置 native 函数的也是相当简单的 :

 premain(){  // 或者也可以在 agentmain 里… if (!isNativeMethodPrefixSupported()){  return; // 如果无法设置，则返回 }  setNativeMethodPrefix(transformer,"another_"); // 设置 native 函数的 prefix，注意这个下划线必须由用户自己规定… }

在这里要注意两个问题。一是不是在任何的情况下都是可以设置 native 函数的 prefix 的。首先，我们要注意到 agent 包之中的 Manifest 所设定的特性 :

 Can-Set-Native-Method-Prefix

要注意，这一个参数都可以影响是否可以设置 native prefix，而且，在默认的设置之中，这个参数是 false 的，我们需要将之设置成 true（顺便说一句，对 Manifest 之中的属性来说都是大小写无关的，当然，如果给一个不是“true”的值，就会被当作 false 值处理）。当然，我们还需要确认虚拟机本身是否支持 setNativePrefix。在 Java API 里，Instrumentation 类提供了一个函数 isNativePrefix，通过这个函数我们可以知道该功能是否可以实行。

二是我们可以为每一个 ClassTransformer 加上它自己的 nativeprefix；同时，每一个 ClassTransformer 都可以为同一个 class 做 transform，因此对于一个 Class 来说，一个 native 函数可能有不同的 prefix，因此对这个函数来说，它可能也有好几种解析方式。在 Java SE 6 当中，Native prefix 的解释方式如下：对于某一个 package 内的一个 class 当中的一个 native method 来说，首先，假设我们对这个函数的 transformer 设置了 native 的 prefix“another”，它将这个函数接口解释成 :

由 Java 的函数接口

 native void method()

和上述 prefix"another"，去寻找本地代码中的函数

 void Java_package_class_another_method(jclass theClass, jobject thiz);   // 请注意 prefix 在函数名中出现的位置！

一旦可以找到，那么调用这个函数，整个解析过程就结束了；如果没有找到，那么虚拟机将会做进一步的解析工作。我们将利用 Java native 接口最基本的解析方式 , 去找本地代码中的函数 :

 void Java_package_class_method(jclass theClass, jobject thiz);

如果找到，则执行之。否则，因为没有任何一个合适的解析方式，于是宣告这个过程失败。那么如果有多个 transformer，同时每一个都有自己的 prefix，又该如何解析呢？事实上，虚拟机是按 transformer 被加入到的 Instrumentation 之中的次序去解析的（还记得我们最基本的 addTransformer 方法吗？）。假设我们有三个 transformer 要被加入进来，他们的次序和相对应的 prefix 分别为：transformer1 和“prefix1_”，transformer2 和 “prefix2_”，transformer3 和 “prefix3_”。那么，虚拟机会首先做的就是将接口解析为 :

 native void prefix1_prefix2_prefix3_native_method()

然后去找它相对应的 native 代码。但是如果第二个 transformer（transformer2）没有设定 prefix，那么很简单，我们得到的解析是：

 native void prefix1_prefix3_native_method()

这个方式简单而自然。当然，对于多个 prefix 的情况，我们还要注意一些复杂的情况。比如，假设我们有一个 native 函数接口是：

 native void native_method()

然后我们为它设置了两个 prefix，比如 "wrapped_" 和 "wrapped2_"，那么，我们得到的是什么呢？是

 void Java_package_class_wrapped_wrapped2_method(jclass theClass, jobject thiz);  // 这个函数名正确吗？

吗？答案是否定的，因为事实上，对 Java 中 native 函数的接口到 native 中的映射，有一系列的规定，因此可能有一些特殊的字符要被代入。而实际中，这个函数的正确的函数名是：

 void Java_package_class_wrapped_1wrapped2_1method(jclass theClass, jobject thiz);  // 只有这个函数名会被找到

很有趣不是吗？因此如果我们要做类似的工作，一个很好的建议是首先在 Java 中写一个带 prefix 的 native 接口，用 javah 工具生成一个 c 的 header-file，看看它实际解析得到的函数名是什么，这样我们就可以避免一些不必要的麻烦。另外一个事实是，与我们的想像不同，对于两个或者两个以上的 prefix，虚拟机并不做更多的解析；它不会试图去掉某一个 prefix，再来组装函数接口。它做且仅作两次解析。总之，新的 native 的 prefix-instrumentation 的方式，改变了以前 Java 中 native 代码无法动态改变的缺点。在当前，利用 JNI 来写 native 代码也是 Java 应用中非常重要的一个环节，因此它的动态化意味着整个 Java 都可以动态改变了 —— 现在我们的代码可以利用加上 prefix 来动态改变 native 函数的指向，正如上面所说的，如果找不到，虚拟机还会去尝试做标准的解析，这让我们拥有了动态地替换 native 代码的方式，我们可以将许多带不同 prefix 的函数编译在一个动态链接库之中，而通过 instrument 包的功能，让 native 函数和 Java 函数一样动态改变、动态替换。当然，现在的 native 的 instrumentation 还有一些限制条件，比如，不同的 transformer 会有自己的 native prefix，就是说，每一个 transformer 会负责他所替换的所有类而不是特定类的 prefix —— 因此这个粒度可能不够精确。

Java SE 6 新特性：BootClassPath / SystemClassPath 的动态增补

我们知道，通过设置系统参数或者通过虚拟机启动参数，我们可以设置一个虚拟机运行时的 boot class 加载路径（-Xbootclasspath）和 system class（-cp）加载路径。当然，我们在运行之后无法替换它。然而，我们也许有时候要需要把某些 jar 加载到 bootclasspath 之中，而我们无法应用上述两个方法；或者我们需要在虚拟机启动之后来加载某些 jar 进入 bootclasspath。在 Java SE 6 之中，我们可以做到这一点了。

实现这几点很简单，首先，我们依然需要确认虚拟机已经支持这个功能，然后在 premain/agantmain 之中加上需要的 classpath。我们可以在我们的 Transformer 里使用 appendToBootstrapClassLoaderSearch/appendToSystemClassLoaderSearch 来完成这个任务。

同时我们可以注意到，在 agent 的 manifest 里加入 Boot-Class-Path 其实一样可以在动态地载入 agent 的同时加入自己的 boot class 路径，当然，在 Java code 中它可以更加动态方便和智能地完成 —— 我们可以很方便地加入判断和选择成分。

在这里我们也需要注意几点。首先，我们加入到 classpath 的 jar 文件中不应当带有任何和系统的 instrumentation 有关的系统同名类，不然，一切都陷入不可预料之中 —— 这不是一个工程师想要得到的结果，不是吗？

其次，我们要注意到虚拟机的 ClassLoader 的工作方式，它会记载解析结果。比如，我们曾经要求读入某个类 someclass，但是失败了，ClassLoader 会记得这一点。即使我们在后面动态地加入了某一个 jar，含有这个类，ClassLoader 依然会认为我们无法解析这个类，与上次出错的相同的错误会被报告。

再次我们知道在 Java 语言中有一个系统参数“java.class.path”，这个 property 里面记录了我们当前的 classpath，但是，我们使用这两个函数，虽然真正地改变了实际的 classpath，却不会对这个 property 本身产生任何影响。

在公开的 JavaDoc 中我们可以发现一个很有意思的事情，Sun 的设计师们告诉我们，这个功能事实上依赖于 ClassLoader 的 appendtoClassPathForInstrumentation 方法 —— 这是一个非公开的函数，因此我们不建议直接（使用反射等方式）使用它，事实上，instrument 包里的这两个函数已经可以很好的解决我们的问题了。

从以上的介绍我们可以得出结论，在 Java SE 6 里面，instrumentation 包新增的功能 —— 虚拟机启动后的动态 instrument、本地代码（native code）instrumentation，以及动态添加 classpath 等等，使得 Java 具有了更强的动态控制、解释能力，从而让 Java 语言变得更加灵活多变

附：agent jar中manifest的属性

• Premain-Class: 当在VM启动时，在命令行中指定代理jar时，必须在manifest中设置Premain-Class属性，值为代理类全类名，并且该代理类必须提供premain方法。否则JVM会异常终止。
• Agent-Class: 当在VM启动之后，动态添加代理jar包时，代理jar包中manifest必须设置Agent-Class属性，值为代理类全类名，并且该代理类必须提供agentmain方法，否则无法启动该代理。
• Boot-Class-Path: Bootstrap class loader加载类时的搜索路径，可选。
• Can-Redefine-Classes: true/false；标示代理类是否能够重定义类。可选。
• Can-Retransform-Classes: true/false；标示代理类是否能够转换类定义。可选。
• Can-Set-Native-Prefix::true/false；标示代理类是否需要本地方法前缀，可选。

当一个代理jar包中的manifest文件中既有Premain-Class又有Agent-Class时，如果以命令行方式在VM启动前指定代理jar，则使用Premain-Class；反之如果在VM启动后，动态添加代理jar，则使用Agent-Class