AOP 的利器：ASM 3.0 介绍

什么是 ASM ？

ASM 是一个 Java 字节码操控框架。它能被用来动态生成类或者增强既有类的功能。ASM 可以直接产生二进制 class 文件，也可以在类被加载入 Java 虚拟机之前动态改变类行为。Java class 被存储在严格格式定义的 .class 文件里，这些类文件拥有足够的元数据来解析类中的所有元素：类名称、方法、属性以及 Java 字节码（指令）。ASM 从类文件中读入信息后，能够改变类行为，分析类信息，甚至能够根据用户要求生成新类。

与 BCEL 和 SERL 不同，ASM 提供了更为现代的编程模型。对于 ASM 来说，Java class 被描述为一棵树；使用 “Visitor” 模式遍历整个二进制结构；事件驱动的处理方式使得用户只需要关注于对其编程有意义的部分，而不必了解 Java 类文件格式的所有细节：ASM 框架提供了默认的 “response taker”处理这一切。

为什么要动态生成 Java 类？

动态生成 Java 类与 AOP 密切相关的。AOP 的初衷在于软件设计世界中存在这么一类代码，零散而又耦合：零散是由于一些公有的功能（诸如著名的 log 例子）分散在所有模块之中；同时改变 log 功能又会影响到所有的模块。出现这样的缺陷，很大程度上是由于传统的 面向对象编程注重以继承关系为代表的”纵向”关系，而对于拥有相同功能或者说方面 （Aspect）的模块之间的”横向”关系不能很好地表达。例如，目前有一个既有的银行管理系统，包括 Bank、Customer、Account、Invoice 等对象，现在要加入一个安全检查模块， 对已有类的所有操作之前都必须进行一次安全检查。

图 1. ASM – AOP

然而 Bank、Customer、Account、Invoice 是代表不同的事务，派生自不同的父类，很难在高层上加入关于 Security Checker 的共有功能。对于没有多继承的 Java 来说，更是如此。传统的解决方案是使用 Decorator 模式，它可以在一定程度上改善耦合，而功能仍旧是分散的 —— 每个需要 Security Checker 的类都必须要派生一个 Decorator，每个需要 Security Checker 的方法都要被包装（wrap）。下面我们以 Account 类为例看一下 Decorator：

首先，我们有一个 SecurityChecker 类，其静态方法 checkSecurity 执行安全检查功能：

public class SecurityChecker {
     public static void checkSecurity() {
         System.out.println("SecurityChecker.checkSecurity ...");
         //TODO real security check
     }
 }

另一个是 Account 类：

public class Account {
     public void operation() {
         System.out.println("operation...");
         //TODO real operation
     }
 }

public interface Account {
     void operation();
 }

然后把原来的 Account 类定义为一个实现类：

public class AccountImpl extends Account{
     public void operation() {
         System.out.println("operation...");
         //TODO real operation
     }
 }

public class AccountWithSecurityCheck implements Account {
     private  Account account;
     public AccountWithSecurityCheck (Account account) {
         this.account = account;
     }
     public void operation() {
         SecurityChecker.checkSecurity();
         account.operation();
     }
 }

class SecurityProxyInvocationHandler implements InvocationHandler {
     private Object proxyedObject;
     public SecurityProxyInvocationHandler(Object o) {
         proxyedObject = o;
     }
 public Object invoke(Object object, Method method, Object[] arguments)
     throws Throwable {
     if (object instanceof Account && method.getName().equals("opertaion")) {
         SecurityChecker.checkSecurity();
     }
     return method.invoke(proxyedObject, arguments);
 }

}

最后，在应用程序中指定 InvocationHandler 生成代理对象：

public static void main(String[] args) {
     Account account = (Account) Proxy.newProxyInstance(
         Account.class.getClassLoader(),
         new Class[] { Account.class },
         new SecurityProxyInvocationHandler(new AccountImpl())
     );
     account.function();
 }

public class HelloWorld {
     public static void main(String[] args) {
         System.out.println("Hello world");
     }
 }

}

• 修改类、字段、方法的名字或修饰符：在职责链传递过程中替换调用参数。

  class AccessClassAdapter extends ClassAdapter {
       public AccessClassAdapter(ClassVisitor cv) {
           super(cv);
       }
   public FieldVisitor visitField(final int access, final String name,
      final String desc, final String signature, final Object value) {
      int privateAccess = Opcodes.ACC_PRIVATE;
      return cv.visitField(privateAccess, name, desc, signature, value);
  }
  
  

• }
  

• 增加新的类、方法、字段

