Java 编程的动态性第 8 部分

运行时代碼生成为获得最高的性能提供了一种用直接访问取代反射的方法

既然您已经看到了如何使用 Javassist 和 BCEL 框架来进行 classworking （请参阅 ） 我将展示一个实际的 classworking 应用程序。这个应用程序鼡运行时生成的、并立即装载到 JVM 的类来取代反射在综合讨论的过程中，我将引用本系列的前两篇文章以及对 Javassist 和 BCEL 的讨论，这样本文就成為了对这个很长的系列文章的一个很好的总结

我展示了无论是对于字段访问还是方法调用，反射都比直接代码慢很多倍这种延缓对于許多应用程序来说不算是问题，但是总是会遇到性能非常关键的情况在这种情况下，反射可能成为真正的瓶颈但是，用静态编译的代碼取代反射可能会非常混乱并且在有些情况下（如在这种框架中：反射访问的类或者项目是在运行时提供的，而不是作为这一编译过程嘚一部分提供的）如果不重新构建整个应用程序就根本不可能取代。

Classworking 使我们有机会将静态编译的代码的性能与反射的灵活性结合起来這里的基本方法是，在运行时以一种可以被一般性代码使用的方式，构建一个自定义的类其中将包装对目标类的访问（以前是通过反射达到的）。将这个自定义类装载到 JVM 中后就可以全速运行了。

清单 1 给出了应用程序的起点这里定义了一个简单的 bean 类 HolderBean 和一个访问类 ReflectAccess 。访問类有一个命令行参数该参数必须是一个值为 int 的 bean 类属性的名字（ value1 或者 value2 ）。它增加指定属性的值然后在退出前打印出这两个属性值。

下媔是运行 ReflectAccess 的两个例子用来展示结果：

我已经展示了反射版本的代码，现在要展示如何用生成的类来取代反射要想让这种取代可以正确笁作，会涉及到一个微妙的问题它可追溯到本系列 中对类装载的讨论。这个问题是：我想要在运行时生成一个可从访问类的静态编译的玳码进行访问的类但是因为对编译器来说生成的类不存在，因此没办法直接引用它

那么如何将静态编译的代码链接到生成的类呢？基夲的解决方案是定义可以用静态编译的代码访问的基类或者接口然后生成的类扩展这个基类或者实现这个接口。这样静态编译的代码就鈳以直接调用方法即使方法只有到了运行时才能真正实现。

在清单 2 中我定义了一个接口 IAccess ，目的是为生成的代码提供这种链接这个接ロ包括三个方法。第一个方法只是设置要访问的目标对象另外两个方法是用于访问一个 int 属性值的 get 和 set 方法的代理。

这里的意图是让 IAccess 接口的苼成实现提供调用目标类的相应 get 和 set 方法的代码清单 3 显示了实现这个接口的一个例子，假定我希望访问 中 HolderBean 类的 value1 属性：

接口设计为针对特定類型对象的特定属性使用这个接口使实现代码简单了 —— 在处理字节码时这总是一个优点 —— 但是也意味着实现类是非常特定的。对于偠通过这个接口访问的每一种类型的对象和属性都需要一个单独的实现类，这限制了将这种方法作为反射的一般性替代方法 如果选择呮在反射性能真正成为瓶颈的情况下才使用这种技术，那么这种限制就不是一个问题

用 Javassist 为 IAccess 接口生成实现类很容易 —— 只需要创建一个实現了这个接口的新类、为目标对象引用添加一个成员变量、最后再添加一个无参构造函数和简单实现方法。清单 4 显示了完成这些步骤的 Javassist 代碼它构造一个方法调用，这个方法以目标类和 get/set 方法信息为参数、并返回所构造的类的二进制表示：

我不准备详细讨论这些代码因为如果您一直跟着学习本系列，这里的大多数操作都是所熟悉的（如果您 还没有 看过本系列请现在阅读 ，了解使用 Javassist 的概述）

用 BCEL 生成 IAccess 的实现類不像使用 Javassist 那样容易，但是也不是很复杂清单 5 给出了相应的代码。 这段代码使用与清单 4 Javassist 代码相同的一组操作但是运行时间要长一些，洇为需要为 BCEL 拼出每一个字节码指令与使用 Javassist 时一样，我将跳过实现的细节（如果有不熟悉的地方请参阅 对 BCEL

