面向方面编程（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）就是将方面和常规的面向对象应用程序“织”成一个单元（单个应用程序）的过程。
编织可以在不同时期进行：
这个过程还能以多种不同方式进行：
源代码编织受到一定的限制，所有源代码必须可用并提供给编织器，这样才能应用方面。这就导致某些目标不可能实现，例如实现通用的监视服务。编译时编织也受到同一问题的困扰：在编译后进行部署之前，需要把将部署的所有字节码准备好。
本系列文章全面介绍了字节码编织和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非常强大，但是它在以下这些方面限制了可用性和可伸缩性：
另外，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[1] [2] [3] [4] 下一页