阿里妹导读

本文就Spring配置项解析问题展开分析，这其中涉及到bean定义注册表后置处理、bean工厂后置处理、工厂bean等Spring相关的概念。本文将以上述问题作为切入点，进行分析和展开介绍。

问题背景介绍

我们的项目中某次依赖了某个第三方包及其中的XML文件，相关代码如下所示：XML文件中定义了Mybatis相关的bean，以及对自定义数据源myDataSource的引用。在@Configuration配置类中，我们引入了XML文件，并通过@Bean注解的方式声明了数据源bean。

项目启动后，我们发现一个原有的通过XML定义的HSF（HSF全称High-speed Service Framework，是阿里内部主要使用的RPC服务框架）客户端bean中的配置项无法被正常解析。由于这是一个与我们新引入的包无关的bean，大家都对问题产生的原因感到奇怪，也尝试了各种不同的处理方式，然而都没有效果。无奈之下，我们通过将整个XML文件改写为Java注解声明的形式，才最终解决了问题。相关代码如下所示：

虽然问题得到了解决，但是大家仍旧对这其中的原因不明所以。笔者在事后通过本地调试的方式，找到了问题的原因。这其中涉及到bean定义注册表后置处理、bean工厂后置处理、工厂bean等Spring相关的概念。本文将以上述问题作为切入点，进行分析和展开介绍。

XML配置项解析

为了更好地解答上述问题产生的原因，我们先来看下Spring框架对bean使用的配置项的解析过程。我们知道，Spring会负责对我们在XML文件中声明的bean的创建。不过，对其中的配置项解析，并不是在这个环节发生，而是在其前置环节 —— bean工厂后置处理的过程中发生的。bean工厂（BeanFactory）是Spring的核心组件，除了负责初始化bean的实例，记录单例外，它还维护了各个bean的定义（BeanDefinition）。bean的定义中主要记录了bean的类型、作用域（singleton/prototype）、属性值、构造函数参数值等信息。bean的实例化便是基于bean的定义进行的。而bean工厂的后置处理环节，则可以在bean被创建之前，修改bean的定义，以达到影响最终生成的bean实例的效果。

对XML中配置项的解析工作，Spring是通过PropertySourcesPlaceholderConfigurer这个bean工厂后置处理器（BeanFactoryPostProcessor）完成的。其核心代码如下所示。总体思路比较简单，即遍历bean工厂中的bean定义，对于每个bean的定义，访问其属性值、构造函数参数值等信息，解析其中的配置项占位符（placeholder）。这个环节完成之后，在bean工厂对bean进行初始化之前，bean定义中的配置项占位符就已经被替换为实际的属性值了。

了解了bean工厂后置处理环节后，让我们再往前探究一步，看下bean定义本身是如何被加载到bean工厂中的（这将有助于我们理解文章开头所提到的问题的产生原因）。bean定义主要是在bean定义注册表后置处理环节被加载到bean工厂中的。与我们前面提到的bean工厂后置处理环节类似，该环节也存在相应的处理器（BeanDefinitionRegistryPostProcessor）完成相关工作。

其中典型的如ConfigurationClassPostProcessor。以Spring Boot场景为例，简单来说，该bean定义注册表后置处理器会从包含了@SpringBootApplication注解的启动引导类开始，根据其组合注解@ComponentScan，扫描被@Component，或者组合了@Component的注解（如@Configuration、@Service、@Repository等）标注的类，将这些配置类（注1）的bean定义注册至bean工厂。同时，处理器还会根据组合注解@EnableAutoConfiguration，获取Spring Boot中的自动配置类。在这之后，ConfigurationClassPostProcessor会尝试解析各个配置类中包含的@Bean、@ImportResource等注解，将对应的bean定义也注册到bean工厂中。

最后，对于配置项本身来说，Spring的环境抽象（Environment）会拉取并聚合JVM系统属性、操作系统环境变量、应用属性配置文件等多个属性源的数据（注2），以供bean工厂中的bean定义或者bean实例使用。如前面提到的PropertySourcesPlaceholderConfigurer处理器，便是从Spring环境中获取bean定义中的配置项占位符所对应的属性值，并将其替换的。上文通过倒序的方式介绍了配置项解析的相关环节，下面我们用顺序表示的流程图作结，以便读者更好地理解。

