JRockit JVM对AOP的支持，第1部分

时间：2005-10-19 作者：Alexandre Vasseur, Joakim Dahlstedt, Jonas Bonér

　　面向方面编程（Aspect-Oriented Programming，AOP）正在软件社区和企业界中获得强大的发展动力。自从20世纪90年代Xerox引入了AOP之后，AOP经过研究团体、开源社区和企业界的数次推动和革新，已经越来越成熟了。在Java领域，近两年开源运动已经获得了极大的推动，这导致AspectWerkz和AspectJ最近合并在一起，现在它们都归入Eclipse Foundation，代号为AspectJ 5。AspectJ是由BEA Systems公司和IBM公司发起的，可以认为它是使用Java实现AOP的事实标准。

　　随着AOP流行程度的逐渐增加和研究团体的不懈努力，词汇表、概念和实现已经趋于一致，这得到了更完善的工具支持，允许更好的开发者体验，比如，出现了AspectJ Eclipse插件AspectJ Development Tools (AJDT)。

　　AOP已经经历了多种实现技术，从源代码操作到字节码测试（这是Java中一种广泛采用的技术，特别是在Java 5 JVMTI出现之后）。如今，在应用程序管理和监视领域，有多种应用AOP的企业级产品采用了这种技术，并且最近随着基于POJO（Plain Old Java Object）的中间件和透明集群的出现而变得越来越流行。

　　因此，无论如何，字节码测试越来越可能成为你最终必须掌握的东西。你将不得不回答下面这些问题：字节码测试技术究竟能够把可管理性、透明性和效率扩展和实现到什么程度？依赖于字节码测试的AOP实现会不会发展到尽头，以至无法为更高的效率、易用性和动态性做进一步的革新？JVM对AOP的支持会解决这些问题吗？能够解决到什么程度？本系列文章通过揭示BEA JRockit JVM AOP支持的内幕以及激发在这个领域中的争论，来提供这些问题的具体答案。

　　第一篇文章介绍AOP概念并且简单地说明为什么许多实现（比如AspectJ）要基于字节码操作。它解释了与字节码测试技术相关的一些限制，以及它们为什么会在长期运行过程中影响可伸缩性和可用性。然后，最后一节介绍JRockit JVM对AOP的支持，这一技术的目标是克服这些限制，为AOP和其他截取机制提供一个高效率的后端。

　　本系列文章的第2部分将通过具体的API细节和示例来说明这种支持的力度。

什么是面向方面编程 ?

　　面向对象的分析和设计引入了继承、抽象和多态等概念，由此为我们提供了降低软件复杂性的工具。但是，开发人员在软件设计过程中仍然经常会面对无法用面向对象软件开发技术轻易解决的问题。这些问题之一就是如何处理应用程序中的横切关注点（Cross-cutting concerns）。

横切关注点

　　关注点就是设计人员感兴趣的某一概念或区域。例如，在一个订货系统中，核心关注点可能是订单处理和生产，而系统关注点可能是事务处理和安全管理。

　　横切关注点是影响多个类或模块的关注点，即未能很好地局部化和模块化的关注点。

　　横切关注点的表现有：

　　·代码纠结——当一个模块或代码段同时管理多个关注点时发生这种情况。

　　·代码分散——当一个关注点分布在许多模块中并且未能很好地局部化和模块化时发生这种情况。

　　这些现象会从几个方面影响软件；例如，它们会导致软件难以维护和重用，并且难以编写和理解。

关注点的隔离

　　面向方面编程试图通过引入“关注点的隔离”这一概念来解决这些问题。采用这一概念，可以以一种模块化而且适当局部化的方式实现关注点。AOP解决这个问题的办法是在设计空间中增加额外一维，并且引入了一些构造，这些构造使我们能够定义横切关注点，将它们转移进新的维，并且以模块化方式将它们打包。

AOP 引入的新构造

