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

核心提示：面向方面编程（aspect-Oriented PRogramming，AOP）正在软件社区和企业界中获得强大的发展动力，JRockit JVM对AOP的支持，第1部分，自从20世纪90年代Xerox引入了AOP之后，AOP经过研究团体、开源社区和企业界的数次推动和革新，在代表对特定方法M进行调用的字节码指令中，这一信息

　　面向方面编程（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是否应该被编织的唯一办法是，在某种形式的类数据