问题原因分析

现在，我们可以对文章开头提到的问题作进一步分析了。仔细查看我们所引入的XML文件可以发现，其中包含一个类型为MapperScannerConfigurer的bean声明。Spring借助该类完成对标注有@Mapper注解的MyBatis映射接口的扫描。MapperScannerConfigurer实现了BeanDefinitionRegistryPostProcessor接口，是一个bean定义注册表后置处理器。它对映射接口的扫描及其对应的bean定义的注册，便是在该环节进行的。

前面我们提到，ConfigurationClassPostProcessor这个bean定义注册表后置处理器会扫描并加载@Configuration和@ImportResource注解相关的bean定义。我们所引入的XML文件中的bean的定义，便是通过这个动作被注册到bean工厂中的（见上文MyDataSourceConfiguration配置类）。在ConfigurationClassPostProcessor完成其扫描及加载工作后，由于有新的bean定义被注册，Spring会再次尝试从bean工厂中找出并初始化其他的bean定义注册表后置处理器，以触发它们的处理动作。MapperScannerConfigurer便是在此时被实例化并触发的。

观察问题背景介绍章节中的相关代码可以发现，MapperScannerConfigurer的bean实例（thirdPartyMapperScannerConfigurer）间接依赖了我们通过@Bean注解在配置类中声明的数据源bean实例（myDataSource）。因此，在本文案例中，Spring在创建MapperScannerConfigurer实例时，会首先对数据源bean进行初始化。而对于通过@Bean注解声明的bean，Spring是通过反射调用注解所在的工厂方法（factory method），完成bean的实例化的。我们的数据源myDataSource的实例化，便是通过反射调用其工厂方法createMyDataSource完成的。由于该方法包含了一个类型为Environment入参，Spring需要遍历bean工厂中的bean定义，找到并创建匹配的bean，作为反射调用时的方法传参。

而问题恰恰就出现在这里的参数匹配环节。Spring在进行方法入参匹配时，会首先调用getBeanNamesForType方法，将符合参数类型的bean的名称找出来，然后依据一定的策略（注3）将bean进行实例化，作为方法入参使用。对于普通的bean来说，Spring只需要依据bean定义中包含的bean类型信息，与参数类型作匹配即可；而对于另一类较为特殊的工厂bean（FactoryBean）来说，其类型推断方式就会更加复杂些。下文将会展开介绍工厂bean的概念和案例，对此不太熟悉的读者，这里只需要了解，工厂bean的作用是负责产生某个我们最终实际需要使用的bean。因此，在进行参数匹配时，Spring关心的是这个最终产生的bean的类型，而不是工厂bean本身的类型。

在判断工厂bean实际输出的bean的类型时（注4），Spring首先会尝试根据工厂bean定义中的某些元数据进行类型推断；其次会尝试对工厂bean进行一次简单创建后，通过其getObjectType方法获取目标bean的类型。如果前两种尝试都失败了，则会使用兜底逻辑 —— 对工厂bean进行正式创建后，再通过getObjectType获取类型信息。这里的「正式创建」，我们可以理解为Spring完成了工厂bean的实例化、属性字段的赋值、单例信息的记录等；而「简单创建」仅仅指工厂bean的实例化，不包括后续的字段初始化等动作。

而我们在上文提到的myHsfClient，便是被声明为了一个类型为HSFSpringConsumerBean的工厂bean。Spring在对createMyDataSource的方法入参进行类型匹配时，由于前述的前两种类型推断方式都没有成功（其具体原因将在后文工厂bean小节中介绍），导致该工厂bean最终被「提前」正式创建了出来。读者可能已经发现，此时Spring正处在bean定义注册表后置处理环节。而我们在XML配置项解析章节中提到的对bean定义中的配置项占位符的解析替换，则是在该环节之后的bean工厂后置处理环节进行的 —— 这就是导致myHsfClient这个工厂bean中的配置项没有被正常解析的原因。整体方法调用关系如下图所示：