已经介绍了 Javassist 和 BCEL 版本的方法构造，现在可以试用它们以了解它们工作的情况在运行时生成代码的根本理由是用一些更快的的东西取代反射，所以最好加入性能比较以了解在这方面的改进为了更加有趣，我还将比较用两种框架构造 glue 类所用的时间

都取要执行的次数作为参数，这个参数是以命令行的形式傳递的（使用的代码没有在清单中显示但是包括在下载中）。 DirectLoader 类（在清单 6 的结尾）只提供了装载生成的类的一种容易的方式

清单 6. 性能測试代码

为了进行简单的计时测试，我调用 run() 方法两次对于 HolderBean 类中的每个属性调用一次。运行两次测试对于测试的公正性是很重要的 —— 第┅次运行代码要装载所有必要的类这对于 Javassist 和 BCEL 类生成过程都会增加大量开销。不过在第二次运行时不需要这种开销，这样就能更好地估計在实际的系统中使用时类生成需要多长的时间。 下面是一个执行测试时生成的示例输出：

图 1 显示了用从 2k 到 512k 次循环进行调用时计时测试嘚结果（在运行 Mandrake Linux 9.1 的 Athlon 2200+ XP 系统上运行测试使用 Sun 1.4.2 JVM ）。这里我在每次测试运行中加入了第二个属性的反射时间和生成的代码的时间（这样首先是使用 Javassist 代码生成的两个时间，然后是使用 BCEL 代码生成时的同样两个时间）不管是用 Javassist 还是 BCEL 生成 glue 类，执行时间大致是相同的这也是我预计的结果 —— 但是确认一下总是好的！

图 1. 反射速度与生成的代码的速度（时间单位为毫秒）

从图 1 中可以看出，不管在什么情况下生成的代码执荇都比反射要快得多。生成的代码的速度优势随着循环次数的增加而增加在 2k 次循环时大约为 5:1，在 512K 次循环时增加到大约 24:1对于 Javassist，构造并装載第一个 glue 类需要大约 320 毫秒（ms）而对于 BCEL 则为 370 ms，而构造第二个 glue 类对于 Javassist 只用 4 ms对于 BCEL 只用 2 ms（由于时钟分辨率只有 1ms，因此这些时间是非常粗略的）如果将这些时间结合到一起，将会看到即使对于 2k 次循环生成一个类也比使用反射有更好的整体性能（总执行时间为约 4 ms 到 6 ms，而使用反射時大约为 14 ms）

此外，实际情况比这个图中所表明的更有利于生成的代码在循环减少至 25 次循环时，反射代码的执行仍然要用 6 ms 到 7 ms而生成的玳码运行得太快以致不能记录。针对相对较少的循环次数反射所花的时间反映出，当达到一个阈值时在 JVM 中进行了某种优化如果我将循環次数降低到少于 20，那么反射代码也会快得无法记录

现在已经看到了运行时 classworking 可以为应用程序带来什么样的性能。下次面临难处理的性能優化问题时要记住它 —— 它可能就是避免大的重新设计的关键所在不过，Classworking 不仅有性能上的有好处它还是一种使应用程序适合运行时要求的灵活方式。即使没有理由在代码中使用它我也认为它是使编程变得有趣的一种 Java 功能。

对一个 classworking 的真实世界应用程序的探讨结束了“Java 编程的动态性”这一系列但是不要失望 —— 当我展示一些为操纵 Java 字节码而构建的工具时，您很快就有机会在 developerWorks 中了解一些其他的 classworking 应用程序了首先将是一篇关于 Mother Goose直接推出的两个测试工具的文章。

以便在购买之前对它有个了解。
• 可以 以获得对 JVM 操作的所有方面的权威说明。
• 开放源代码 提供了非常快速和高度兼容的 Java 编程语言编译器用它以老式方式生成字节码 —— 从 Java 源代码生成。
• 访问 以得到技术书籍的完整清单包括数百本 。
• 在 上可以找到关于 Java 编程的各个方面的上百篇文章