初学 Java 时，我对 IDEA 的 Debug 非常好奇，不止是它能查看断点的上下文环境，更神奇的是我可以在断点处使用它的 Evaluate 功能直接执行某些命令，进行一些计算或改变当前变量。
刚开始语法不熟经常写错代码，重新打包部署一次代码耗时很长，我就直接面向 Debug 开发。在要编写的方法开始处打一个断点，在 Evaluate 框内一次次地执行方法函数不停地调整代码，没问题后再将代码复制出来放到 IDEA 里，再进行下一个方法的编写，这样就跟写 PHP 类似的解释性语言一样，写完即执行，非常方便。
但 Java 是静态语言，运行之前是要先进行编译的，难道我写的这些代码是被实时编译又”注入”到我正在 Debug 的服务里了吗？
随着对 Java 的愈加熟悉，我也了解了反射、字节码等技术，直到前些天的周会分享，有位同事分享了 Btrace 的使用和实现，提到了 Java 的 ASM 框架和 JVM TI 接口。 Btrace 修改代码能力的实现与 Debug 的 Evaluate 有很多相似之处，这大大吸引了我。分享就像一个引子，从中学到的东西只是皮毛，要了解它还是要自己研究。于是自己查看资料并写代码学习了下其具体实现。
ASM实现 Evaluate 要解决的第一个问题就是怎么改变原有代码的行为，它的实现在 Java 里被称为动态字节码技术。
动态生成字节码我们知道，我们编写的 Java 代码都是要被编译成字节码后才能放到 JVM 里执行的，而字节码一旦被加载到虚拟机中，就可以被解释执行。
字节码文件（.class）就是普通的二进制文件，它是通过 Java 编译器生成的。而只要是文件就可以被改变，如果我们用特定的规则解析了原有的字节码文件，对它进行修改或者干脆重新定义，这不就可以改变代码行为了么。
Java 生态里有很多可以动态生成字节码的技术，像 BCEL、Javassist、ASM、CGLib 等，它们各有自己的优势。有的使用复杂却功能强大、有的简单确也性能些差。
ASM 框架ASM 是它们中最强大的一个，使用它可以动态修改类、方法，甚至可以重新定义类，连 CGLib 底层都是用 ASM 实现的。
当然，它的使用门槛也很高，使用它需要对 Java 的字节码文件有所了解，熟悉 JVM 的编译指令。虽然我对 JVM 的字节码语法不熟，但有大神开发了可以在 IDEA 里查看字节码的插件：ASM Bytecode Outline ，在要查看的类文件里右键选择 Show bytecode Outline 即可以右侧的工具栏查看我们要生成的字节码。对照着示例，我们就可以很轻松地写出操作字节码的 Java 代码了。
而切到 ASMified 标签栏，我们甚至可以直接获取到 ASM 的使用代码。
在 ASM 的代码实现里，最明显的就是访问者模式，ASM 将对代码的读取和操作都包装成一个访问者，在解析 JVM 加载到的字节码时调用。
ClassReader 是 ASM 代码的入口，通过它解析二进制字节码，实例化时它时，我们需要传入一个 ClassVisitor，在这个 Visitor 里，我们可以实现 visitMethod()/visitAnnotation() 等方法，用以定义对类结构（如方法、字段、注解）的访问方法。
而 ClassWriter 接口继承了 ClassVisitor 接口，我们在实例化类访问器时，将 ClassWriter “注入” 到里面，以实现对类写入的声明。
Instrument 介绍字节码是修改完了，可是 JVM 在执行时会使用自己的类加载器加载字节码文件，加载后并不会理会我们做出的修改，要想实现对现有类的修改，我们还需要搭配 Java 的另一个库 instrument。
instrument 是 JVM 提供的一个可以修改已加载类文件的类库。1.6以前，instrument 只能在 JVM 刚启动开始加载类时生效，之后，instrument 更是支持了在运行时对类定义的修改。
使用要使用 instrument 的类修改功能，我们需要实现它的 ClassFileTransformer 接口定义一个类文件转换器。它唯一的一个 transform() 方法会在类文件被加载时调用，在 transform 方法里，我们可以对传入的二进制字节码进行改写或替换，生成新的字节码数组后返回，JVM 会使用 transform 方法返回的字节码数据进行类的加载。
JVM TI定义完了字节码的修改和重定义方法，但我们怎么才能让 JVM 能够调用我们提供的类转换器呢？这里又要介绍到 JVM TI 了。
介绍