专一Java畛域分享、成长，回绝浅尝辄止。关注公众号【BAT的乌托邦】开启专栏式学习，回绝浅尝辄止。本文 https://www.yourbatman.cn 已收录，外面一并有Spring技术栈、MyBatis、中间件等小而美的专栏供以学习哦。

前言

各位小伙伴大家好，我是A哥。这是继上篇文章：真懂Spring的@Configuration配置类？你可能自我感觉太良好 的原理/源码解释篇。依照本公众号的定位，原理个别跑不了，尽管很干燥，但还得做，毕竟做难事必有所得，真的把握了才有底气谈涨薪嘛。

Tips：鉴于常常有些同学无奈辨别某个性能/某项能力属于Spring Framework的还是Spring Boot，你能够参考文章里的【版本约定】目录，那里会阐明本文的版本依赖，也就是性能所属喽。比方本文内容它就属于Spring Framework，和Spring Boot木有关系。

版本约定

本文内容若没做非凡阐明，均基于以下版本：

  • JDK：1.8
  • Spring Framework：5.2.2.RELEASE

注释

Spring的IoC就像个“大熔炉”，什么都当作Bean放在外面。然而，尽管它们都放在了一起，然而理论在性能上是有区别的，比方咱们相熟的BeanPostProcessor就属于后置处理器性能的Bean，还有本文要探讨的@Configuration配置Bean也属于一种非凡的组件。

判断一个Bean是否是Bean的后置处理器很不便，只需看它是否实现了BeanPostProcessor接口即可；那么如何去确定一个Bean是否是@Configuration配置Bean呢？若是，如何辨别是Full模式还是Lite模式呢？这便就是本文将要探讨的内容。

如何判断一个组件是否是@Configuration配置？

首先须要明确：@Configuration配置前提必须是IoC治理的一个组件（也就是常说的Bean）。Spring应用BeanDefinitionRegistry注册核心治理着所有的Bean定义信息，那么对于这些Bean信息哪些属于@Configuration配置呢，这是须要甄选进去的。

判断一个Bean是否是@Configuration配置类这个逻辑对立交由ConfigurationClassUtils这个工具类去实现。

ConfigurationClassUtils工具类

见名之意，它是和配置无关的一个工具类，提供几个动态工具办法供以应用。它是Spring 3.1新增，对于它的作用，官网给的解释是：用于标识@Configuration类的实用程序(Utilities)。它次要提供了一个办法：checkConfigurationClassCandidate()用于查看给定的Bean定义是否是配置类的候选对象（或者在配置/组件类中申明的嵌套组件类），并做相应的标记。

checkConfigurationClassCandidate()

它是一个public static工具办法，用于判断某个Bean定义是否是@Configuration配置。

