运行时字节码生成性能适用于较大的方法和类

Question

有许多用于运行时字节码生成的库，例如ASM，Javassist，CGLib和BCEL等等。所有这些工具都能够动态地操作java字节码，并且与javac编译器等工具不同。

我知道有一些很好的理由来生成字节码并在运行时将它们加载到ClassLoader中。我的问题是，在为非常大的java方法或类生成字节码时，这些工具是否存在性能问题或问题。

一个场景可能是一个长时间运行的应用程序，生成的字节码将是微不足道的但是连续的（它将继续生成字节码和/或类，并将它们连续加载/卸载到类加载器中）。

有一个类似的问题here，但没有一个答案解释任何有关表现的问题。我是否可以找到关于这个问题的学术文章的链接？

Answer 1

在现实世界中，您将使用哪个框架并不重要。除非您计划生成数百万个新方法并在运行时加载它们，否则从一开始就不错。

Answer 2

我认为ASM是最有选择性的两个原因。首先，它具有所有JVM功能的最新功能，其次，其访问者模式API非常高效。我认为，第二点是解决您的性能问题。

Answer 3

在运行时生成类并不比用内容填充字节数组更有意义。此时，JVM被告知将此内容解释为Java类，它与从硬盘驱动器加载的预编译类添加到运行时环境的方式没有区别。

由于填充字节数组很简单，因此性能取决于确定内容的规则。解析源代码并验证其正确性是一项昂贵的任务。另一方面，根据硬编码规则生成代码，例如，通过调用单个指定的方法（如lambda实例化工作）来完成接口，通常比从硬盘驱动器加载等效代码要快得多。将此类规则作为运行时字节码生成的典型用例。

但在考虑性能之前，你应该问问自己为什么要考虑动态字节码生成。在大多数现实场景中，这个问题的答案已经包含了对性能是否相关的问题的答案，或者为什么期望通过生成代码来改进性能。