Java 元编程及其应用

亦凉 2021-05-12 11:50 509阅读 0赞

# 什么是元编程 #

> 元编程是写出编写代码的代码

试想一下，如果那些原本需要我们手动编写的代码,可以自动生成,我们是不是又更多的时间来做更加有意义的事情?有些框架之所以开发效率高,其原因也是因为框架层面,把大量的需要重复编写的代码,采用元编程的方式给自动生成了。

比如经常被Java程序员诟病的大段大段的setter/getter/toString/hashCode/equals方法，这些方法其实在模型字段定义好了之后，这些方法其实基本上就已经标准化了，比如常用的IDE(eclipse,IDEA)都支持自动生成这些方法,这样挺好,可以省掉我们好多精力. 但是这样做的还不够好,当我们尝试去理解一个模型的时候,视线里有大量这些的冗余方法,会增加我们对于模型理解的负担. lombok给出了一个解决方案通过注解的方法,来自动为模型生成setter/getter/toString/hashCode方法,使我们的代码精简了很多。

比如另外一个Java程序员诟病的地方,用mybatis访问数据库,即使我们的对数据库的操作仅仅是简单的增删查改,我们也需要对每一个操作的定义sql,我们需要编写

*  领域模型对象
 *  DAO的interface
 *  mybatis的mapper文件

比如 [mybatis generator][]就可以根据数据库结构自动生成上面这些文件, 他大大减少了初次搭建项目的负担。

但是文件生成了,我么就得维护,我们会往里面加其它东西,比如加字段,增加其它操作. 这样当数据库的表结构有变动之后,我们就要维护所有涉及到的文件,这个工作量其实也不小. 有没有更好的方法?本文后面会提出一种解决方案.

# Java元编程的几种姿势 #

## 1、反射(reflection) ##

### 1）自省 ###

我们要生成代码,我至少得知道我们现有的代码长什么样子吧?

正如,我们要化妆(给自己化妆,亦或是给别人化妆)我们至少得看得清楚我们的容貌,别人的容貌吧.

`reflection`这个名字起得真有意思,把程序的自省比喻成照镜子,对着这个镜子,程序就知道,哟,

*  这是一个`Class`
 *  这个`Class`有几个`Field`
 *  这个`Field`是什么类型的
 *  这个`Field`是否`static`,是否是`final`的
 *  这个`Class`还有几个`Method`
 *  这个`Method`的返回类型是什么
 *  这个`Method`的参数列表类型什么
 *  每个参数有什么注解
 *  …

> 参数的名字在运行时已经擦除了,获取不到

反射的API除了提供了以上的`读`能力之外,还提供了一个动态代理的功能.

### 2）动态代理 ###

所谓动态代理,它的动态其实是相对于静态代理而言的.在静态代理里面,代理对象与被代理对象的类型都实现了同样的接口,这样当客户端持有一个接口对象的时候,就可以用代理的对象来替换这个真实对象,同时这个代理对象就像在扮演真实对象的秘书,很多需要真实对象处理的东西,其实都是这个代理做的.大部分场景下,他会直接把问题转给真实对象处理,同时,他还做了其它事情

*  比如记录一下日志啊
 *  比如`选择性拒绝`啊(我们老板太忙,这个请求我替我们老板拒绝了)
 *  甚至还可以通过请求其它服务,来伪造结果(mock)

所有的这些代理工作的实现,都是在写代码的时候,手动实现好的. 明显,这`很不元编程`

动态代理的神奇之处在于,本来`老板`是没有`秘书`的,只是突然决定要请一个`秘书`,就`临时变了一个秘书出来`,`老板`能做的事情,他都能做(`Proxy.newProxyInstance()`需要传一个接口列表,这个新生成的类,就会实现这些接口)

有了这种`变化能力`,我们不仅仅可以动态变出`AA`的代理`AAProxy`,而且还能动态变出`BB`的代理`BBProxy`,甚至更多. 看出区别了吗?

如果有10个需要代理的类,在静态代理中,我们就需要编写10个代理类;而在动态代理中,我们可以仅需要编写一个实现了`java.lang.reflect.InvocationHandler`接口的类即可.

> 我们编写的不是代码,而是生成代码的代码