　　AOP引入了一些新的构造。联结点（join point）构造准确反映了程序流中定义良好的点，例如调用方法的地方或者捕获异常的地方。切点（pointcut）构造使我们能够挑选出匹配某一标准的联结点。建议（advice）构造使我们能够添加应该在匹配的联结点执行的代码。引入（introduction）构造使我们能够向现有的类添加额外的代码，例如，向现有的类添加方法、字段或接口。最后，AOP引入了方面（aspect）构造，这是模块化的AOP单元。方面由联结点、切点、建议和引入来定义（也称为类型间声明）。

用 AspectJ 实现 AOP 的示例

　　下面是一些简单的AspectJ 5代码示例，它们在一定程度上说明了如何在代码中实现上面定义的概念。要想进一步了解特定的AOP语言细节，请参考AspectJ文档。

// using a dedicated syntax
// that compliments the Java language
public aspect Foo {

  pointcut someListOperation() : call(* List+.add(..));

  pointcut userScope() : within(com.biz..*);

  before() : someListOperation() && userScope() {
    System.out.println("called: "
        + thisJoinPoint.getSignature()
    );
  }
}

　　以上代码使用了一种专门的语法。可以使用Java注释写出等效的代码。

// the Java 5 annotations approach
@Aspect
public class Foo {

  @Pointcut("call(* java.util.List+.add(..))")
  public void someListOperation() {}

  @Pointcut("within(com.biz..*)")
  public void userScope() {}

  @Before("someListOperation() && userScope()")
  public void before(JoinPoint thisJoinPoint) {
    System.out.println("called: "
        + thisJoinPoint.getSignature()
    );
  }
}

　　以上代码定义了一个方面Foo，它具有两个切点someListOperation()和userScope()。这些切点将在应用程序中挑选出一组联结点。它们组合在一起成为一个布尔表达式someListOperation() && userScope()，这样在扩展List的任何类型实例上，在每次调用名为add的任何方法之前都会执行before建议，前提条件是：调用是从com.biz包（及其子包）中的某些代码发出的。这样，before建议会在所有这些联结点上输出将被调用的方法的签名。第二个代码示例定义了一个非常相似的方面，只是采用了一种依赖Java 5注释的替代语法。

什么是 编织 ?

　　正如前一节和代码示例所描述的，方面可以对整个应用程序进行横切。编织（waving）就是将方面和常规的面向对象应用程序“织”成一个单元（单个应用程序）的过程。

　　编织可以在不同时期进行：

• 编译时编织：例如，在部署之前（因此也在运行时之前）进行代码的后期处理（AspectJ 1.x中采用）。
• 装载时编织：在装载类的时候（也就是在部署时）进行编织（AspectWerkz 2.0中采用）。
• 运行时编织：编织可以在应用程序生命周期中的任何时候进行（JRockit 和SteamLoom中采用）。

　　这个过程还能以多种不同方式进行：

• 源代码编织：输入是已开发的源代码，而输出是经过修改的调用方面的源代码（AspectJ 1.x中采用）。
• 字节码编织：输入是编译出来的应用程序类的字节码，而输出是经过调整的编织过的应用程序的字节码（AspectWerkz 2.0和AspectJ 1.1以及更高版本中采用）。

　　源代码编织受到一定的限制，所有源代码必须可用并提供给编织器，这样才能应用方面。这就导致某些目标不可能实现，例如实现通用的监视服务。编译时编织也受到同一问题的困扰：在编译后进行部署之前，需要把将部署的所有字节码准备好。

　　本系列文章全面介绍了字节码编织和JVM 编织，从下一节开始将讨论这些内容。

　　随便提一下动态代理（Dynamic proxies），这是一种受限的编织方式，它在JVM中已经存在了一段时间了。这个API自从1.3版开始就是JDK的一部分，它允许为一个接口（和/或一系列接口）创建一个动态虚拟代理，这样就有可能截取对这个代理的每个调用，并且将其重定向到你希望的任何地方。根据定义，这并不是真正的编织，但是它与编织类似的地方是它提供了进行方法截取的简单方式。各种框架采用它来进行简单的AOP，例如Spring Framework。