ConfigurationClassUtils：    public static boolean checkConfigurationClassCandidate(BeanDefinition beanDef, MetadataReaderFactory metadataReaderFactory) {        ...        // 依据Bean定义信息，拿到器对应的注解元数据        AnnotationMetadata metadata = xxx;        ...                // 依据注解元数据判断该Bean定义是否是配置类。若是：那是Full模式还是Lite模式        Map<String, Object> config = metadata.getAnnotationAttributes(Configuration.class.getName());        if (config != null && !Boolean.FALSE.equals(config.get("proxyBeanMethods"))) {            beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);        } else if (config != null || isConfigurationCandidate(metadata)) {            beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);        } else {            return false;        }                ...                // 到这。它必定是一个残缺配置（Full or Lite） 这里进一步把@Order排序值放上去        Integer order = getOrder(metadata);        if (order != null) {            beanDef.setAttribute(ORDER_ATTRIBUTE, order);        }        return true;    }

步骤总结：

  1. 依据Bean定义信息解析成为一个注解元数据对象AnnotationMetadata metadata

    1. 可能是个AnnotatedBeanDefinition，也可能是个StandardAnnotationMetadata

  2. 依据注解元数据metadata判断是否是个@Configuration配置类，有如下三种可能case：

    1. 标注有@Configuration注解并且该注解的proxyBeanMethods = false，那么mark一下它是Full模式的配置。否则进入下一步判断
    2. 标注有@Configuration注解或者合乎Lite模式的条件（上文有说一共有5种可能是Lite模式，源码处在isConfigurationCandidate(metadata)这个办法里表述），那么mark一下它是Lite模式的配置。否则进入下一步判断
    3. 不是配置类，并且返回后果return false
  3. 能进行到这一步，阐明该Bean必定是个配置类了（Full模式或者Lite模式），那就取出其@Order值（若有的话），而后mark进Bean定义外面去

这个mark动作很有意义：前面判断一个配置类是Full模式还是Lite模式，甚至判断它是否是个配置类均可通过beanDef.getAttribute(CONFIGURATION_CLASS_ATTRIBUTE)这样实现判断。

办法应用处

通晓了checkConfigurationClassCandidate()可能判断一个Bean(定义)是否是一个配置类，那么它在什么时候会被应用呢？通过查找能够发现它被如下两处应用到：

  • 应用处：ConfigurationClassPostProcessor.processConfigBeanDefinitions()解决配置Bean定义阶段。
ConfigurationClassPostProcessor：    public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {                // 拿出以后所有的Bean定义信息，一个个的查看是否是配置类            String[] candidateNames = registry.getBeanDefinitionNames();        for (String beanName : candidateNames) {            BeanDefinition beanDef = registry.getBeanDefinition(beanName);            if (beanDef.getAttribute(ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE) != null) {                logger.debug("Bean definition has already been processed as a configuration class: " + beanDef);            }            // 如果该Bean定义不是配置类，那就持续判断一次它是否是配置类，若是就退出后果汇合里            else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {                configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));            }        }        ...    }

ConfigurationClassPostProcessor是个BeanDefinitionRegistryPostProcessor，会在BeanFactory 筹备好后执行生命周期办法。因而自然而然的，checkConfigurationClassCandidate()会在此阶段调用，用于辨别出哪些是配置Bean。

值得注意的是：ConfigurationClassPostProcessor的执行期间是十分晚期的（BeanFactory筹备好后就执行嘛），这个时候容器内的Bean定义很少。这个时候只有主配置类才被注册了进来，那些想通过@ComponentScan扫进来的配置类都还没到“工夫”，这个工夫节点很重要，请留神辨别。为了不便你了解，我别离把Spring和Spring Boot在此阶段的Bean定义信息截图展现如下：


以上是Spring环境，对应代码为：

new AnnotationConfigApplicationContext(AppConfig.class);


以上是Spring Boot环境，对应代码为：

@SpringBootApplicationpublic class Boot2Demo1Application {    public static void main(String[] args) {        SpringApplication.run(Boot2Demo1Application.class, args);    }}
相比之下，Spring Boot里多了internalCachingMetadataReaderFactory这个Bean定义。起因是SB定义了一个CachingMetadataReaderFactoryPostProcessor把它放进去的，因为此Processor也是个BeanDefinitionRegistryPostProcessor并且order值为Ordered.HIGHEST_PRECEDENCE，所以它会优先于ConfigurationClassPostProcessor执行把它注册进去~
  • 应用处：ConfigurationClassParser.doProcessConfigurationClass() 解析 @Configuration配置类阶段。所处的大阶段同上应用处，仍旧是ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry()阶段
ConfigurationClassParser：    @Nullable    protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass) throws IOException {        ... // 先解析nested外部类（外部类会存在@Bean办法嘛~）        ... // 解析@PropertySource资源，退出到environment环境        ... // 解析@ComponentScan注解，把组件扫描进来        scannedBeanDefinitions = ComponentScanAnnotationParser.parse(componentScan, ...);            // 把扫描到的Bean定义信息仍旧须要一个个的判断，是否是配置类                // 若是配置类，就持续当作一个@Configuration配置类来解析parse() 递归嘛            for (BeanDefinitionHolder holder : scannedBeanDefinitions) {                ...                if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {                    parse(bdCand.getBeanClassName(), holder.getBeanName());                }            }        ... // 解析@Import注解        ... // 解析@ImportResource注解        ... // 解析以后配置里配置的@Bean办法        ... // 解析接口默认办法（因为配置类可能实现接口，而后接口默认办法可能标注有@Bean ）        ... // 解决父类（递归，直到父类为java.打头的为止）    }

这个办法是Spring对配置类解析的最外围步骤，通过它顺带也可能解答你的纳闷了吧：为何你仅需在类上标注一个@Configuration注解即可让它成为一个配置类？因为被Scan扫描进去了嘛~

通过以上两个应用处的剖析和比照，对于@Configuration配置类的了解，你至多应该把握了如下讯息：

  1. @Configuration配置类必定是个组件，存在于IoC容器里
  2. @Configuration配置类是有主次之分的，主配置类是驱动整个程序的入口，能够是一个，也能够是多个（若存在多个，反对应用@Order排序）
  3. 咱们平时个别只书写次配置类（而且个别写多个），它个别是借助主配置类的@ComponentScan能力实现加载进而解析的（当然也可能是@Import、又或是被其它次配置类驱动的）
  4. 配置类能够存在嵌套（如外部类），继承，实现接口等个性

聊完了最为重要的checkConfigurationClassCandidate()办法，当然还有必要看看ConfigurationClassUtils的另一个工具办法isConfigurationCandidate()。

isConfigurationCandidate()

它是一个public static工具办法，通过给定的注解元数据信息来判断它是否是一个Configuration。

ConfigurationClassUtils：    static {        candidateIndicators.add(Component.class.getName());        candidateIndicators.add(ComponentScan.class.getName());        candidateIndicators.add(Import.class.getName());        candidateIndicators.add(ImportResource.class.getName());    }    public static boolean isConfigurationCandidate(AnnotationMetadata metadata) {        // 不思考接口 or 注解 阐明：注解的话也是一种“非凡”的接口哦        if (metadata.isInterface()) {            return false;        }        // 只有该类上标注有以上4个注解任意一个，都算配置类        for (String indicator : candidateIndicators) {            if (metadata.isAnnotated(indicator)) {                return true;            }        }        // 若一个注解都没标注，那就看有木有@Bean办法 若有那也算配置类        return metadata.hasAnnotatedMethods(Bean.class.getName());    }

步骤总结：

  1. 若是接口类型（含注解类型），间接不予考虑，返回false。否则持续判断
  2. 若此类上标注有@Component、@ComponentScan、@Import、@ImportResource任意一个注解，就判断胜利返回true。否则持续判断
  3. 到此步，就阐明此类上没有标注任何注解。若存在@Bean办法，返回true，否则返回false。

须要特地特地特地留神的是：此办法它的并不思考@Configuration注解，是“轻量级”判断，这是它和checkConfigurationClassCandidate()办法的最次要区别。当然，后者依赖于前者，依赖它来依据注解元数据判断是否是Lite模式的配置。

Spring 5.2.0版本变动阐明

因为本文的解说和代码均是基于Spring 5.2.2.RELEASE的，而并不是所有小伙伴都会用到这么新的版本。对于此局部的实现，以Spring 5.2.0版本为分界线实现上有些许差别，所以在此处做出阐明。

proxyBeanMethods属性的作用

proxyBeanMethods属性是Spring 5.2.0版本为@Configuration注解新减少的一个属性：

@Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)@Documented@Componentpublic @interface Configuration {    @AliasFor(annotation = Component.class)    String value() default "";    // @since 5.2    boolean proxyBeanMethods() default true;}

它的作用是：是否容许代理@Bean办法。说白了：决定此配置应用Full模式还是Lite模式。为了放弃向下兼容，proxyBeanMethods的默认值是true，应用Full模式配置。

Spring 5.2提出了这个属性项，是冀望你在曾经理解了它的作用之后，显示的把它置为false的，因为在云原生将要到来的明天，启动速度方面Spring始终在做着致力，也心愿你能配合嘛。这不Spring Boot就“配合”得很好，它在2.2.0版本（依赖于Spring 5.2.0）起就把它的所有的主动配置类的此属性改为了false，即@Configuration(proxyBeanMethods = false)。

Full模式/Lite模式实现上的差别

因为Spring 5.2.0新增了proxyBeanMethods属性来管制模式，因而实现上也有些许惊讶，请各位留神甄别：

Spring 5.2.0+版本判断实现：

ConfigurationClassUtils：        Map<String, Object> config = metadata.getAnnotationAttributes(Configuration.class.getName());        if (config != null && !Boolean.FALSE.equals(config.get("proxyBeanMethods"))) {            beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);        } else if (config != null || isConfigurationCandidate(metadata)) {            beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);        } else {            return false;        }

Spring 5.2.0-版本判断实现：

ConfigurationClassUtils：        if (isFullConfigurationCandidate(metadata)) {            beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);        } else if (isLiteConfigurationCandidate(metadata)) {            beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);        } else {            return false;        }

