通过使用 Byte Buddy，便捷地创建 Java Agent.docxVIP

通过使用 Byte Buddy，便捷地创建 Java Agent 类文件代表了 Java 类编译之后的形态。类文件中会包含字节码，这些字节码代表了 Java 源码中最后的程序指令。Java 字节码可以视为 Java 虚拟机的言语。实际上，JVM 并不会将 Java 视为编程言语，它只能处理字节码。由于它接受二进制的表现方式，所以相对于程序的源码，它占用的空间更少。除此之外，将程序以字节码的方式进行表现能够更简约地编译 Java 以外的其他言语，如 Scala 或 Clojure，从而让它们运转在 JVM 上。假如没有字节码作为两头言语的话，那么其他的程序在运转之前，可能还需要将其转换为 Java 源码。 但是，在代码处理的时候，这种笼统却带来了肯定的成本。假如要将ClassFileTransformer应用到某个类上，那我们不能将该类依据 Java 源码的方式进行处理，甚至不能假设被转换的代码最后是由 Java 编写而成的。更蹩脚的是，探查类成员或注解的反射 API 也是禁止使用的，这是由于类加载之前，我们无法访问这些 API，而在转换进程完成之前，是无法进行加载的。 所幸的是，Java 字节码相对来讲是一个比较简约的笼统方式，它包含了很少量的操作，略微花点功夫我们就能大致将其把握起来。Java 虚拟机执行程序的时候，会以基于栈的方式来处理值。字节码指令一般会告知虚拟机，需要从操作数栈（operand stack）上弹出值，执行一些操作，然后再将结果压到栈中。 让我们考虑一个简约的样例：将数字 1 和 2 进行相加操作。JVM 首先会将这两个数字压到栈中，这是通过?iconst_1和iconst_2这两个字节指令实现的。iconst_1是个单字节的便捷运算符（operator），它会将数字 1 压到栈中。与之类似，iconst_2会将数字 2 压到栈中。然后，会执行iadd指令，它会将栈中最新的两个值弹出，将它们求和计算的结果重新压到栈中。在类文件中，每个指令并不是以其易于记忆的名称进行存储的，而是以一个字节的方式进行存储，这个字节能够独一地标记特定的指令，这也是bytecode这个术语的来历。上文所述的字节码指令及其对操作数栈的影响，通过下面的图片进行了可视化。 对于人类用户来讲，会更宠爱源码而不是字节码，不过侥幸的是 Java 社区创建了多个库，能够解析类文件并将紧凑的字节码暴露为具出名称的指令流。例如，流行的 ASM 库供应了一个简约的 visitor API，它能够将类文件剖析为成员和方法指令，其操作方式类似于阅读 XML 文件时的 SAX 解析器。假如使用 ASM 的话，那上述样例中的字节码可以依据如下的代码来进行实现（在这里，ASM 方式的指令是visitIns，能够供应修正的方法实现）： MethodVisitor methodVisitor = ... methodVisitor.visitIns(Opcodes.ICONST_1); methodVisitor.visitIns(Opcodes.ICONST_2); methodVisitor.visitIns(Opcodes.IADD); 需要留意的是，字节码规范只不过是一种比方的说法（metaphor），由于 Java 虚拟机允许将程序转换为优化后的机器码（machine code），只需程序的输出能够保证是正确的即可。由于字节码的简约性，所以在已有的类中取代和修改指令是很简约直接的。因而，使用 ASM 及其底层的 Java 字节码基础就足以实现类转换的 Java agent，这需要注册一个ClassFileTransformer，它会使用这个库来处理其参数。 克服字节码的不足 对于实际的应用来讲，解析原始的类文件照旧意味着有很多的手动工作。Java 程序员通常感爱好的是类型层级结构中的类。例如，某个 Java agent 可能需要修改全部实现给定接口的类。假如要确定某个类的超类，那只靠解析ClassFileTransformer所给定的类文件就不够了，类文件中只包含了直接超类和接口的名字。为了解析可能的超类型关联关系，程序员照旧需要定位这些类型的类文件。 在项目中直接使用 ASM 的另外一个困难在于，团队中需要有开发人员学习 Java 字节码的基础学问。在实践中，这往往会导致很多的开发人员不敢再去修改字节码操作相关的代码。假如这样的话，实现 Java agent 很简约为项目的长期维护带来风险。 为了克服这些问题，我们最好使用较高层级的笼统来实现 Java agent，而不是直接操作 Java 字节码。Byte Buddy 是开源的、基于 Apache 2.0 许可证的库，它努力于处理字节码操作和 instrumentation API 的简单性。Byt