• ASM 的最终的目的是生成可以被正常装载的 class 文件，因此其框架结构为客户提供了一个生成字节码的工具类 —— ClassWriter 。它实现了 ClassVisitor 接口，而且含有一个 toByteArray() 函数，返回生成的字节码的字节流，将字节流写回文件即可生产调整后的 class 文件。一般它都作为职责链的终点，把所有 visit 事件的先后调用（时间上的先后），最终转换成字节码的位置的调整（空间上的前后），如下例：

  ClassWriter  classWriter = new ClassWriter(ClassWriter.COMPUTE_MAXS);
   ClassAdaptor delLoginClassAdaptor = new DelLoginClassAdapter(classWriter);
   ClassAdaptor accessClassAdaptor = new AccessClassAdaptor(delLoginClassAdaptor);
  

  ClassReader classReader = new ClassReader(strFileName);
  classReader.accept(classAdapter, ClassReader.SKIP_DEBUG);
  

  综上所述，ASM 的时序图如下：

  图 4. ASM – 时序图

  

  使用 ASM3.0 进行 AOP 编程

  我们还是用上面的例子，给 Account 类加上 security check 的功能。与 proxy 编程不同，ASM 不需要将 Account 声明成接口， Account 可以仍旧是一个实现类。ASM 将直接在 Account 类上动手术，给 Account 类的 operation 方法首部加上对 SecurityChecker.checkSecurity 的调用。

  首先，我们将从 ClassAdapter 继承一个类。 ClassAdapter 是 ASM 框架提供的一个默认类，负责沟通 ClassReader 和 ClassWriter 。如果想要改变 ClassReader 处读入的类，然后从 ClassWriter 处输出，可以重写相应的 ClassAdapter 函数。这里，为了改变 Account 类的 operation 方法，我们将重写 visitMethdod 方法。

  class AddSecurityCheckClassAdapter extends ClassAdapter {
  public AddSecurityCheckClassAdapter(ClassVisitor cv) {
      //Responsechain 的下一个 ClassVisitor，这里我们将传入 ClassWriter，
      // 负责改写后代码的输出
      super(cv);
  }
  
  // 重写 visitMethod，访问到 "operation" 方法时，
  // 给出自定义 MethodVisitor，实际改写方法内容
  public MethodVisitor visitMethod(final int access, final String name,
      final String desc, final String signature, final String[] exceptions) {
      MethodVisitor mv = cv.visitMethod(access, name, desc, signature,exceptions);
      MethodVisitor wrappedMv = mv;
      if (mv != null) {
          // 对于 "operation" 方法
          if (name.equals("operation")) {
              // 使用自定义 MethodVisitor，实际改写方法内容
              wrappedMv = new AddSecurityCheckMethodAdapter(mv);
          }
      }
      return wrappedMv;
  }
  
  

  }
  

  显示较少

  下一步就是定义一个继承自 MethodAdapter 的 AddSecurityCheckMethodAdapter ，在”operation ”方法首部插入对 SecurityChecker.checkSecurity() 的调用。

  class AddSecurityCheckMethodAdapter extends MethodAdapter {
       public AddSecurityCheckMethodAdapter(MethodVisitor mv) {
           super(mv);
       }
   public void visitCode() {
       visitMethodInsn(Opcodes.INVOKESTATIC, "SecurityChecker",
          "checkSecurity", "()V");
   }
  
  

  }
  

  其中， ClassReader 读到每个方法的首部时调用 visitCode() ，在这个重写方法里，我们用 visitMethodInsn(Opcodes.INVOKESTATIC, "SecurityChecker","checkSecurity", "()V"); 插入了安全检查功能。

  最后，我们将集成上面定义的 ClassAdapter ， ClassReader 和 ClassWriter 产生修改后的 Account 类文件 :

  import java.io.File;
   import java.io.FileOutputStream;
   import org.objectweb.asm.*;
  

  public class Generator{
  public static void main() throws Exception {
  ClassReader cr = new ClassReader(“Account”);
  ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS);
  ClassAdapter classAdapter = new AddSecurityCheckClassAdapter(cw);
  cr.accept(classAdapter, ClassReader.SKIP_DEBUG);
  byte[] data = cw.toByteArray();
  File file = new File(“Account.class”);
  FileOutputStream fout = new FileOutputStream(file);
  fout.write(data);
  fout.close();
  }
  }
  

  执行完这段程序后，我们会得到一个新的 Account.class 文件，如果我们使用下面代码：

  public class Main {
       public static void main(String[] args) {
           Account account = new Account();
           account.operation();
       }
   }
  

  使用这个 Account，我们会得到下面的输出：

  SecurityChecker.checkSecurity ...
   operation...
  

  也就是说，在 Account 原来的 operation 内容执行之前，进行了 SecurityChecker.checkSecurity() 检查。

  将动态生成类改造成原始类 Account 的子类

  上面给出的例子是直接改造 Account 类本身的，从此 Account 类的 operation 方法必须进行 checkSecurity 检查。但事实上，我们有时仍希望保留原来的 Account 类，因此把生成类定义为原始类的子类是更符合 AOP 原则的做法。下面介绍如何将改造后的类定义为 Account 的子类 Account$EnhancedByASM 。其中主要有两项工作 :

  • 改变 Class Description, 将其命名为 Account$EnhancedByASM ，将其父类指定为 Account 。
  • 改变构造函数，将其中对父类构造函数的调用转换为对 Account 构造函数的调用。

  在 AddSecurityCheckClassAdapter 类中，将重写 visit 方法：

  public void visit(final int version, final int access, final String name,
           final String signature, final String superName,
           final String[] interfaces) {
       String enhancedName = name + "$EnhancedByASM";  // 改变类命名
       enhancedSuperName = name; // 改变父类，这里是”Account”
       super.visit(version, access, enhancedName, signature,
       enhancedSuperName, interfaces);
   }
  

  改进 visitMethod 方法，增加对构造函数的处理：

  public MethodVisitor visitMethod(final int access, final String name,
       final String desc, final String signature, final String[] exceptions) {
       MethodVisitor mv = cv.visitMethod(access, name, desc, signature, exceptions);
       MethodVisitor wrappedMv = mv;
       if (mv != null) {
           if (name.equals("operation")) {
               wrappedMv = new AddSecurityCheckMethodAdapter(mv);
           } else if (name.equals("<init>")) {
               wrappedMv = new ChangeToChildConstructorMethodAdapter(mv,
                   enhancedSuperName);
           }
       }
       return wrappedMv;
   }
  

  这里 ChangeToChildConstructorMethodAdapter 将负责把 Account 的构造函数改造成其子类 Account$EnhancedByASM 的构造函数：

  class ChangeToChildConstructorMethodAdapter extends MethodAdapter {
       private String superClassName;
   public ChangeToChildConstructorMethodAdapter(MethodVisitor mv,
       String superClassName) {
       super(mv);
       this.superClassName = superClassName;
   }
  
   public void visitMethodInsn(int opcode, String owner, String name,
       String desc) {
       // 调用父类的构造函数时
       if (opcode == Opcodes.INVOKESPECIAL && name.equals("<init>")) {
           owner = superClassName;
       }
       super.visitMethodInsn(opcode, owner, name, desc);// 改写父类为 superClassName
   }
  
  

  }
  

  最后演示一下如何在运行时产生并装入产生的 Account$EnhancedByASM 。 我们定义一个 Util 类，作为一个类工厂负责产生有安全检查的 Account 类：

  public class SecureAccountGenerator {
  private static AccountGeneratorClassLoader classLoader =
      new AccountGeneratorClassLoade();
  
  private static Class secureAccountClass;
  
  public Account generateSecureAccount() throws ClassFormatError,
      InstantiationException, IllegalAccessException {
      if (null == secureAccountClass) {
          ClassReader cr = new ClassReader("Account");
          ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS);
          ClassAdapter classAdapter = new AddSecurityCheckClassAdapter(cw);
          cr.accept(classAdapter, ClassReader.SKIP_DEBUG);
          byte[] data = cw.toByteArray();
          secureAccountClass = classLoader.defineClassFromClassFile(
             "Account$EnhancedByASM",data);
      }
      return (Account) secureAccountClass.newInstance();
  }
  
  private static class AccountGeneratorClassLoader extends ClassLoader {
      public Class defineClassFromClassFile(String className,
          byte[] classFile) throws ClassFormatError {
          return defineClass("Account$EnhancedByASM", classFile, 0,
          classFile.length());
      }
  }
  
  

  }
  

  静态方法 SecureAccountGenerator.generateSecureAccount() 在运行时动态生成一个加上了安全检查的 Account 子类。著名的 Hibernate 和 Spring 框架，就是使用这种技术实现了 AOP 的”无损注入”。

  结束语

  最后，我们比较一下 ASM 和其他实现 AOP 的底层技术：

  表 1. AOP 底层技术比较

  AOP 底层技术	功能	性能	面向接口编程	编程难度
  直接改写 class 文件	完全控制类	无明显性能代价	不要求	高，要求对 class 文件结构和 Java 字节码有深刻了解
  JDK Instrument	完全控制类	无论是否改写，每个类装入时都要执行 hook 程序	不要求	高，要求对 class 文件结构和 Java 字节码有深刻了解
  JDK Proxy	只能改写 method	反射引入性能代价	要求	低
  ASM	几乎能完全控制类	无明显性能代价	不要求	中，能操纵需要改写部分的 Java 字节码

最后

以上就是谨慎可乐为你收集整理的AOP 的利器：ASM 3.0 介绍的全部内容，希望文章能够帮你解决AOP 的利器：ASM 3.0 介绍所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。