基于字节码测试进行编织的问题

值得强调的是，下面提到的问题与字节码测试相关，因此，当前的AOP实现（比如AspectJ）会受到它们的困扰。总的来说，这些问题会影响所有基于字节码测试的产品，比如应用程序监视解决方案、分析工具或其他应用AOP的解决方案。

测试是低效率的

　　编织的实际测试部分往往非常消耗CPU，而且有时还会消耗大量内存。这会影响启动时间。例如，要想截取所有对toString()方法的调用或者对某个字段的所有访问，需要逐一分析所有类中的几乎每一条字节码指令。这还意味着字节码测试框架将创建许多中间表示结构，以一种有用的方式公开字节码指令。这可能意味着编织器需要分析整个应用程序（包括第三方库等）中所有类中的所有字节码指令。在糟糕的情况下，这可能会涵盖超过10, 000个类。

　　如果使用多个编织器，那么开销就会成倍增加。

双重 记录 ：为编织器构建类数据库是代价高昂的

　　为了知道类、方法或字段是否应该被编织，编织器需要对这个类或成员的元数据进行匹配。大多数AOP框架和应用AOP的产品具有某种高级表达式语言（切点表达式），用于定义代码块（建议）应该被编织在哪里（在哪些联结点上）。例如，这些表达式语言使你能够挑选出具有某种返回类型的所有方法，这种类型实现了类型T的接口。在代表对特定方法M进行调用的字节码指令中，这一信息是不可用的。了解这个特定方法M是否应该被编织的唯一办法是，在某种形式的类数据库中查找它，查询它的返回类型，并且检查它的返回类型是否实现了给定的接口T。

　　你可能会认为：为什么不只使用java.lang.reflect.* API？在这里使用反射的问题是，如果不触发这个类的类装载，就无法通过反射查询Java类型，这将在我们掌握进行编织所需的足够信息（在装载时编织基础架构中）之前触发这个类的编织。简单地说，这就成了典型的鸡生蛋/蛋生鸡问题。

　　因此，编织器需要一个类数据库（常常从硬盘读取原始字节码，在内存中建立），这样才能对实际的联结点是否需要某个方法进行必要的查询。有时候，可以通过限制表达式语言的可表达性来避免这个问题，但是这种做法常常会限制产品的可用性。

　　一旦编织完成，这个内存中的类数据库就是多余的。JVM已经在它自己的数据库中保存了所有信息，而且是经过优化的（比如，它为java.lang.reflect API服务就使用这些信息）。所以，我们最终对整个类结构（对象模型）进行了双重记录，这会不必要地消耗可观的内存，而且由于创建这个类数据库以及在发生变化时维护它，会增加启动开销。

　　如果使用多个编织器，那么开销就会成倍增加。

HotSwap ：在运行时改变字节码会增加复杂性

　　Java 5引入了HotSwap API，作为JVMTI规范的一部分。在Java 5之前，这个API只有运行于调试模式时才可用，而且只对本机C/C++ JVM扩展有效。这个API允许在运行时修改字节码——即重新定义一个类。一些AOP框架和应用AOP的产品使用它模拟运行时编织功能。

　　尽管这个API非常强大，但是它在以下这些方面限制了可用性和可伸缩性：

• 它的效率不高。因为在运行时改变字节码，所以在运行时也会产生测试开销（CPU开销和内存开销）。另外，如果需要修改许多地方，就意味着要重新定义许多类。然后，JVM将不得不重新执行它以前可能执行过的所有优化和内联工作。
• 它受到很大的限制。这个API没有指定当前运行字节码的地方可以安全更改。因此，编织器需要假设此字节码在硬盘上，否则它就需要跟踪此字节码。当使用多个编织器时，这是个大问题，这在下一节解释。

　　另外，HotSwap API的当前实现不支持方案修改（schema change），规范中将此功能声明为可选的。这意味着不可能在运行时修改类的方案，例如，添加底层测试模型可能需要的方法/字段/接口。这导致不可能实现某些运行时编织类型，并且因此要求用户提前“准备好”类。