至此可能读者会有疑问：难道我们的项目中之前没有对@Mapper映射器接口的扫描动作吗？答案是有扫描动作，不过是通过MapperScannerRegistrar这个bean定义注册器触发的。而由于其与我们通过XML所引入的MapperScannerConfigurer的一些细微区别，使得项目中原先不存在工厂bean被提前创建的问题。由于篇幅所限，这里不再对MapperScannerRegistrar作展开介绍。

知道了问题背后的原因后，寻找对应的解法也就相对简单了。对于文中案例，一方面，我们可以看到，由于thirdPartyMapperScannerConfigurer依赖了SqlSessionFactoryBean实例（这就是我们刚刚说的「细微区别」所在），导致其间接依赖了myDataSource。而考察源码可以发现，其实MapperScannerConfigurer只需要SqlSessionFactory的bean名称（sqlSessionFactoryBeanName）作为输入即可，因此我们可以把XML中相关的depends-on声明去除。另一方面，由于createMyDataSource方法入参是Spring环境抽象，我们可以改由通过使配置类实现EnvironmentAware接口的方式，获得应用上下文中的Environment实例。这两种方法都能解决我们的工厂bean被提前创建的问题。

在更一般化的场景中，如果在Spring启动的早期阶段，对某个bean的依赖注入无法避免，我们可以使相关的类实现ApplicationContextAware接口，尝试通过应用上下文（ApplicationContext）的getBean方法获取我们想要的对象。不过需要注意的是，getBean方法存在两类版本：根据bean名称获取实例，或是根据指定类型获取实例；而如果我们选择根据指定类型获取实例，则仍旧会触发上文提到的类型匹配机制，导致某些无法通过正常方式进行类型推断的工厂bean被提前创建出来。最后，对于前文提到的，在使用注解形式改写myHsfClient的bean声明后，问题得到解决的原因，我们将在后文分析介绍。

一些引申扩展

经过上文让人感觉有些绕的分析，我们可以看到，文章开头所提到的问题的本质是，某些bean被Spring提前正式创建了出来，导致其bean声明中的配置项占位符没有来得及被解析和替换。这其中涉及到不少概念，诸如bean定义注册表后置处理、bean工厂后置处理、工厂bean等。由于我们在日常开发中一般接触得不多，读者对它们的理解可能还比较模糊，下文将尝试结合实际案例，进行一些引申和扩展介绍。

bean定义注册表后置处理

我们在前文中已经介绍了ConfigurationClassPostProcessor和MapperScannerConfigurer这两个bean定义注册表后置处理器。这类处理器的主要作用便是扫描并向bean工厂中注册bean定义。其中，ConfigurationClassPostProcessor负责扫描配置类，处理其包含的注解，并将相关的bean定义注册至bean工厂中。随后，对于这些新增的bean定义，如果其中又包含了其他的bean定义注册表后置处理器，Spring会将它们实例化，并触发它们的处理动作（注5），继续注册可能被发现的新的bean定义……如此循环往复，直到所有该类型的处理器都被触发，完成bean定义的注册为止。如以下代码所示：

回到我们的问题案例，MapperScannerConfigurer便是在上述环节被创建出来并触发的。这里，细心的读者可能会有疑问：如果我们在使用XML声明这个Mybatis的处理器时，对其中的某些属性也使用了配置项占位符，那么Spring在创建它时，是否也会遇到同样的解析问题?MapperScannerConfigurer的作者显然是考虑到了这一点 —— 处理器被触发后，支持首先尝试对它的属性字段进行配置项的解析和替换。其具体的实现方式，是构造一个新的bean工厂，将自身的bean定义注册其中，然后借助PropertySourcesPlaceholderConfigurer等处理器，对这个bean工厂执行配置项的后置处理操作；最后，用bean定义中的被解析后的属性值，替换自身实例中原有的属性值。这在一定程度上相当于模拟了Spring的bean工厂后置处理环节。其具体代码如下：

最后，值得一提的是，对于ConfigurationClassPostProcessor的bean定义本身，则是在Spring应用上下文（ApplicationContext）初始化的过程中，通过硬编码的形式被注册到bean工厂中的（注6）。这里同时被注册的还有诸如AutowiredAnnotationBeanPostProcessor等bean后置处理器，我们将在后文对此作相应介绍。

