Spring关于@Configuration配置处理流程

@Configuration配置处理流程解析

AnnotationConfigApplicationContext基于注解配置

Spring通过上下文应用AnnotationConfigApplicationContext提供基于注解配置能力，启动过程中通过ConfigurationClassPostProcessor在执行Bean定义注册后处理器阶段解析@Configuration、@Bean、@Import等注解，完成Bean声明定义和注册到容器注册器中。本文简述Spring容器启动流程对配置类@Configuration处理过程，理解Spring应用如何实现基于@Configuration配置注册。

ApplicationContext启动刷新流程

Spring容器启动流程AbstractApplicationContext#refresh，列举几个关键阶段（感兴趣同学自行debug）：

• obtainFreshBeanFactory，获取Bean工厂。
• prepareBeanFactory，准备工作，设置系统相关Bean定义等。
• postProcessBeanFactory，设置Bean工厂后处理。
• invokeBeanFactoryPostProcessors，执行Bean工厂后置处理器，按Bean定义注册器后处理，Bean工厂后置处理顺序执行。
• registerBeanPostProcessors，注册Bean后处理器。
• initMessageSource、initApplicationEventMulticaster，初始化国际化消息和Spring事件广播处理器。
• registerListeners，注册监听器。
• finishBeanFactoryInitialization，固化配置，完成单例非延迟初始化对象实例化。

Spring关于@Configuration解析处理流程

上面第4点，Spring可以通过自定义Bean定义后置处理，自定义解析Bean定义规则并完成Bean定义注册到Spring容器中，@Configuration就是通过bean定义注册后置处理器ConfigurationClassPostProcessor实现，关键处理步骤如下（感兴趣同学自行debug）：

ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry，Bean定义后置处理器执行入口。
ConfigurationClassPostProcessor#processConfigBeanDefinitions，通过扫描应用已注册配置，引导扫描或导入其他候选配置类。
ConfigurationClassParser#parse，解析每一个配置类，按如下顺序处理，具体代码见：
ConfigurationClassParser#doProcessConfigurationClass
1）、获取配置类内部定义的成员类，即静态内部类和实例内部类，如果内部成员类为配置类，则递归处理内部成员类。
2）、处理配置类上面@PropertySource注解，属性文件注入处理。
3）、扫描@ComponentScan @ComponentScans指定路径下Component类（ComponentScanAnnotationParser#parse），如果扫描类为配置类，则递归处理扫描到的类。
4）、处理@Import，导入指定配置类，导入方式分ImportSelector，ImportBeanDefinitionRegistrar和processConfigurationClass。
5）、处理@ImportResource，导入指定配置资源文件。
6）、处理配置类内部定义的@Bean methods
7）、处理default methods on interfaces
8）、处理superClass
ConfigurationClassBeanDefinitionReader#loadBeanDefinitions，加载3解析出来@Bean，对于静态方法Bean和实例方法Bean定义区别，需要关注ConfigurationClassBeanDefinitionReader#loadBeanDefinitionsForBeanMethod。

那些年被忽略问题

基于对配置类@Configuration处理流程理解，试下是否能正确回答下面两个问题：问题 1：@Configuration配置类实例方法声明@Bean和静态方法声明@Bean有什么区别，对应用启动有产生什么影响？样例代码如下：

@Configuration
public class UserConfiguration {
	@Bean
	public static UserService userService() {
		return new UserService();
	}
	/*@Bean
	public UserService userService() {
		return new UserService();
	}*/
}
@Data
public class UserService {
	public String sayHello() {
		return "hello";
	}
}

解析 1：从@Configuration解析处理流程可以知道，@Bean方法在ConfigurationClassBeanDefinitionReader#loadBeanDefinitions中通过包装成工厂方法去声明Bean定义，实例方法调用需要依赖于类实例对象，故会触发类实例化，而静态方法不需要依赖于实例对象，故不会触发类实例化。故如果是类实例方法声明@Bean，会导致工厂配置类过早实例化，从会引起不可预期异常。关于这点，Spring官方明确说明：https://docs.spring.io/spring-framework/reference/core/beans/java/composing-configuration-classes.html

• @Configuration配置类依赖应该简单，因为配置类实例化可能会提前，依赖注入关系会导致非预期异常。
• @Configuration如果有定义bean工厂后处理器和bean后处理器，应该声明为静态@Bean方法，避免导致配置类过早实例化。

问题 2： @Configuration配置类内部实例类和内部静态类内声明Bean，Bean实例化顺序是什么？样例代码如下：

@Configuration
public class UserOuterConfiguration {
	@Bean
	public UserService userService1() {
		return new UserService("userService1");
	}
	@Configuration
	public static class UserInnerConfiguration {
		@Bean
		public UserService userService2() {
			return new UserService("userService2");
		}
	}
}
@Data
@AllArgsConstructor
public static class UserService {
	private String name;
	public String sayHello() {
		return "hello";
	}
}

解析2：在组件扫描ComponentScan处理候选Configuration，会扫描指定包名下的配置类，按名称字典序排序。这个会让内部配置类优先与配置类处理，bean实例化顺序依赖于bean注册器里面注册的顺序，所以在不存在依赖关系，即没有如@Autoware @DependsOn @Lazy等会影响bean实例化顺序和Import导入配置类等改变某个配置处理顺序前提下，内部静态配置类定义Bean的实例化会优先于外部配置类定义Bean实例化。

到此这篇关于Spring关于@Configuration配置处理流程解析的文章就介绍到这了,更多相关Spring @Configuration配置内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！