甚至更夸张的是,本来公司没`老板`(被代理类),现在决定要一个`老板`,我们描述一下这个老板需要什么能力(实现的`接口`),就能动态的变一个类似于老板的东西(`代理对象`),而这个东西,还挺像个老板的(实现了老板的接口,并且能够符合人们预期工作)

就像[retrofit][]这个项目实现的一样,通过一个接口,以及这个接口上的注解,就能动态生成一个符合预期的,http接口的Java SDK.(代码就不贴了,有兴趣自己到官网参观).我之前,也借鉴这种模式,写了一个公司内部http接口的生成器. 这种编码方式,更加干净,更加直观.

其它使用动态代理技术的项目

*  Spring的基于接口的AOP
 *  [dubbo][] reference对象的生成
 *  …

## 2、字节码增强(bytecode enhancement) ##

我们知道,Java的类是编译成字节码存在class文件中的,类的加载,其实就是字节码被读取,生成Class类的过程.

我们是否能够通过某种途径,改变这个字节码呢?

要回答这个问题,我们可以先反问一句,我们是否有改变一个已经加载了的`Class`的需求呢?还真有,比如我们想给一个类的某些标记了`@Log`注解的方法进行打日志记录,我们想统计一个标记了`@Perf`注解的方法的执行时间. 如果我们无法改变一个类,那么我们就必须在每个类里面加类似的代码,这显然不环保. 由于这是个强需求,如果Java不允许修改意见加载的类,那么Java无疑会被实现了这些feature其它技术所淘汰,基于这个反向推理,由于Java现在还那么火,所以可以推测,Java应该支持这种feature.

### 1）加载时 ###

为了实现上面这种需求,Java5就推出了`java.lang.instrument`并且在jdk6进一步加强.

要实现一个类的转换,我们需要执行如下步骤:

*  就像我们编写Java程序入口`main`方法一样,我们通过编写一个`public static void premain(String agentArgs, Instrumentation inst);`方法
 *  然后再方法体里面注册一个`java.lang.instrument.ClassFileTransformer`
 *  然后实现这个transformer
 *  然后将整个程序打包,并且在`META-INF/MANIFEST.MF`注明实现了premain方法的类名
 *  最终在程序启动的时候,`java -javaagent:myagent.jar`

JVM就会加载myagent.jar中的`META-INF/MANIFEST.MF`, 读取`Premain-Class`的值,并且加载我们的`Premain-class`类,然后在main方法执行之前,执行这个方法,由于我们在方法体重注册了transformer,这样后续一旦有类在加载之前,都会先执行我们的transformer的transform方法,进行字节码增强.

在`java.lang.instrument.ClassFileTransformer`的接口有一个方法：

byte[] transform(  
        ClassLoader         loader,
        String              className,
        Class<?>            classBeingRedefined,
        ProtectionDomain    protectionDomain,
        byte[]              classfileBuffer)
    throws IllegalClassFormatException;

我们可以利用一些字节码增强的类库,对传入的字节码数组进行解析,然后修改,然后序列化成字节码,作为方法结果返回

常用的字节码增强类库

*  ASM
 *  cglib
 *  javassist

其中javassist因为API易于使用,且项目一直活跃,所以推荐使用.

### 2）运行时 ###

Java也可以在类已经加载到内存中的情况,对类进行修改,不过这个修改有个限制,只能修改方法体的实现,不能对类的结构进行修改.

类似的eclipse以及IDEA的动态加载,就是这个原理.

## 3、Annotation Processing ##

运行时或者加载时的字节码增强,虽然牛逼,但是其有个致命性短板,它增加的方法,无法在编译时被代码感知,也就是说,我们在运行时给`MyObj`类增加的方法`getSomeThing(Param param)`,无法在其它源代码中,通过`myObj.getSomeThing(param)`这种方式进行调用,而只能通过反射的方式进行调用,这无疑丑陋了很多.也许Java也是考虑到这种需求,才发明了`Annotation Processing`这种编译过程。

![f178e0f7b8a752ff75950e3a9f1d09cb.png][]

如图所示,Java的编译过程分为三步

