源码分析Spring @Configuration注解如何巧夺天空，偷梁换柱。

前言

回想起五年前的一次面试，面试官问@Configuration注解和@Component注解有什么区别？记得当时的回答是：

• 相同点：@Configuration注解继承于@Component注解，都可以用来通过ClassPathBeanDefinitionScanner装载Spring bean的配置信息。

• 不同点：Component注解为通用组件类模式注解，Configuration注解为配置类模式注解，主要是在做代码分层上的有差别（当然也是从字面意思上理解）。

很显然不是面试官想要到答案，最后还是挂了。回去看了一下注解本身定，Configuration继承于Component，多了个proxyBeanMethods 属性，注释中提到在运行中可以生成子类进行增强，但是类类型必须不是final的,当proxyBeanMethods配置为false的时候不会进行增强。当时也就草率的下了定义，Configuration可以选择是否通过生成代理类进行增强。

进阶

多余的属性是proxyBeanMethods，字面的意思是代理Bean的方法，代理了个什么东西？是如何增强？带着问题写了一段测试代码：

@Component
public class Demo {public static void main(String[] args) {AnnotationConfigApplicationContext annotationConfigApplicationContext =new AnnotationConfigApplicationContext();annotationConfigApplicationContext.register(Demo.class);annotationConfigApplicationContext.refresh();Test test = annotationConfigApplicationContext.getBean(Test.class);System.out.println("spring ioc容器中管理的person对象：" + annotationConfigApplicationContext.getBean(Person.class));for (int i = 0; i < 2; i++) {System.out.println("通过bean作用的方法创建对象：" + test.createUser());}for (int i = 0; i < 2; i++) {System.out.println("通过没用bean作用的方法创建对象：" + test.createUserNoMethodBean());}annotationConfigApplicationContext.close();
}@Configurationpublic static class Test {@Beanpublic Person createUser() {return createUserNoMethodBean();}public Person createUserNoMethodBean(){Person person = new Person();person.setName(UUID.randomUUID().toString());return person;}}public static class Person {private String name;//get set 省略@Overridepublic String toString() {return "Person{" +"name='" + name + '\'' +'}';}}
}

代码输出

spring ioc容器中管理的person对象：Person{name='2a8c8844-c979-4784-942b-af4299d32866'}
通过bean作用的方法创建对象：Person{name='2a8c8844-c979-4784-942b-af4299d32866'}
通过bean作用的方法创建对象：Person{name='2a8c8844-c979-4784-942b-af4299d32866'}
通过没用bean作用的方法创建对象：Person{name='67707608-79bf-44c0-a83a-9ebaa7c17bb1'}
通过没用bean作用的方法创建对象：Person{name='27028430-9f82-4379-993a-6edd884ce145'}

我们调用Test对象创建用户方法，带有bean注解的返回的是同一个对象，并且与注入到spring ioc容器中的person对象是同一个，而且没有通过@Bean注解作用的方法真正执行了。不得不说好神奇。

猜想

我们先做一个大胆的猜想~ 注解Configuration注解proxyBeanMethods默认为true，也就是说默认会进行代理增强。调用通过bean注解的方法时会进行拦截，并且会舍弃调用真正的目标方法。其中会对带有bean的方法进行代理，对不带有bean的方法进行过滤。拦截带有bean方法返回对象时会从spring ioc容器中进行依赖查找并返回该对象。
如图

• 带有bean方法不需要进行执行目标方法，也就是我们的原始方法；
• 我们需要注入我们的BeanFactory对象，来完成我们带有Bean方法依赖查找；
• 需要对我们的方法进行过滤，需要对特定方法进行回调。

源码

由上一章我们熟悉了Spring ioc容器解析注册的流程，ConfigurationClassPostProcessor.class类比较重要，前半部分为BeanDefinitionRegistry逻辑，后半部为配置类的增强。
接下来开始查看对给定BeanFactoryPostProcessor的处理。跟踪源码到ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry(beanfactory);

/*** Prepare the Configuration classes for servicing bean requests at runtime* by replacing them with CGLIB-enhanced subclasses.*///通过 CGLIB 增强的子类来代替配置类来为 bean 请求提供支持
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {int factoryId = System.identityHashCode(beanFactory);if (this.factoriesPostProcessed.contains(factoryId)) {throw new IllegalStateException("postProcessBeanFactory already called on this post-processor against " + beanFactory);}this.factoriesPostProcessed.add(factoryId);if (!this.registriesPostProcessed.contains(factoryId)) {// BeanDefinitionRegistryPostProcessor hook apparently not supported...// Simply call processConfigurationClasses lazily at this point then.processConfigBeanDefinitions((BeanDefinitionRegistry) beanFactory);}enhanceConfigurationClasses(beanFactory);beanFactory.addBeanPostProcessor(new ImportAwareBeanPostProcessor(beanFactory));
}

继续跟踪到ConfigurationClassPostProcessor#enhanceConfigurationClasses(beanFactory)方法中，

public void enhanceConfigurationClasses(ConfigurableListableBeanFactory beanFactory) {StartupStep enhanceConfigClasses = this.applicationStartup.start("spring.context.config-classes.enhance");Map<String, AbstractBeanDefinition> configBeanDefs = new LinkedHashMap<>();for (String beanName : beanFactory.getBeanDefinitionNames()) {BeanDefinition beanDef = beanFactory.getBeanDefinition(beanName);Object configClassAttr = beanDef.getAttribute(ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE);AnnotationMetadata annotationMetadata = null;MethodMetadata methodMetadata = null;if (beanDef instanceof AnnotatedBeanDefinition) {AnnotatedBeanDefinition annotatedBeanDefinition = (AnnotatedBeanDefinition) beanDef;annotationMetadata = annotatedBeanDefinition.getMetadata();methodMetadata = annotatedBeanDefinition.getFactoryMethodMetadata();}if ((configClassAttr != null || methodMetadata != null) && beanDef instanceof AbstractBeanDefinition) {// Configuration class (full or lite) or a configuration-derived @Bean method// -> eagerly resolve bean class at this point, unless it's a 'lite' configuration// or component class without @Bean methods.AbstractBeanDefinition abd = (AbstractBeanDefinition) beanDef;if (!abd.hasBeanClass()) {boolean liteConfigurationCandidateWithoutBeanMethods =(ConfigurationClassUtils.CONFIGURATION_CLASS_LITE.equals(configClassAttr) &&annotationMetadata != null && !ConfigurationClassUtils.hasBeanMethods(annotationMetadata));if (!liteConfigurationCandidateWithoutBeanMethods) {try {abd.resolveBeanClass(this.beanClassLoader);}catch (Throwable ex) {throw new IllegalStateException("Cannot load configuration class: " + beanDef.getBeanClassName(), ex);}}}}//判断BeanDefinition的configurationClass是否为full，然后加入集合后续进行特殊处理if (ConfigurationClassUtils.CONFIGURATION_CLASS_FULL.equals(configClassAttr)) {if (!(beanDef instanceof AbstractBeanDefinition)) {throw new BeanDefinitionStoreException("Cannot enhance @Configuration bean definition '" +beanName + "' since it is not stored in an AbstractBeanDefinition subclass");}else if (logger.isInfoEnabled() && beanFactory.containsSingleton(beanName)) {logger.info("Cannot enhance @Configuration bean definition '" + beanName +"' since its singleton instance has been created too early. The typical cause " +"is a non-static @Bean method with a BeanDefinitionRegistryPostProcessor " +"return type: Consider declaring such methods as 'static'.");}configBeanDefs.put(beanName, (AbstractBeanDefinition) beanDef);}}if (configBeanDefs.isEmpty() || NativeDetector.inNativeImage()) {// nothing to enhance -> return immediatelyenhanceConfigClasses.end();return;}ConfigurationClassEnhancer enhancer = new ConfigurationClassEnhancer();//遍历进行cglib增强子类for (Map.Entry<String, AbstractBeanDefinition> entry : configBeanDefs.entrySet()) {AbstractBeanDefinition beanDef = entry.getValue();// If a @Configuration class gets proxied, always proxy the target classbeanDef.setAttribute(AutoProxyUtils.PRESERVE_TARGET_CLASS_ATTRIBUTE, Boolean.TRUE);// Set enhanced subclass of the user-specified bean classClass<?> configClass = beanDef.getBeanClass();Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);if (configClass != enhancedClass) {if (logger.isTraceEnabled()) {logger.trace(String.format("Replacing bean definition '%s' existing class '%s' with " +"enhanced class '%s'", entry.getKey(), configClass.getName(), enhancedClass.getName()));}beanDef.setBeanClass(enhancedClass);}}enhanceConfigClasses.tag("classCount", () -> String.valueOf(configBeanDefs.keySet().size())).end();

在ConfigurationClassEnhancer类中，我们看到增强的具体实现：

/*** Creates a new CGLIB {@link Enhancer} instance.*///创建cglib的实例。
private Enhancer newEnhancer(Class<?> configSuperClass, @Nullable ClassLoader classLoader) {Enhancer enhancer = new Enhancer();//为增强类设置父类enhancer.setSuperclass(configSuperClass);//为增强类设置接口，该接口继承BeanFactoryAware，在实例化非lazy对象处理中接口回调阶段initializeBean    进行（BeanNameAware  ClassLoaderAware BeanFactoryAware 回调），我们能通过BeanFactoryAware  获取我们beanfactory类。enhancer.setInterfaces(new Class<?>[] {EnhancedConfiguration.class});enhancer.setUseFactory(false);//设置beanfactory字段。方便进行依赖查找enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);enhancer.setStrategy(new BeanFactoryAwareGeneratorStrategy(classLoader));//具体我们可以看到此处配置的filter 也就是特殊方法才会执行回调，否则调用父类目标方法enhancer.setCallbackFilter(CALLBACK_FILTER);enhancer.setCallbackTypes(CALLBACK_FILTER.getCallbackTypes());return enhancer;
}

CALLBACK_FILTER:并不是所有方法进行拦截， 首先需要拦截的是内部调用 @Bean 注解的方法时，进行ioc依赖查找返回；其次是依赖查找依赖的beanfactory字段的赋值；其他方法不进行拦截（当然也可以拦截，直接在调用父类的方法proxy.invokeSuper(obj, args)）;这样多实现不如不实现，没用！！！。

因为我们多个拦截器，所以我们需要进行组合，选出符合条件的拦截器下标。

/*** A {@link CallbackFilter} that works by interrogating {@link Callback Callbacks} in the order* that they are defined via {@link ConditionalCallback}.*/private static class ConditionalCallbackFilter implements CallbackFilter {private final Callback[] callbacks;private final Class<?>[] callbackTypes;//初始化的数据为固定顺序public ConditionalCallbackFilter(Callback[] callbacks) {this.callbacks = callbacks;this.callbackTypes = new Class<?>[callbacks.length];for (int i = 0; i < callbacks.length; i++) {this.callbackTypes[i] = callbacks[i].getClass();}}@Overridepublic int accept(Method method) {//遍历callbacks，首先判断是否符合for (int i = 0; i < this.callbacks.length; i++) {Callback callback = this.callbacks[i];if (!(callback instanceof ConditionalCallback) || ((ConditionalCallback) callback).isMatch(method)) {return i;}}throw new IllegalStateException("No callback available for method " + method.getName());}public Class<?>[] getCallbackTypes() {return this.callbackTypes;}}// The callbacks to use. Note that these callbacks must be stateless.
private static final Callback[] CALLBACKS = new Callback[] {new BeanMethodInterceptor(),new BeanFactoryAwareMethodInterceptor(),NoOp.INSTANCE
};
private static final ConditionalCallbackFilter CALLBACK_FILTER = new ConditionalCallbackFilter(CALLBACKS);

CALLBACKS 根据ConditionalCallbackFilter#accept(method)``方法逻辑，首先会判断是是继承了ConditionalCallback，然后调用isMatch(method)的方法；组合条件中 NoOp.INSTANCE非ConditionalCallback子类与BeanMethodInterceptor和BeanFactoryAwareMethodInterceptor互斥；BeanMethodInterceptor和BeanFactoryAwareMethodInterceptor`互斥。

BeanMethodInterceptor#isMatch(method);源码

@Override
public boolean isMatch(Method candidateMethod) {return (candidateMethod.getDeclaringClass() != Object.class &&!BeanFactoryAwareMethodInterceptor.isSetBeanFactory(candidateMethod) &&BeanAnnotationHelper.isBeanAnnotated(candidateMethod));
}

接下来创建我们目标类的子类，注册子类的回调:

/**
*为派生子类的设置回调。
*/
private Class<?> createClass(Enhancer enhancer) {Class<?> subclass = enhancer.createClass();// Registering callbacks statically (as opposed to thread-local)// is critical for usage in an OSGi environment (SPR-5932)...//CALLBACKS为Enhancer.registerStaticCallbacks(subclass, CALLBACKS);return subclass;
}

CALLBACKS 为数组，

• BeanMethodInterceptor：对于配置类中内部 @Bean 注解的方法的调用将会被拦截器拦截。拦截器的逻辑是判断声明的 Spring bean 在容器中是否已经存在，如果存在则直接返回容器中的 Spring bean。否则真正的配置类的方法创建 Spring bean 实例，避免了多例的出现。主要是解析获取我们beanfactory字段（该字段受益于CALLBACKS第二个元素的赋值），进行依赖查找。

private ConfigurableBeanFactory getBeanFactory(Object enhancedConfigInstance) {//解析BEAN_FACTORY_FIELD beanfactory字段~Field field = ReflectionUtils.findField(enhancedConfigInstance.getClass(), BEAN_FACTORY_FIELD);Assert.state(field != null, "Unable to find generated bean factory field");Object beanFactory = ReflectionUtils.getField(field, enhancedConfigInstance);Assert.state(beanFactory != null, "BeanFactory has not been injected into @Configuration class");Assert.state(beanFactory instanceof ConfigurableBeanFactory,"Injected BeanFactory is not a ConfigurableBeanFactory");return (ConfigurableBeanFactory) beanFactory;
}

• BeanFactoryAwareMethodInterceptor：为我们代理类新增的BEAN_FACTORY_FIELD字段进行赋值。源码如下：

public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {//查找我们的BEAN_FACTORY_FIELD字段Field field = ReflectionUtils.findField(obj.getClass(), BEAN_FACTORY_FIELD);Assert.state(field != null, "Unable to find generated BeanFactory field");//为我们字段进行赋值，args[0]->因为我们BeanFactoryAware接口回调方法为 void setBeanFactory(BeanFactory beanFactory) throws BeansException;只有一个参数~field.set(obj, args[0]);// Does the actual (non-CGLIB) superclass implement BeanFactoryAware?// If so, call its setBeanFactory() method. If not, just exit.//如果父类实现了BeanFactoryAware接口，改方法直接调用父类方法。if (BeanFactoryAware.class.isAssignableFrom(ClassUtils.getUserClass(obj.getClass().getSuperclass()))) {return proxy.invokeSuper(obj, args);}return null;
}

• NoOp.INSTANCE:这个NoOp表示no operator，即什么操作也不做，代理类直接调用被代理的方法不进行拦截。
  配置中当然满足内部bean方法调用时走BeanMethodInterceptor；调用setBeanFactory(BeanFactory beanFactory)时走BeanFactoryAwareMethodInterceptor；其他方法走NoOp.INSTANCE。
  回到我们ConfigurationClassPostProcessor#enhanceConfigurationClasses(beanFactory)方法中，可以看到BeanDefinition的beanClass属性被赋值我们生成增强的代理子类，
  最后来到我们bean的实例化处理方法DefaultListableBeanFactory#preInstantiateSingletons。至此@Configuration的实现原理和我们猜想大致相同。