JRockit JVM对AOP的支持

　　以上代码定义了一个方面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。

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

测试是低效率的

　　编织的实际测试部分往往非常消耗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