声明:本文若有任何纰漏、错误,还请不吝指出!
@Configuration
注解在 SpringBoot
中作用很大,且不说 SpringBoot
中的外部化配置,一些第三方组件也是通过这个注解完成整合的,常用的比如说 mybatis
,就是利用了 @Configuration
这个注解来实现的。
在注解类中,还可以使用 @Bean
的方式向 Spring
容器中,注入一些我们自定义的组件。
在 SpringBoot
中各种 Enable
又是如何实现的?和 @Configuration
又有什么联系呢?
这就要了解 Spring
是怎么对待被 @Configuration
所注解的类。
SpringBoot 2.2.6RELEASE
Spring 5.2.5.RELEASE
注解依附于具体的 Java
类,所以如果想获取注解的信息,必须先将类加载进来,才能从 Class
对象获取到其注解元信息。
好在 Spring
容器启动之前,已经把所有需要加载的Bean,封装成一个 BeanDefinition
对象,最终注册到 BeanDefinitionRegistry
中。
BeanDefinition
包含了一个 Bean
所有的信息,自然也包含了它的元注解信息。
有了这个就能轻而易举的获取到标注有 @Configuration
注解的 BeanDefinition
,从而去处理这个配置类拥有的各种配置信息。
有了 BeanDefinition
之后,下面一步就是要进行Bean的实例化了。如果一个 Bean
被实例化后,就没有可操作的机会了,因此 Spring
在 Bean
的实例化前预留了一些自定义的处理时机。
BeanFactoryPostProcessor
就是这样的一个功能,用于在 Bean
实例化之前,做一些其他的处理操作。
对配置类的处理,也正是利用了这一预留点。
处理配置类,第一步就要从茫茫的 BeanDefinition
中,找出哪些是配置类。
容器开始启动之前的一些准备动作,这里不说明,主要是扫描 classpath
,然后将生成 BeanDefinition
。
直接从容器的启动开始简单下调用栈
Spring容器真正开始启动的是从这里开始的 org.springframework.context.support.AbstractApplicationContext#refresh
,在这个方法中,会去执行所有的 BeanFactoryPostProcessor
。
通过一个委托类 org.springframework.context.support.PostProcessorRegistrationDelegate
,执行所有的 BeanFactoryPostProcessor
后置处理逻辑。
BeanFactoryPostProcessor
有一个子接口是 BeanDefinitionRegistryPostProcessor
,这个接口的主要作用就是在其他后置处理执行之前,额外注册一些 BeanDefinition
进来。
想想在配置类中使用的 @Import
和 @Bean
,就可以猜到,这些注解的处理就是由这个处理器进行处理的。
BeanDefinitionRegistryPostProcessor
和 BeanFactoryPostProcessor
是放到一起处理的,只不过 BeanDefinitionRegistryPostProcessor
的执行时机,早于 BeanFactoryPostProcessor
的执行时机。
// org.springframework.context.support.PostProcessorRegistrationDelegate public static void invokeBeanFactoryPostProcessors( ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) { Set<String> processedBeans = new HashSet<>(); // 如果BeanFactory同时又是一个BeanDefinitionRegistry的话 // 例如 DefaultListaleBeanFactory if (beanFactory instanceof BeanDefinitionRegistry) { BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory; List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>(); List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>(); // 如果有直接注册到Context的后置处理器, // 先执行直接添加到ApplicationContext的BeanDefinitionRegistryPostProcessor处理器 for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) { if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) { BeanDefinitionRegistryPostProcessor registryProcessor = (BeanDefinitionRegistryPostProcessor) postProcessor; // 执行BeanDefinitionRegistryPostProcessor处理器 registryProcessor.postProcessBeanDefinitionRegistry(registry); // BeanDefinitionRegistryPostProcessor同时又是一个BeanFactoryPostProcessor // 待所有的BeanDefinitionRegistryPostProcessor执行完后,再来执行它 registryProcessors.add(registryProcessor); } else { // 加入到BeanFactoryPostProcessor处理器集合中,待所有的BeanDefinitionRegistryPostProcessor执行完后,来执行它 regularPostProcessors.add(postProcessor); } } List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>(); // 对从BeanDefinitionRegistry中的BeanDefinition做后置处理 // 先执行被@PriorityOrdered注解的BeanDefinitionRegistryPostProcessor // 并且按排序大小进行优先级排序 // 根据类型,从BeanDefinitionRegistry中查找出所有的BeanDefinitionRegistryPostProcessor的是实现类,及子类 String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false); for (String ppName : postProcessorNames) { // 使用@PriorityOrdered注解的先查找出来 if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) { currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class)); processedBeans.add(ppName); } } // 按编号大小排序,升序排列 sortPostProcessors(currentRegistryProcessors, beanFactory); registryProcessors.addAll(currentRegistryProcessors); // 执行BeanDefinitionRegistryPostProcessor invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry); currentRegistryProcessors.clear(); // 处理被注解@Ordered标注的BeanDefinitionRegistryPostProcessor, // 并且按排序后排序后执行 // 根据类型,从BeanDefinitionRegistry中查找出所有的BeanDefinitionRegistryPostProcessor的是实现类,及子类 postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false); for (String ppName : postProcessorNames) { // 没被处理过且被注解@Ordered if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) { currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class)); processedBeans.add(ppName); } } sortPostProcessors(currentRegistryProcessors, beanFactory); registryProcessors.addAll(currentRegistryProcessors); // 执行BeanDefinitionRegistryPostProcessor invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry); currentRegistryProcessors.clear(); // 再去执行其他的剩下的所有BeanDefinitionRegistryPostProcessor boolean reiterate = true; while (reiterate) { reiterate = false; postProcessorNames= beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false); for (String ppName : postProcessorNames) { if (!processedBeans.contains(ppName)) { currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class)); processedBeans.add(ppName); reiterate = true; } } sortPostProcessors(currentRegistryProcessors, beanFactory); registryProcessors.addAll(currentRegistryProcessors); invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry); currentRegistryProcessors.clear(); } // BeanDefinitionRegistryPostProcessor也是一个BeanFactoryPostProcessor // 下面这部分就是执行postProcessBeanFactory方法, // 会在@Configuration的proxyBeanMethods为true时对配置类做一个CGLIB增强, // 表示对配置类中的BeanMethod创建时,使用代理创建 // 将增强后的类,替换到其BeanDefinition#setBeanClass invokeBeanFactoryPostProcessors(registryProcessors, beanFactory); // 最后再执行直接注册到到ApplicationContext中的BeanFactoryPostProcessor invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory); } else { // 处理直接通过ApplicationContext实例注册的BeanFactoryPostProcessor invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory); } // 上面就执行过了定义的所有的BeanDefinitionRegistryPostProcessor,以及实现的 // BeanFactoryPostProcessor#postProcessBeanFactory方法 // 接下来回去执行所有的BeanFactoryPostProcessor处理器 // 查找出所有注册的类型为BeanFactoryPostProcessor的BeanDefinition的name数组 String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false); // 分别归类出使用@PriorityOrdered 和 @Ordered注解和没有使用的 List<BeanFactoryPostProcessor> priorityOrderedPostProcessors = new ArrayList<>(); List<String> orderedPostProcessorNames = new ArrayList<>(); List<String> nonOrderedPostProcessorNames = new ArrayList<>(); for (String ppName : postProcessorNames) { if (processedBeans.contains(ppName)) { // 处理过的,不用重复处理 } else if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) { priorityOrderedPostProcessors.add(beanFactory.getBean(ppName, BeanFactoryPostProcessor.class)); } else if (beanFactory.isTypeMatch(ppName, Ordered.class)) { orderedPostProcessorNames.add(ppName); } else { nonOrderedPostProcessorNames.add(ppName); } } // 优先处理 PriorityOrdered. sortPostProcessors(priorityOrderedPostProcessors, beanFactory); invokeBeanFactoryPostProcessors(priorityOrderedPostProcessors, beanFactory); // 其次 Ordered. List<BeanFactoryPostProcessor> orderedPostProcessors = new ArrayList<>(orderedPostProcessorNames.size()); for (String postProcessorName : orderedPostProcessorNames) { orderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class)); } sortPostProcessors(orderedPostProcessors, beanFactory); invokeBeanFactoryPostProcessors(orderedPostProcessors, beanFactory); //最后普通的 BeanFactoryPostProcessor List<BeanFactoryPostProcessor> nonOrderedPostProcessors = new ArrayList<>(nonOrderedPostProcessorNames.size()); for (String postProcessorName : nonOrderedPostProcessorNames) { nonOrderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class)); } invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, beanFactory); beanFactory.clearMetadataCache(); }
上面这个方法执行完后,已经完成了所有BeanFactoryPostProcessor的执行,也自然已经处理过所有的配置类了。
在众多的后置处理器中,有一个独属于 @Configuration
的后置处理器,就是 ConfigurationClassPostProcessor
,一个好的命名的效果,就体现出来了。
下面这个方法,负责两件事
BeanDefinitionRegistry BeanDefinition
// org.springframework.context.annotation.ConfigurationClassPostProcessor public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) { // 候选配置类集合 List<BeanDefinitionHolder> configCandidates = new ArrayList<>(); // 获取所有的BeanDefinition的name数组 String[] candidateNames = registry.getBeanDefinitionNames(); for (String beanName : candidateNames) { BeanDefinition beanDef = registry.getBeanDefinition(beanName); // 如果BeanDefinition中有这个属性存在,说明作为一个配置类已经被处理过了 if (beanDef.getAttribute(ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE) != null) { if (logger.isDebugEnabled()) { logger.debug("Bean definition has already been processed as a configuration class: " + beanDef); } } // 检查是否为一个配置类 // 查看是否具有@Configuration注解 // 这里不会仅仅看BeanDefinition所代表的类直接标注的注解,而是会递归查找其注解的注解是否有为 // @Configuration,只要找到了那么当前的类就是一个配置类 else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) { configCandidates.add(new BeanDefinitionHolder(beanDef, beanName)); } } // 找不到就结束 if (configCandidates.isEmpty()) { return; } // 对使用了@Order的进行排序 自然排序也就是升序 // 注意不是@Ordered configCandidates.sort((bd1, bd2) -> { int i1 = ConfigurationClassUtils.getOrder(bd1.getBeanDefinition()); int i2 = ConfigurationClassUtils.getOrder(bd2.getBeanDefinition()); return Integer.compare(i1, i2); }); // 如果有自定义Bean Name生成器,就使用自定义的 SingletonBeanRegistry sbr = null; if (registry instanceof SingletonBeanRegistry) { sbr = (SingletonBeanRegistry) registry; if (!this.localBeanNameGeneratorSet) { BeanNameGenerator generator = (BeanNameGenerator) sbr.getSingleton( AnnotationConfigUtils.CONFIGURATION_BEAN_NAME_GENERATOR); if (generator != null) { this.componentScanBeanNameGenerator = generator; this.importBeanNameGenerator = generator; } } } // 如果还没有初始化Environment对象,初始化一个 if (this.environment == null) { this.environment = new StandardEnvironment(); } // 解析每一个被@Configuratin标注的注解类 ConfigurationClassParser parser = new ConfigurationClassParser( this.metadataReaderFactory, this.problemReporter, this.environment, this.resourceLoader, this.componentScanBeanNameGenerator, registry); Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates); Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size()); do { parser.parse(candidates); parser.validate(); Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses()); configClasses.removeAll(alreadyParsed); // 构造一个BeanDefinitionReader if (this.reader == null) { this.reader = new ConfigurationClassBeanDefinitionReader( registry, this.sourceExtractor, this.resourceLoader, this.environment, this.importBeanNameGenerator, parser.getImportRegistry()); } // 加载配置类中的@Bean,生成BeanDefinition this.reader.loadBeanDefinitions(configClasses); alreadyParsed.addAll(configClasses); candidates.clear(); // 下面这段主要是考虑到@Import进来的或者@ImportSource或者@Bean等方式注入进来的会有配置类 if (registry.getBeanDefinitionCount() > candidateNames.length) { String[] newCandidateNames = registry.getBeanDefinitionNames(); Set<String> oldCandidateNames = new HashSet<>(Arrays.asList(candidateNames)); Set<String> alreadyParsedClasses = new HashSet<>(); for (ConfigurationClass configurationClass : alreadyParsed) { alreadyParsedClasses.add(configurationClass.getMetadata().getClassName()); } for (String candidateName : newCandidateNames) { if (!oldCandidateNames.contains(candidateName)) { BeanDefinition bd = registry.getBeanDefinition(candidateName); if (ConfigurationClassUtils.checkConfigurationClassCandidate(bd, this.metadataReaderFactory) && !alreadyParsedClasses.contains(bd.getBeanClassName())) { candidates.add(new BeanDefinitionHolder(bd, candidateName)); } } } candidateNames = newCandidateNames; } } while (!candidates.isEmpty()); //把 ImportRegistry注册成一个Bean,以便支持 继承ImportAware 有注解类@Configuration的配置类 if (sbr != null && !sbr.containsSingleton(IMPORT_REGISTRY_BEAN_NAME)) { sbr.registerSingleton(IMPORT_REGISTRY_BEAN_NAME, parser.getImportRegistry()); } }
这个方法执行完后,所有的配置类都会被进行处理,并且在此过程中, BeanDefinition
的总量有可能会增加,有新的 BeanDefinition
在解析过程新增进来。
这些 BeanDefinition
的来源就是存在于配置类上的其他注解
SpringBoot
是如何使用一个 @SpringBootApplication
注解,完成了那么多的事情?
答案就在下面揭晓
// `org.springframework.context.annotation.ConfigurationClassParser protected final SourceClass doProcessConfigurationClass( ConfigurationClass configClass, SourceClass sourceClass, Predicate<String> filter) throws IOException { // 如果有Component注解 if (configClass.getMetadata().isAnnotated(Component.class.getName())) { // 首先递归处理内部类 processMemberClasses(configClass, sourceClass, filter); } // 处理所有的@PropertySource注解 for (AnnotationAttributes propertySource : AnnotationConfigUtils.attributesForRepeatable( sourceClass.getMetadata(), PropertySources.class, org.springframework.context.annotation.PropertySource.class)) { if (this.environment instanceof ConfigurableEnvironment) { processPropertySource(propertySource); } else { logger.info("Ignoring @PropertySource annotation on [" + sourceClass.getMetadata().getClassName() + "]. Reason: Environment must implement ConfigurableEnvironment"); } } // 处理所有的 @ComponentScan 和@ComponentScans Set<AnnotationAttributes> componentScans = AnnotationConfigUtils.attributesForRepeatable( sourceClass.getMetadata(), ComponentScans.class, ComponentScan.class); if (!componentScans.isEmpty() && !this.conditionEvaluator.shouldSkip(sourceClass.getMetadata(), ConfigurationPhase.REGISTER_BEAN)) { for (AnnotationAttributes componentScan : componentScans) { // The config class is annotated with @ComponentScan -> perform the scan immediately Set<BeanDefinitionHolder> scannedBeanDefinitions = this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName()); // 继续检查扫描的BeanDefinition有没有是配置类的 for (BeanDefinitionHolder holder : scannedBeanDefinitions) { BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition(); if (bdCand == null) { bdCand = holder.getBeanDefinition(); } if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) { // 如果是的话,解析 parse(bdCand.getBeanClassName(), holder.getBeanName()); } } } } // 处理所有的@Import注解,将导入的Bean注册到BeanDefinitionRegistry // 这个也是会查找注解的注解,制止找到所有的@Import processImports(configClass, sourceClass, getImports(sourceClass), filter, true); // 处理所有的@ImportResource 注解,将导入的Bean注册到BeanDefinitionRegistry AnnotationAttributes importResource = AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class); if (importResource != null) { String[] resources = importResource.getStringArray("locations"); Class<? extends BeanDefinitionReader> readerClass = importResource.getClass("reader"); for (String resource : resources) { String resolvedResource = this.environment.resolveRequiredPlaceholders(resource); configClass.addImportedResource(resolvedResource, readerClass); } } // 处理独立的 @Bean方法,生成BeanMethod // 使用@Bean,方法要是可重写,也就是不能为default/private,因为要使用CGLIB代理 // 详细可进去下面方法细看 Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass); for (MethodMetadata methodMetadata : beanMethods) { configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass)); } // 处理接口的默认方法 processInterfaces(configClass, sourceClass); // 如果有父类,处理 if (sourceClass.getMetadata().hasSuperClass()) { String superclass = sourceClass.getMetadata().getSuperClassName(); if (superclass != null && !superclass.startsWith("java") && !this.knownSuperclasses.containsKey(superclass)) { this.knownSuperclasses.put(superclass, configClass); // Superclass found, return its annotation metadata and recurse return sourceClass.getSuperClass(); } } //没有父类,处理完成 return null; }
看下 @SpringBootApplication
的定义
@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Configuration public @interface SpringBootConfiguration { } @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class), @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) }) public @interface SpringBootApplication { }
可以看到 @SpringBootApplication
在功能上也是一个 @Configuration
。
这样就解释了,一般在 SpringBoot
的启动类上写了那么多注解,为啥可以被执行。
如果有看过各类 @Enable
注解,就一定会看到,每一个 @Enable
几乎都会被 @Import
所注解,而一般使用 @Enable
时,都会和 @SpringBootApplication
写一起,这个写法的一方面是比较清晰,集中写到一起,还有个原因就是部分 @Enable
在定义时,没有使用 @Configuration
来进行注解,需要借助于一个能被Spring容器启动时处理的配置类上。
上面的这段代码分析,正好解释了 @Enable
背后的实现原理。
其实总的看下来, @Configuration
就是一个标志注解,更大的作用就是为别的注解服务的。这么说有点矛盾,主要是觉得本身不具备什么功能性。
至于其能实现的对字段进行配置值绑定来说,可以使用 @ConfigurationProperties
或者 @Value
这两个注解来实现,由此可见, @Configuration
并不是用于将配置文件的配置值,绑定到配置类的,这个工作和他没有任何关系,对于一些配置文件的配置来说,可以使用 @Component
注解来对普通的配置类注解,达到一样的效果,而并非一定要使用 @Configuration
( @Configuration
注解派生自 @Component
)。
通过我们上面的分析,被 @Configuration
注解的类,仅有存在以上那几个注解时,才有意义,才能被 ConfigurationClassPostProcessor
所处理,而这个处理过程中,和配置值绑定一毛钱的关系都没有。
实际上配置值的绑定,都是在 Bean
实例化后, Bean
属性填充期间进行的。
@ConfigurationProperties
注解会在 ConfigurationPropertiesBindingPostProcessor
执行时进行处理,这个处理器是一个 BeanPostProcessor
。
@Value
注解的处理是在 AutowiredAnnotationBeanPostProcessor
这个 BeanPostProcessor
中来处理的,这个处理器同时也是处理 @Inject
、 @Autowired
、 @Resource
的 BeanPostProcesoor
。
Spring
或者 SpringBoot
中,大量的使用各种后置处理器,除了对主体框架( Bean
的生命周期)的理解外,剩下的主要就是熟悉这些支持各种功能的 PostProcessor
。
还有个值得注意的是, @Configuration
有个方法 proxyBeanMethods
,这个方法返回 true
时,默认也是 true
,会对我们的配置类,生成一个代理类,注意,这里是直接生成一个代理类,并且最后实例化时,也是使用这个代理类进行实例化 Bean
,这个就给我们一个启发,如果想对一些无法直接修改又被 Spring
容器所管理的的 Bean
,是否可以通过自定义 BeanDefinitionRegistryProcessor
的方式,来对原 Class
做一个增强,从而实现我们的目的。
PS:是否具备切实可行性,并不保证,只是觉得如果遇到,可以尝试下。