FactoryBean模式剖析
FactoryBean也是向容器提供Bean的一种方式，如最常见的SqlSessionFactoryBean就是这么一个大代表，因为它比较常用，并且这里也作为此拦截器一个单独的执行分支，所以很有必要研究一番。
执行此分支逻辑的条件是：容器内已经存在&beanName和beanName两个Bean。执行的方式是：使用enhanceFactoryBean()方法对FactoryBean进行增强。
ConfigurationClassEnhancer： // 创建一个子类代理，拦截对getObject()的调用，委托给当前的BeanFactory // 而不是创建一个新的实例。这些代理仅在调用FactoryBean时创建 // factoryBean：从容器内拿出来的那个已经存在的工厂Bean实例（是工厂Bean实例） // exposedType：@Bean标注的方法的返回值类型 private Object enhanceFactoryBean(Object factoryBean, Class<?> exposedType, ConfigurableBeanFactory beanFactory, String beanName) { try { // 看看Spring容器内已经存在的这个工厂Bean的情况，看看是否有final Class<?> clazz = factoryBean.getClass(); boolean finalClass = Modifier.isFinal(clazz.getModifiers()); boolean finalMethod = Modifier.isFinal(clazz.getMethod("getObject").getModifiers()); // 类和方法其中有一个是final，那就只能看看能不能走接口代理喽 if (finalClass || finalMethod) { // @Bean标注的方法返回值若是接口类型 尝试走基于接口的JDK动态代理 if (exposedType.isInterface()) { // 基于JDK的动态代理 return createInterfaceProxyForFactoryBean(factoryBean, exposedType, beanFactory, beanName); } else { // 类或方法存在final情况，但是呢返回类型又不是 return factoryBean; } } } catch (NoSuchMethodException ex) { // 没有getObject()方法 很明显，一般不会走到这里 } // 到这，说明以上条件不满足：存在final且还不是接口类型 // 类和方法都不是final，生成一个CGLIB的动态代理 return createCglibProxyForFactoryBean(factoryBean, beanFactory, beanName); }
步骤总结：
1.拿到容器内已经存在的这个工厂Bean的类型，看看类上、getObject()方法是否用final修饰了
2.但凡只需有一个被final修饰了，那注定不能使用CGLIB代理了喽，那么就尝试使用基于接口的JDK动态代理：
- 若你标注的@Bean返回的是接口类型（也就是FactoryBean类型），那就ok，使用JDK创建个代理对象返回
- 若不是接口（有final又还不是接口），那老衲无能为力了：原样return返回
3.若以上条件不满足，表示一个final都木有，那就统一使用CGLIB去生成一个代理子类。大多数情况下，都会走到这个分支上，代理是通过CGLIB生成的
说明：无论是JDK动态代理还是CGLIB的代理实现均非常简单，就是把getObject()方法代理为使用beanFactory.getBean(beanName)去获取实例（要不代理掉的话，每次不就执行你getObject()里面的逻辑了麽，就又会创建新实例啦~）
需要明确，此拦截器对FactoryBean逻辑处理分支的目的是：确保你通过方法调用拿到FactoryBean后，再调用其getObject()方法（哪怕调用多次）得到的都是同一个示例（容器内的单例）。因此需要对getObject()方法做拦截嘛，让该方法指向到getBean()，永远从容器里面拿即可。
这个拦截处理逻辑只有在@Bean方法调用时才有意义，比如parent()里调用了son()这样子才会起到作用，否则你就忽略它吧~
针对于此，下面给出不同case下的代码示例，加强理解。
代码示例（重要）
准备一个SonFactoryBean用于产生Son实例：
public class SonFactoryBean implements FactoryBean<Son> { @Override public Son getObject() throws Exception { return new Son(); } @Override public Class<?> getObjectType() { return Son.class; } }
并且在配置类里把它放好：
@Configuration public class AppConfig { @Bean public FactoryBean<Son> son() { SonFactoryBean sonFactoryBean = new SonFactoryBean(); System.out.println("我使用@Bean定义sonFactoryBean：" + sonFactoryBean.hashCode()); System.out.println("我使用@Bean定义sonFactoryBean identityHashCode：" + System.identityHashCode(sonFactoryBean)); return sonFactoryBean; } @Bean public Parent parent(Son son) throws Exception { // 根据前面所学，sonFactoryBean肯定是去容器拿 FactoryBean<Son> sonFactoryBean = son(); System.out.println("parent流程使用的sonFactoryBean：" + sonFactoryBean.hashCode()); System.out.println("parent流程使用的sonFactoryBean identityHashCode：" + System.identityHashCode(sonFactoryBean)); System.out.println("parent流程使用的sonFactoryBean：" + sonFactoryBean.getClass()); // 虽然sonFactoryBean是从容器拿的，但是getObject()你可不能保证每次都返回单例哦~ Son sonFromFactory1 = sonFactoryBean.getObject(); Son sonFromFactory2 = sonFactoryBean.getObject(); System.out.println("parent流程使用的sonFromFactory1：" + sonFromFactory1.hashCode()); System.out.println("parent流程使用的sonFromFactory1：" + sonFromFactory2.hashCode()); System.out.println("parent流程使用的son和容器内的son是否相等：" + (son == sonFromFactory1)); return new Parent(sonFromFactory1); } }
运行程序：
@Bean public static void main(String[] args) { ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class); SonFactoryBean sonFactoryBean = context.getBean("&son", SonFactoryBean.class); System.out.println("Spring容器内的SonFactoryBean：" + sonFactoryBean.hashCode()); System.out.println("Spring容器内的SonFactoryBean：" + System.identityHashCode(sonFactoryBean)); System.out.println("Spring容器内的SonFactoryBean：" + sonFactoryBean.getClass()); System.out.println("Spring容器内的Son：" + context.getBean("son").hashCode()); }
输出结果：
我使用@Bean定义sonFactoryBean：313540687 我使用@Bean定义sonFactoryBean identityHashCode：313540687 parent流程使用的sonFactoryBean：313540687 parent流程使用的sonFactoryBean identityHashCode：70807318 parent流程使用的sonFactoryBean：class com.yourbatman.fullliteconfig.config.SonFactoryBean$$EnhancerBySpringCGLIB$$1ccec41d parent流程使用的sonFromFactory1：910091170 parent流程使用的sonFromFactory1：910091170 parent流程使用的son和容器内的son是否相等：true Spring容器内的SonFactoryBean：313540687 Spring容器内的SonFactoryBean：313540687 Spring容器内的SonFactoryBean：class com.yourbatman.fullliteconfig.config.SonFactoryBean Spring容器内的Son：910091170
结果分析：
达到了预期的效果：parent在调用son()方法时，得到的是在容器内已经存在的SonFactoryBean基础上CGLIB字节码提升过的实例，拦截成功，从而getObject()也就实际是去容器里拿对象的。
通过本例有如下小细节需要指出：
- 原始对象和代理/增强后（不管是CGLIB还是JDK动态代理）的实例的.hashCode()以及.equals()方法是一毛一样的，但是identityHashCode()值（实际内存值）不一样哦，因为是不同类型、不同实例，这点请务必注意
- 最终存在于容器内的仍旧是原生工厂Bean对象，而非代理后的工厂Bean实例。毕竟拦截器只是拦截了@Bean方法的调用来了个“偷天换日”而已~
- 若SonFactoryBean上加个final关键字修饰，根据上面讲述的逻辑，那代理对象会使用JDK动态代理生成喽，形如这样（本处仅作为示例，实际使用中请别这么干）：
/
public final class SonFactoryBean implements FactoryBean<Son> { ... }
再次运行程序，结果输出为：执行的结果一样，只是代理方式不一样而已。从这个小细节你也能看出来Spring对代理实现上的偏向：优先选择CGLIB代理方式，JDK动态代理方式用于兜底。
... // 使用了JDK的动态代理 parent流程使用的sonFactoryBean：class com.sun.proxy.$Proxy11 ...
提示：若你标注了final关键字了，那么请保证@Bean方法返回的是FactoryBean接口，而不能是SonFactoryBean实现类，否则最终无法代理了，原样输出。因为JDK动态代理和CGLIB都搞不定了嘛~
在以上例子的基础上，我给它“加点料”，再看看效果呢：
使用BeanDefinitionRegistryPostProcessor提前就放进去一个名为son的实例：
// 这两种方式向容器扔bd or singleton bean都行 我就选择第二种喽 // 注意：此处放进去的是BeanFactory工厂，名称是son哦~~~ 不要写成了&son @Component public class SonBeanDefinitionRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor { @Override public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException { // registry.registerBeanDefinition("son", BeanDefinitionBuilder.rootBeanDefinition(SonFactoryBean.class).getBeanDefinition()); } @Override public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException { SonFactoryBean sonFactoryBean = new SonFactoryBean(); System.out.println("初始化时，注册进容器的sonFactoryBean：" + sonFactoryBean); beanFactory.registerSingleton("son", sonFactoryBean); } }
再次运行程序，输出结果：
初始化时最早进容器的sonFactoryBean：2027775614 初始化时最早进容器的sonFactoryBean identityHashCode：2027775614 parent流程使用的sonFactoryBean：2027775614 parent流程使用的sonFactoryBean identityHashCode：1183888521 parent流程使用的sonFactoryBean：class com.yourbatman.fullliteconfig.config.SonFactoryBean$$EnhancerBySpringCGLIB$$1ccec41d parent流程使用的sonFromFactory1：2041605291 parent流程使用的sonFromFactory1：2041605291 parent流程使用的son和容器内的son是否相等：true Spring容器内的SonFactoryBean：2027775614 Spring容器内的SonFactoryBean：2027775614 Spring容器内的SonFactoryBean：class com.yourbatman.fullliteconfig.config.SonFactoryBean Spring容器内的Son：2041605291
效果上并不差异，从日志上可以看到：你配置类上使用@Bean标注的son()方法体并没执行了，而是使用的最开始注册进去的实例，差异仅此而已。
为何是这样的现象？这就不属于本文的内容了，是Spring容器对Bean的实例化、初始化逻辑，本公众号后面依旧会采用专栏式讲解，让你彻底弄懂它。当前有兴趣的可以先自行参考DefaultListableBeanFactory#preInstantiateSingletons的内容~
Lite模式下表现如何？
Lite模式下可没这些“加强特性”，所以在Lite模式下（拿掉@Configuration这个注解便可）运行以上程序，结果输出为：
我使用@Bean定义sonFactoryBean：477289012 我使用@Bean定义sonFactoryBean identityHashCode：477289012 我使用@Bean定义sonFactoryBean：2008966511 我使用@Bean定义sonFactoryBean identityHashCode：2008966511 parent流程使用的sonFactoryBean：2008966511 parent流程使用的sonFactoryBean identityHashCode：2008966511 parent流程使用的sonFactoryBean：class com.yourbatman.fullliteconfig.config.SonFactoryBean parent流程使用的sonFromFactory1：433874882 parent流程使用的sonFromFactory1：572191680 parent流程使用的son和容器内的son是否相等：false Spring容器内的SonFactoryBean：477289012 Spring容器内的SonFactoryBean：477289012 Spring容器内的SonFactoryBean：class com.yourbatman.fullliteconfig.config.SonFactoryBean Spring容器内的Son：211968962
结果解释我就不再啰嗦，有了前面的基础就太容易理解了。
为何是@Scope域代理就不用处理？
要解释好这个原因，和@Scope代理方式的原理知识强相关。限于篇幅，本文就先卖个关子~
关于@Scope我个人觉得足够用5篇以上文章专题讲解，虽然在Spring Framework里使用得比较少，但是在理解Spirng Cloud的自定义扩展实现上显得非常非常有必要，所以你可关注我公众号，会近期推出相关专栏的。
总结
关于Spring配置类这个专栏内容，讲解到这就完成99%了，毫不客气的说关于此部分知识真正可以实现“横扫千军”，据我了解没有解决不了的问题了。
当然还剩下1%，那自然是缺少一篇总结篇喽：在下一篇总结篇里，我会用图文并茂的方式对Spring配置类相关内容的执行流程进行总结，目的是让你快速掌握，应付面试嘛。
