第21集 refresh-invokeBeanFactoryPostProcessor-下半部分BeanFactoryPostPrcessor处理

【视频来源于：B站up主孙帅suns Spring源码视频】【微信号：suns45】

1、注解处理添加的的BeanDefinitionRegistryFactoryProcessor在哪个地方？

在第一个invokeBeanDefinitionRegistryPostProcessors中处理ConfiguraitonClassPostProcessor

2、beanFactory.getBeanNamesForType获取到的有什么BeanPostProcessor？

3、为什么add加入BeanFactoryPostProcessor没有注册？

因为new了没有注册，正常情况下应该是自己把添加的BeanDefinitionRegistryPostProcessor给注册了，这样才合乎情理。

4、Spring的设计缺点

因为new了没有注册，正常情况下应该是自己把添加的BeanDefinitionRegistryPostProcessor给注册了也就是添加到BeanDefinitionMap，这样才合乎情理。

5、整个下方其实的处理逻辑是什么？

因为，在上方处理的时候 会把@Component的BeanFactoryPostProcessor进行注册，上方的处理逻辑只会处理BeanDefinitionRegistryPostProcessor的父接口【postProcessBeanFactory】和子接口【postProcessBeanDefinitionRegistry】，下方的只会处理注解添加的BeanFactoryPostProcessor【postProcessBeanFactory】以及自带的EventListenerProcessor【postProcessBeanFactory】

6、总结第21集

• refresh的invokeBeanFactoryPostProcessor方法从两个角度处理BeanFactoryPostProcessor以及BeanDefinitionRegistryPostPrcessor，
  • 第一个角度就是 Spring自带的CofigurationClassPostProcessor【BeanDefinitionRegistryPostPrcessor 】还有就是EventListenerProcessor【BeanFactoryProcessor】
  • 第二个角度就是 程序猿自己通过手工或者注解【@Component @Configuration】方式添加的BeanFactoryPostProcessor还有BeanDefinitionRegistryPostPrcessor
• refresh的invokeBeanFactoryPostProcessor方法，刚开始先经历一个for循环处理手工添加的，如果你手工添加的有BeanDefinitionRegistryPostPrcessor A 那么 A和CofigurationClassPostProcessor会在第一次InvokeBeanDefinitionRegistryPostProcessors进行处理，然后会在以相同的逻辑后面处理EventListenerProcessor【BeanFactoryProcessor】
• 请注意手动add的BeanFactoryProcessor和BeanDefinitionRegistryPostPrcessor 是不会注册成BeanDefinition。

7、从第17集-21集的总结

refresh的invokeBeanFactoryPostProcessor方法的作用：其实就是调用postProcessBeanDefinitionRegistry的 processConfigBeanDefinitions完成了我们开发过程中所涉及到的应用不同的形式和应用不同的注解，最后BeanDefinition注册完成的工作。
6.1:、正常情况下，分为上下两个处理过程，如果我们不手动添加，上半部分只会处理CofigurationClassPostProcessor【BeanDefinitionRegistryPostPrcessor 】 CofigurationClassPostProcessor处理顶级注解，这个还分为两个类型一个FullConfiguration还有一个LiteConfiguration以及一个不属于任何的@PropertySource

• FullConfiguration
  • @Configuration
• LiteConfiguration
  • @Component
  • @CompeontScan
  • @ImportResource

1. FullConfiguration (完全模式)

• 使用 @Configuration 注解的 Java 类定义。
• Spring 容器会通过 CGLIB 代理提高 Bean 的创建过程。
• 支持定义有状态的 Bean 单例（有状态的单例在多线程环境下需要注意）。
• 优点：支持更复杂的依赖注入与管理。
• 缺点：在大型项目中可能导致启动时间较长及资源占用较多。

2. LiteConfiguration (轻量模式)

• 不使用 @Configuration 注解，而直接使用普通类定义。
• Spring 容器不会使用 CGLIB 对这些类进行代理。
• 通常用于简单的配置场景，如第三方库的内置自动配置等。
• 推荐使用无状态的 Bean 单例，避免潜在的多线程问题。
• 优点：启动速度较快，资源占用较少，更适合大型项目或微服务架构。
• 缺点：相较于 FullConfiguration，功能稍有限制，不支持某些高级功能。

总之，根据项目需求和团队习惯，可以灵活选择适合的配置方式。FullConfiguration 提供强大、深度的定制能力，适用于复杂的系统；而 LiteConfiguration 更轻量、快速，适用于简单或大型项目中。

接着会继续调用两次invokeBeanFactoryPostProcessors，其实处理的都是BeanDefinitionRegistryPostPrcessor的父类接口，一个是registryProcessors处理@Configuration通过 CGLIB 代理提高 Bean 的创建过程 也就是说非AppConfig中的@Configuration @Bean返回new User保证前后都是一致的 那怕它加了其他注解 @Lazy @Primary @DependOn，regularPostProcessors处理的是手工添加的BeanFactoryProcessor

6.2、下半部分处理的是EventListenerProcessor【BeanFactoryProcessor】，如果你是注解添加的BeanFactoryProcessor也会在这里进行处理的，这里之所以出现这种情况就是上方在处理ConfigurationClassPostPrcessor的时候帮你注册了@Component的BeanFactoryProcessor，而上方只处理BeanDefinitionRegistryPostPrcessor的父子接口。

6.3、请注意手动add的BeanFactoryProcessor和BeanDefinitionRegistryPostPrcessor 是不会注册成BeanDefinition。