思考题？

  1. 既然isConfigurationCandidate()判断办法是为checkConfigurationClassCandidate()服务，那Spring为何也把它设计为public static呢？
  2. ConfigurationClassUtils里还存在对@Order程序的解析办法，不是说Spring的Bean是无序的吗？这又如何了解呢？

总结

本文作为上篇文章的续篇，解释了@Configuration配置的Full模式和Lite模式的判断原理，同时顺带的也介绍了什么叫主配置配和次配置类，这个概念（尽管官网并不这么叫）对你了解Spring Framework是十分有帮忙的。如果你应用是基于Spring 5.2.0+的版本，在理解了这两篇文章内容的根底上，倡议你的配置类均采纳Lite模式去做，即显示设置proxyBeanMethods = false。

另外对于此局部内容，有些更为感兴趣的小伙伴问到：为什么Full模式下通过办法调用指向的仍旧是原来的Bean，保障了只会执行一次呢？开启的是Full模式这只是表象起因，想要答复此问题须要波及到CGLIB加强实现的深水区内容，为了满足这些好奇（好学）的娃子，打算会在下篇文章持续再拿一篇专程解说（预计篇幅不短，万字以上），你可订阅我的公众号持续保持关注。

关注A哥

  • 原创不易，码字更不易。关注A哥的公众号【BAT的乌托邦】，开启有深度的专栏式学习，回绝浅尝辄止
  • 专栏式学习，咱们是认真的（关注公众号回复“常识星球”领券后再轻装入驻）
  • 加A哥好友（fsx641385712），备注“Java入群”邀你进入【Java高工、架构师】系列纯纯纯技术群