bean工厂后置处理

当bean定义注册表后置处理环节完成后，基本上（注7）所有的bean定义都已经被注册至bean工厂中了。随后，Spring会找出所有的bean工厂后置处理器，按照一定的顺序实例化并触发它们的处理动作（优先执行实现了PriorityOrdered接口的，其次执行实现了Ordered接口的，最后执行没有实现前两个接口的）。这类处理器一般会遍历bean工厂中所有的bean定义，执行一些特定的操作。我们在前文提到的PropertySourcesPlaceholderConfigurer这个bean工厂后置处理器，便是在此时被触发的。而在这个所有bean定义都已经准备就绪的阶段，统一进行配置项占位符的解析和替换，其时机总体上也是恰当合理的。

其他的比较典型的Spring内置bean工厂后置处理器还有ConfigurationBeanFactoryMetaData。这个处理器执行的动作比较简单：它会遍历bean工厂中的bean定义，记录其中的工厂方法等元数据信息。其核心代码如下所示。而这份记录的作用，我们将在后文说明。

public class ConfigurationBeanFactoryMeta Data implements BeanFactoryPostProcessor { private Map<String, MetaData> beans = new HashMap<String, MetaData>(); public void postProcessBeanFactory(Configurab leListableBeanFactory beanFactory) throws BeansException { this.beanFactory = beanFactory; // 遍历bean工厂中的bean定义 for (String name : beanFactory.getBean DefinitionNames()) { BeanDefinition definition = beanFactory. getBeanDefinition(name); String method = definition.getFactoryMethodName(); String bean = definition.getFactoryBeanName(); // 如果存在工厂方法元数据（如通过 @Bean注解声明的bean），则将相关信息记录下来 if (method != null && bean != null) { this.beans.put(name, new MetaData(bean, method)); } } } }

最后，我们来看另一个和我们的XML配置项解析问题相关的处理器。在问题背景介绍章节中我们提到，当把myHsfClient的bean声明改写为由@HSFConsumer注解修饰的形式后，问题得到了解决。而这背后则是HsfConsumerPostProcessor这个bean工厂后置处理器在发挥作用：对于每一个bean定义，如果它的类属性字段上存在@HSFConsumer注解，处理器会动态生成并注册一个类型为HSFSpringConsumerBean的工厂bean定义。虽然由于PropertySourcesPlaceholderConfigurer处理器实现了PriorityOrdered接口，在此之前已经被优先执行过了，但是HsfConsumerPostProcessor考虑到了这一点 —— 在生成工厂bean定义的过程中，会主动尝试解析相关属性的配置项占位符，因此规避了我们在使用XML方式进行工厂bean声明时遇到的问题。

工厂bean

前面我们提到，HSFSpringConsumerBean是一个工厂bean。不仅如此，我们详细讨论的Mybatis的MapperScannerConfigurer处理器，对于其基于@Mapper注解扫描到的映射接口，也会将其bean定义改写为MapperFactoryBean这个工厂bean类型。此外，在Spring中，用于创建Mybatis的SqlSession对象的SqlSessionFactory，也是由一个名为SqlSessionFactoryBean的工厂bean生成的。那么，什么是工厂bean，它的作用又是什么呢？

工厂bean，即FactoryBean，其基于工厂模式，创建我们最终需要的bean实例。根据Spring文档中的介绍（注8），如果某个bean的初始化逻辑较为复杂，不适合使用XML的方式表达，那么我们可以通过使用工厂bean，以Java语言的方式完成目标bean的初始化。工厂bean的概念早在Spring 0.9版本（注9）就已经被引入，在Spring框架中的使用是比较普遍的，至今为止仅其自带的实现就有50多个。下面我们就文中的案例展开介绍。

// MyBatis配置文件路径。配置文件包含数 据源、映射器等信息 String resource = "org/mybatis/example/mybatis-config.xml"; // 创建配置文件输入流 InputStream inputStream = Resources.get ResourceAsStream(resource); // 创建SqlSessionFactory实例 SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); // 创建SqlSession实例 try (SqlSession session = sqlSessionFactory. openSession()) { // 获取BlogMapper映射器 BlogMapper mapper = session.getMapper (BlogMapper.class); // 执行查询语句 Blog blog = mapper.selectBlog(101); }

在介绍Mybatis与Spring整合时使用的两个工厂bean之前，我们先来看下相关功能单纯基于Mybatis本身实现时的代码。代码片段摘自Mybatis官网，如上所示。可以看到，其中SqlSessionFactory实例是由SqlSessionFactoryBuilder创建的；而用于执行查询语句的映射器实例，则是由SqlSession实例的getMapper方法创建的。与之相对的，如果阅读源码可以发现，在Mybatis-Spring中，用于创建SqlSessionFactory实例的SqlSessionFactoryBean和映射器实例的MapperFactoryBean这两个工厂bean，在一定程度上可以看作是对上述代码封装和扩展。

可以看到，虽然借助如上所示的factory-bean和factory-method标签属性，我们也能通过XML完成对SqlSessionFactory的声明，但这种通过XML刻画bean初始化过程的方式，与我们在问题背景介绍章节看到的基于工厂bean的声明方式相比，不免显得有些繁琐了。不过，随着Spring 3.0带来的基于@Configuration的Java注解配置特性，工厂bean在这方面的优势也变得不再那么明显了。

不过，当我们考察如上MapperFactoryBean的源码时，会发现它的bean初始化逻辑很简单，与单纯基于MyBatis的代码实现如出一辙。其中仅有的不同是，这里getMapper方法的映射器类型入参，使用的是工厂bean中的mapperInterface属性。前面我们提到，MapperScannerConfigurer在扫描被@Mapper注解标注的映射器接口时，会为每个接口生成一个对应的bean定义，并将bean定义的类型属性改写为工厂bean类型。而对于bean定义中mapperInterface属性的设置，也是在此时完成的（属性的值即为映射器接口的全限定名）。随后，在bean的实例化环节，Spring便可以基于这些bean定义，为每个映射器接口生成一个对应的工厂bean，以此服务于我们开发中常用的映射器实例依赖注入场景。对此，如果通过Java注解配置或是XML声明的方式实现，则会显得有些大费周章 —— 对于每一个Mybatis映射器接口，我们都需要作一次对应的声明；而如果一个项目中包含数十个映射器接口（这个量级在中大型项目中应属常见），则需要做数十次大同小异的声明。

对于HSFSpringConsumerBean这个工厂bean来说，其作用也是类似。这类bean注入方式的共性是：基于注解（或接口）扫描以及一些相关的配置信息，为每个被标注的接口生成一个对应的工厂bean；而当工厂bean通过getObject方法输出我们最终需要的bean时，往往是基于配置信息为接口生成一个动态代理，供实际使用。这种做法常见于Spring与其他框架集成的场景。就我们文中分析的例子而言，在数据库持久化领域，除了Mybatis外，Hibernate借助JpaRepositoryFactoryBean这个工厂bean生成其Repository接口的实例；在远程调用领域，除了HSF外，Spring Cloud中的Feign通过FeignClientFactoryBean为标注有@FeignClient注解的客户端接口生成动态代理。由于篇幅所限，这里仅以MyBatis为例，展示其类结构关系（见下图）。对于其他的案例，我们不再一一展开分析，感兴趣的读者可以阅读相关源码作进一步了解。

回到我们文章中探讨的配置项解析问题，可以看到，虽然工厂bean能为Spring与其他框架整合提供很多便利，但如果使用不慎，则可能导致一些隐蔽的问题。其实，在2015年，MyBatis的MapperFactoryBean也遇到了类似的与类型推断相关的问题（详见github - mybatis-spring issue #58及pull request #59），而社区对此的解决方式是：利用Spring对bean进行实例化时，会首先尝试匹配有参构造函数的特性，在MapperFactoryBean中新增一个以映射器类型为入参的构造函数；并在处理工厂bean定义的阶段，将映射器类型作为构造函数参数，放入bean定义中（如下图所示）。如此，在前文提到的「简单创建」后，Spring便可以通过调用getObjectType方法获取到当前MapperFactoryBean实例所代表的映射器接口类型了。

最后，回到本次问题的关键点之一：HSFSpringConsumerBean。在使用XML声明的方式时，虽然我们在工厂bean的interfaceName字段指定了客户端接口类型，但Spring在尝试对其进行「简单创建」以做类型推断时，并不会为实例中的属性字段赋值。这导致我们无法通过调用该实例的getObjectType方法得到它所代表的客户端接口类型，并最终导致该工厂bean被「正式创建」了出来。虽然通过@HSFConsumer注解声明的形式，我们得以规避了配置项解析问题，但HSF作者可以考虑参考MapperFactoryBean的方式，增加一个以客户端接口类型为入参的构造函数，来更好地兼容基于XML的声明方式。

基于注解的配置项解析

上文主要围绕基于XML声明的配置项解析进行了分析探讨，其实，自Spring引入基于Java注解的bean声明能力以来，我们使用得更多的是基于注解的配置项解析特性。而对此特性的支持主要是通过Spring的bean后置处理器（BeanPostProcessor）完成的。绝大部分bean的后置处理是在bean的创建环节被触发的：bean工厂首先对bean进行实例化，然后使用bean后置处理器对它们进行相应的处理操作。下面我们进行简单的介绍。

前面我们提到，Spring会以硬编码的形式将AutowiredAnnotationBeanPostProcessor这个bean后置处理器注册到bean工厂中。从字面上看，这个处理器是负责@Autowired注解的，其实，@Value注解也在它的处理范围之内。处理器会在bean实例化后的属性赋值步骤（注10）被触发，对@Value注解中的配置项占位符进行解析，并将属性值赋给被注解标注的字段。而其使用的配置项解析器，其中之一就是通过PropertySourcesPlaceholderConfigurer这个bean工厂后置处理器添加的（详见XML配置项解析章节）。

另一个我们常见的配置项相关的注解是@ConfigurationProperties。该注解由ConfigurationPropertiesBindingPostProcessor这个bean后置处理器处理，处理动作在bean实例化后的初始化步骤（注11）被触发。除了我们熟知的作用于类的使用方式外，@ConfigurationProperties还可以作用于被@Bean注解标注的方法 —— 这主要是针对我们无法直接将注解加在第三方外部类上的情况。而这里对于方法级别的注解解析，处理器便是借助我们之前提到的ConfigurationBeanFactoryMetaData的工厂方法记录完成的（详见bean工厂后置处理小节）。具体代码如下所示：

@Override public Object postProcessBeforeInitialization (Object bean, String beanName) throws BeansException { ConfigurationProperties annotation = AnnotationUti ls.findAnnotation(bean.getClass(), ConfigurationProperties.class); if (annotation != null) { postProcessBeforeInitialization(bean, beanName, annotation); } // 处理方法级别的@ConfigurationProperties注解 // 这里的this.beans即为ConfigurationBean FactoryMetaData实例 annotation = this.beans.findFactoryAnnotation (beanName, ConfigurationProperties.class); if (annotation != null) { postProcessBeforeInitialization(bean, beanName, annotation); } return bean; }

思考与总结

我们可以看到，随着Spring从基于XML的bean声明到基于Java注解的bean声明能力的演化，对配置项的解析方式也在发生着变化。其中牵涉到bean工厂后置处理、bean后置处理等环节，而它们彼此之间又存在一定的关联。同时，如果某些bean（如工厂bean）由于某些原因，在Spring启动的早期阶段（如bean定义注册表后置处理环节）被提前创建了出来，则可能导致其中的配置项解析失败。对此，我们一方面可以尝试寻找规避手段，另一方面也可以从该bean本身的设计探究原因。

为了方便读者理解，以上表格整理了文中提到的各类Spring后置处理器，以及它们彼此的关联。可以看到，Spring框架在给我们提供了很多开发便利的同时，其整体的设计还是较为复杂的。在日常开发中，我们可能时不时会遇到一些「疑难杂症」，而此时对框架的深入理解能帮助我们高效地解决问题。此外，善用对Spring代码的调试，也能帮助我们在纷繁的思路或线索中定位到问题原因。最后，由于写作时间仓促，且Spring不同版本间可能存在一定的行为差异，文中如有错漏之处还请读者包涵指正。