多个代理是个问题

　　当多个产品正在使用字节码测试时，可能会发生出乎意料的问题。问题涉及到先后次序、更改通知、更改撤消等。这在当今可能还不是个大问题，但是以后将成为严重的问题。编织器可以视为代理（JVMTI规范中就是采用这种称呼），它在装载时或运行时执行测试。当使用多个代理时，就会存在很高的风险，因为代理以各自的方式获得字节码，并可能以出乎下一个代理意料的方式修改字节码，而原来假设是只有单独配置的代理。

　　下面是当两个代理互不了解时出现问题的例子。如果有人使用两个代理——一个编织器和某个应用程序性能产品，它们都在装载时执行字节码测试，根据配置，编织后的代码可能是也可能不是性能度量的一部分，如下所示：

// say this is the original user code
void businessMethod() {
  userCode.do();
}

//---- Case 1
// say the AOP weaver was applied BEFORE the
// performance management weaver
// the woven code will behave like:
void businessMethod() {
  try {
    performanceEnter();
    aopBeforeExecuting();//hypothetical advice
    userCode.do()
  } finally {
    performanceExit();
  }
}
// ie the AOP code affect the measure


//---- Case 2
// say the AOP weaver was applied AFTER the
// performance management weaver
// the woven code will behave like:
void businessMethod() {
  aopBeforeExecuting();//hypothetical advice
  try {
    performanceEnter();
    userCode.do()
  } finally {
    performanceExit();
  }
}
// ie the AOP code will NOT affect the measure

　　关于这些代理的先后次序有一个问题；在联结点（或切点）级别上没有控制次序的细粒度配置方法。

　　某些其他情况可能导致更加无法预测的结果。例如，当一个字段访问被截取时，这往往意味着字段获取（field get）字节码指令被移动到一个新添加的方法，并且被替换为对这个新方法的调用。因此，下一个编织器将在代码中的另一个位置（在那个新添加的方法中）看到一个字段访问，而它自己的匹配机制和配置可能不匹配这个位置。

　　总之，主要问题如下：

• 代理看到哪些字节码？问题是，正常情况下，被编织的字节码是从类装载管道获得的，但是建立类数据库所依赖的字节码是从硬盘读取的。当涉及多个代理时，硬盘上的字节码不再是正在执行的字节码了；因为某个代理可能已经修改了字节码，这意味着第二个代理看到的是错误的字节码视图。当使用HotSwap API时，也会发生这种情况。
• 当代理A撤消或者改变它的编织操作时，可能会出现问题。如果另一个代理B在代理A之后已经执行了修改，那么代理B可能已经重新构造了字节码，导致字节码看起来完全不一样了（尽管其功能是一样的），在此情况下，代理A就不知道该怎么做了。

截取反射式调用是不可能的

　　当前的编织方式只能测试（至少是部分地）可静态确定的执行流。请考虑以下代码示例，它在给定的实例foo上调用方法void doA()。

public void invokeA(Object foo) throws Throwable {
  Method mA = foo.getClass().getDeclaredMethod("doA",
 new Class[0]);
  mA.invoke(foo, new Object[0]);
}

　　在现代的代码库中常常使用这种反射式访问来创建实例、调用方法或者访问字段。

　　从字节码的角度来看，对方法void doA()的调用是看不到的。编织器只看到对java.lang.reflect API的调用。还没有简单且高效的办法可以对通过反射执行的调用进行编织。目前，这对于如何执行编织以及如何实现AOP是很重要的限制。最好的办法是，开发人员使用执行端切点来代替。显然，从JVM的角度来看，存在一个对doA()方法的方法调度，尽管这在源代码或字节码中没有出现。已经证明，JVM编织是以高效的方式解决这个问题的唯一编织机制。

其他问题

