Spring解析Configuration类
上次我们大体介绍了Spring在初始化时每个方法是做什么的，本篇文章我们会重点介绍Spring是如何解析配置类的。
通过invokeBeanFactoryPostProcessors()方法，Spring会完成对配置类的解析并扫描配置的包路径。下面我们来分析这一过程。
public static void invokeBeanFactoryPostProcessors(
// First, invoke the BeanDefinitionRegistryPostProcessors that implement PriorityOrdered.
// 这里是为了获取已经注册了的BeanDefinitionRegistryPostProcessor名称
String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
}
}
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors,registry);
}
最终会通过beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class)方法来获取ConfigurationClassPostProcessor类，这个类是解析配置文件的关键。在拿到这个类实例后，通过invokeBeanDefinitionRegistryPostProcessors来调用postProcessBeanDefinitionRegistry方法进行解析。在该方法内会依次判断已有的bd中是否存在配置类，如果没有配置类会直接返回。需要说明的是Spring对配置类有两种判断方法。
第一种方法是判断类上是否直接标有@Configuration注解，这种类会在bd中设置一个参数CONFIGURATION_CLASS_FULL(full)来标识是配置类。
第二种是判断当前类是否标注了@Component、@ComponentScan、@Import或@ImportResource注解，若任意存在一个则也当配置类来判断。
上述两种判断方法有一个区别就是，Configuration的类会被CGLIB加强，但第二种方法的配置类不会。而且第二种方法会将@Controller、@Service和@Repostory都扫描进来。不过无需担心，此时处理的类仅仅是根目录下的类，一般情况下不会遇到上述3个注解，即使遇到了也不影响，因为后面还会有其他的诸如@ConponentScan、@Bean之类的判断，而MVC注解中并不会存在这些配置。也会被忽略掉。
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
List configCandidates = new ArrayList<>();
String[] candidateNames = registry.getBeanDefinitionNames();
// 这里是用来筛选配置类的操作
for (String beanName : candidateNames) {
BeanDefinition beanDef = registry.getBeanDefinition(beanName);
// 直接判断是否bd中已经存在标识属性
if (ConfigurationClassUtils.isFullConfigurationClass(beanDef) ||
ConfigurationClassUtils.isLiteConfigurationClass(beanDef)) {
}
// 不存在，则通过类注解来判断，并给bd中的标识属性赋值
else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {
configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
}
}
// Parse each @Configuration class
// 这里创建配置类解析器对象
ConfigurationClassParser parser = new ConfigurationClassParser(
this.metadataReaderFactory, this.problemReporter, this.environment,
this.resourceLoader, this.componentScanBeanNameGenerator, registry);
// 随后会在一个do-while循环里面对所有配置类进行解析
parser.parse(candidates);
..................................................................................
for (String candidateName : newCandidateNames) {
if (!oldCandidateNames.contains(candidateName)) {
BeanDefinition bd = registry.getBeanDefinition(candidateName);
// 在得到全部的bd后，会进行判断，对新扫描到的bd(通过@ComponentScan和@Bean得到的bd)进行判断，再次检查是否存在配置类
if (ConfigurationClassUtils.checkConfigurationClassCandidate(bd, this.metadataReaderFactory) && ! alreadyParsedClasses.contains(bd.getBeanClassName())) {
candidates.add(new BeanDefinitionHolder(bd, candidateName));
}
}
}
}
最终会在ConfigurationClassParser#doProcessConfigurationClass()方法中进行解析。
protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass)
throws IOException {
// 这里是处理内部类的，可以暂时忽略
if (configClass.getMetadata().isAnnotated(Component.class.getName())) {
// Recursively process any member (nested) classes first
processMemberClasses(configClass, sourceClass);
}
// 这里会处理ComponentScan并进行扫描
// Process any @ComponentScan annotations
Set 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
// 这里会执行扫描，并将扫描结果封装成BeanDefinitionHolder
Set scannedBeanDefinitions = this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName());
// Check the set of scanned definitions for any further config classes and parse recursively if needed
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注解的地方
// Process any @Import annotations
processImports(configClass, sourceClass, getImports(sourceClass), true);
// 这里是处理@ImportResource注解的地方
// Process any @ImportResource annotations
AnnotationAttributes importResource =
AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class);
if (importResource != null) {
String[] resources = importResource.getStringArray("locations");
Class readerClass = importResource.getClass("reader");
for (String resource : resources) {
String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
configClass.addImportedResource(resolvedResource, readerClass);
}
}
}
在解析ComponentScan时会通过ClassPathBeanDefinitionScanner#doScan()方法执行扫描并封装。在方法内部，实际上是通过PathMatchingResourcePatternResolver#getResources()来加载class文件，核心代码如下随后会通过isCandidateComponent放来来调用@ComponentScan中配置的Filter，来过滤或选择符合条件的class
private Set scanCandidateComponents(String basePackage) {
String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX + resolveBasePackage(basePackage) + '/' + this.resourcePattern;
// 这里就是去指定目录读取Class文件
Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);
for (Resource resource : resources) {
// 解析class文件，获取当前类的metadata
MetadataReader metadataReader = getMetadataReaderFactory().getMetadataReader(resource);
// 根据配置的Filter来过滤当前类是否需要管理
if (isCandidateComponent(metadataReader)) {
// 创建BeanDefinition对象
ScannedGenericBeanDefinition sbd = new ScannedGenericBeanDefinition(metadataReader);
}
}
}
结束后ClassPathBeanDefinitionScanner#doScan()方法中会继续处理注解中是否配置Lazy、Primary、DependsOn、Role级Description并赋值给BeanDefinition。到此扫描过程基本结束。
上述操作只处理了扫描包中的Bean，对于@Configuration类中配置的@Bean注解，则是在parse操作结束后，通过ConfigurationClassBeanDefinitionReader#loadBeanDefinitionsForBeanMethod方法来解析，并添加到beanDefinitionMap中。关键代码如下：
/**
* Read the given {@link BeanMethod}, registering bean definitions
* with the BeanDefinitionRegistry based on its contents.
*/
@SuppressWarnings("deprecation") // for RequiredAnnotationBeanPostProcessor.SKIP_REQUIRED_CHECK_ATTRIBUTE
private void loadBeanDefinitionsForBeanMethod(BeanMethod beanMethod) {
// 通过注解的metadata来创建bd对象，随后同样会进行Lazy、Scop等判断并赋值。
ConfigurationClassBeanDefinition beanDef = new ConfigurationClassBeanDefinition(configClass, metadata);
// 结束后会将改bd注册到容器中
this.registry.registerBeanDefinition(beanName, beanDefToRegister);
}
注册结束后PostProcessorRegistrationDelegate#invokeBeanFactoryPostProcessors()方法中会调用已经注册的BeanFactoryPostProcessors，注意，这里有很多操作，比如调用CGLIB代理，解析propertiesPlaceHolder等均在这里发生。关键代码如下
public static void invokeBeanFactoryPostProcessors(
// Now, invoke the postProcessBeanFactory callback of all processors handled so far.
// 这里的postProcessor是ConfigurationClassPostProcessor
invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
}
/**
* Invoke the given BeanFactoryPostProcessor beans.
*/
private static void invokeBeanFactoryPostProcessors(
Collection postProcessors, ConfigurableListableBeanFactory beanFactory) {
for (BeanFactoryPostProcessor postProcessor : postProcessors) {
postProcessor.postProcessBeanFactory(beanFactory);
}
}
在ConfigurationClassPostProcessor#postProcessBeanFactory()方法中来增强@Configuration类，Spring会通过CGLIB来生成代理类，并且植入3个回调方法，分别是!
image.png
后面我们再来分析这三个回调的作用。得到代理类后会覆盖bd内的beanClass属性的值，这样就会替代了原来的配置类而使用生成的代理类。
至此对@Configuration的主要流程处理就算结束了，还有些许不是很重要的地方未在文中列举，大家可以自行查看。下篇文章我们来分析IOC容器创建Bean的过程。