1.  Parse & Enter: 这一步主要负责将Java的源代码解析成抽象语法树(AST)
2.  Annotation Processing: 这一步就会执行用户定义的AnnotationProcessing逻辑,生成`新的代码`/资源,然后重复执行过程1,直到没有新的源代码生成
3.  Analyse & Generate: 这一步才是真正的生成字节码的过程

这个编译过程中,我们可以扩展的是,第二部,我们可以自己实现一个`javax.annotation.processing.Processor`类,然后将这个类告诉编译器,然后编译器就会在编译源代码的时候,调用接口的process逻辑,我们就可以在这里生成新的源文件与资源文件!

遗憾的是,编译器并没有显示的API提供给我们,允许我们修改已有class的抽象语法树,也就是说,我们无法在通过`正规途径`在`编译时`给一个类增加成员;这里强调了`正规途径`是因为确认是存在一些非正规途径,可以让我们去修改这棵树. lombok就是这么做的

> lombok是做什么的?
> 
> lombok允许我们通过简易的注解,来自动生成我们模型的getter,setter,constructor,toString等常用方法,可以让我们的模型代码更加干净.

了解了上述的Java的编译过程,我们其实就可以想想,是否可以通过代码生成的方式,来去掉我们平时诟病,却一直难以根除的痛?

基于Annotation Processing的MybatisDAO & mapper文件自动生成

分析

对于一个model而已,常用的操作包括以下几种

*  insert(model)
 *  selectByXXX(model)
 *  countByXXX(model)
 *  updateByXXXAndYYY(model)
 *  deleteByXXX(model)

如果仅仅提供model,是不是就足以生成对应的DAO接口申明以及对应mapper配置?

*  表名: 简单点,可以直接根据模型名来推断,也可以通过注解增加方法,来允许自定义表名
 *  insert/update的字段列表: 直接去模型的字段列表即可
 *  select/update/delete的时候,我们是需要知道我们根据什么字段进行过滤,这个信息我们是需要告诉`Processor`的,因为我们可以考虑增加一个注解`@Index`来告诉`Processor`,这些字段是索引字段,可以根据这些字段进行过滤

基于上面分析,我们有了以下大致思路

*  我们首先定义一个`@DAO`,用于标记我们的模型class
 *  然后定义一个`@Index`,用于标记模型的字段
 *  然后定义一个`DAOGeneratorProcessor`继承自`AbstractProcessor`,并且申明支持`DAO`
    
     *  process方法的实现中,我们会分析模型的语法书,提取出类名,字段列表
     *  找出标记了`@Index`的字段列表,然后对涉及到过滤的方法生成所有的组合,比如
        
         *  selectByOrderAndSellerId
         *  selectBySellerId
         *  selectByOrderNo
     *  生成对应的接口声明,以及mapper文件

> 这种组合索引字段,生成方法名的方式比较粗暴,比如如果有N个@Index字段,对应的selectByXXX方法就会有`2**N`,大部分场景下,这个N都不会超过3个,比如订单表,就是orderno,商品表,就是itemid

由于annotation是编译器的扩展,这一点体验比较好,一旦我们定义好了模型(比如Order.class),然后编译模型,我们就可以在代码其它地方,就可以直接引用`OrderDAO`这个对象类(这个类是生成的哦),可以回顾一下Java的编译过程.

实践

实践中,虽然生成的DAO可以覆盖我们大部分的用例,但是并不能覆盖所有我们的需求场景,因此,我们推荐将生成的DAO统一叫做BasicDAO,这样有些个性化的需求,我们仍然可以同自己书写SQL的方式来自定义,这样在解决重复冗余的前提下,也能很好的适应复杂的业务场景.

# 总结 #

Java本身是一门静态语言,程序从源代码,到运行的程序,中间会经历很多的环节.

这些环节都可以作为我们元编程的切入点,不同的环节,可以发挥不同的威力,使用得当,可以帮助我们提供生产力的同时,也能很好优化我们的代码性能。

[mybatis generator]: https://github.com/mybatis/generator
[retrofit]: http://square.github.io/retrofit/
[dubbo]: http://dubbo.io/
[f178e0f7b8a752ff75950e3a9f1d09cb.png]: /images/20210511/765305ae745d4634861d99a69d5ab7db.png