　　某些人对字节码测试持怀疑态度，尤其是在动态执行的情况下（在装载时或运行时）。对于动态修改代码，存在着一种不应低估的情绪化影响，尤其是在与某种盲目的革命性新技术（比如AOP或服务的透明式插入）结合使用时。在涉及多个代理时可能发生的混乱将增加人们的怀疑。

　　另一个潜在的问题是Java规范中对类文件规定的64Kb边界。方法体的字节码指令总长度被限制为64Kb。在编织已经很大的类文件（例如，将JSP文件编译为servlet时产生的类文件）时，这可能会导致问题。在处理这个类时，可能会突破64Kb的限制，这就会导致运行时错误。

提议的解决方案

　　对于上面讨论的大多数问题，JVM编织是自然的解决方案。为了理解其原因，我们将查看两个示例。这些示例说明，JVM已经做了执行编织所需的大多数工作：当类被装载时，JVM读取字节码以便建立为java.lang.reflect.* API服务所需的数据。另一个例子是方法调度。现代的JVM将方法或代码块的字节码编译为更高级而且更高效的构造和执行流（在可以应用代码内联的地方进行代码内联）。由于HotSwap API的需要，JRockit JVM（可能还包括其他JVM）还会记录哪个方法调用了其他方法，这样如果在运行时重新定义某个类，那么在所有期望的位置（内联的或非内联的），类中定义的方法体仍然可以被热交换。

　　因此，不必为了编织进一个建议调用而修改字节码，比如说在特定的方法调用之前。JVM实际上可以掌握关于这个建议调用的知识，它会在任何匹配的联结点上对此建议进行调度，然后再调度实际的方法。

　　由于不接触字节码，可以预期到直接的好处，比如：

• 不会由于字节码测试而导致启动开销。
• 对于在任何位置、任何时间、以线性开销添加和删除建议的完全的运行时支持。
• 对建议的反射式调用的隐式支持。
• 不需要占用额外的内存来将类模型复制到某些框架特有的结构。

　　本系列的第二篇文章将详细描述提议的JRockit JVM对AOP的支持。

　　以下代码示例作了总结性说明。它在调用sayHello()方法之前对静态方法advice()进行调度：

public class Hello {

  // -- the sample method to intercept
  public void sayHello() {
    System.out.println("Hello World");
  }

  // -- using the JRockit JVM support for AOP
  static void weave() throws Throwable {
    // match on method name
    StringFilter methodName = new StringFilter(
        "sayHello",
        StringFilter.Type.EXACT
    );

    // match on callee type
    ClassFilter klass = new ClassFilter(
        Hello.class,
        false,
        null
    );

    // advice is a regular method dispatch
    Method advice = Aspect.class.getDeclaredMethod(
        "advice",
        new Class[0]
    );

    // get a JRockit weaver and subscribe the
    // advice to the join point picked out by the filter
    Weaver w = WeaverFactory.createWeaver();

    w.addSubscription(new MethodSubscription(
        new MethodFilter(
            0,
            null,
            klass,
            methodName,
            null,
            null
        ),
        MethodSubscription.InsertionType.BEFORE,
        advice
    ));
  }

  // -- sample code

  static void test() {
    new Hello().sayHello();
  }

  public static void main(String a[])
  throws Throwable {
    weave();
    test();
  }

  // -- the sample aspect

  public static class Aspect {

    public static void advice() {
        System.out.println("About to say:");
    }
  }
}

结束语

　　在Java社区中已经开始流行使用字节码测试来实现中间件领域中的高级技术，比如AOP或者透明式服务插入。但是，几个关键的限制妨碍了字节码测试，而且它的广泛使用将导致更多的问题，影响可伸缩性和可用性。

　　因为字节码测试在某种程度上已经成了在AOP中实现编织的标准方式，所以本文中描述的限制和问题将会妨碍它（可能已经妨碍它了）。

　　我们相信，JVM对AOP的支持是这些问题的自然解决方案。我们将要提供一个已经在JRockit JVM中实现的基于订阅的API，它与JVM方法调度组件紧密集成。本系列中的下一篇文章将更详细地讲解这个API，并且解释如何解决每个问题。