共计 15726 个字符，预计需要花费 40 分钟才能阅读完成。
前言
- 上篇博客 spring 5.0.x 源码学习系列四: AnnotationConfigApplicationContext 类 register 办法作用次要介绍了 register 办法的作用。上面咱们将进入初始化 spring 环境最重要的一步:refresh 办法
一、refresh 源码黑箱实践
- 在此篇章中，咱们先把源码中每个办法的执行流程先列进去, 再依据每一个具体的办法进行解析
-
源码
@Override public void refresh() throws BeansException, IllegalStateException {synchronized (this.startupShutdownMonitor) { // Prepare this context for refreshing. prepareRefresh(); // 获取 spring bean 工厂 ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // Prepare the bean factory for use in this context. // 这个办法执行实现, spring 的 bean 单例容器中会存在三个 bean, // 别离是 systemEnvironment, environment, systemProperties // 同时会增加 ApplicationContextAwareProcessor 的后置处理器, 这个处理器没有走 // spring 的 bean 初始化, 是在外部间接 new 进去的, 该处理器是用来解决实现了 // ApplicationContextAware 接口的 bean, 调用重写的 set 办法, 所以能够利用 // 这种办法获取 spring 的上下文对象 prepareBeanFactory(beanFactory); try { // 该办法没有做任何事, 外部无任何逻辑 postProcessBeanFactory(beanFactory); // 调用后置处理器, 此办法太重要了, 在后续的源码解读系列中会解析它 // 先大抵总结下它做了什么事 // 1. 解决手动增加的 BeanFactoryPostProcessor // 1.1 调用手动增加的 BeanDefinitionRegistryPostProcessor, 并增加到存储它的汇合中, // 该汇合名字为: registryProcessors // 1.2 存储手动增加的 BeanFactoryPostProcessor, // 该汇合名字为: regularPostProcessors // 留神: 下面这个步骤是 if else 逻辑, 存了一个另外一个就不会存了 // 2. 执行 BeanDefinitionRegistryPostProcessor 类型且实现了 PriorityOrdered 接 // 口的后置处理器. 默认执行 spring 内置 BeanDefinitionRegistryPostProcessor // 后置处理器(ConfigurationClassPostProcessor), 这个后置处理器执行完之后, // 所有能被扫描进去的 bean 都以 BeanDefinition 的形式注册到 bean 工厂了 // 3. 执行 BeanDefinitionRegistryPostProcessor 类型且实现了 // Ordered 接口的后置处理器 // 4. 执行以 @Component 形式增加的 BeanDefinitionRegistryPostProcessor 类型没实现 // Ordered 和 PriorityOrdered 接口的后置处理器 // 5. 执行 regularPostProcessors 和 registryProcessors 数据结构中 // BeanFactoryPostProcessor 类型的后置处理器(在此处执行 // ConfigurationClassPostProcessor 类的 postProcessBeanFactory 办法, 次要是 // 为全配置类生成了 cglib 代理类的 Class 对象, 并批改它的 beanDefinition 信息为代 // 理类的信息 // 6. 执行以 @Component 模式增加并实现了 PriorityOrdered 接口的 BeanFactoryPost // Processor 后置处理器 // 7. 执行以 @Component 模式增加并实现了 Ordered 接口的 BeanFactoryPost // Processor 后置处理器 // 8. 执行以 @Component 模式增加并未实现 PriorityOrdered 和 Ordered 接口的 Bean // FactoryPostProcessor 后置处理器 invokeBeanFactoryPostProcessors(beanFactory); // 注册 spring bean 工厂的 BeanPostProcessor // 其中包含 spring 内置的、扫描进去的(eg: 应用 ImportBeanDefinitionRegistrar, AOP 的实现形式)、// 本人手动增加的(手动增加 BeanDefinitionRegistryPostProcessor, // 并在其中注册一个 BeanPostProcessor 的 bean) // // 默认状况下, spring 内置的 3 个 BeanPostProcessor 别离为: // org.springframework.context.annotation.internalAutowiredAnnotationProcessor => 解决 @Autowired 注解的 // org.springframework.context.annotation.internalRequiredAnnotationProcessor => 解决 @Required 注解的 // org.springframework.context.annotation.internalCommonAnnotationProcessor => 解决 Common 注解的后置处理器 // 以及各种实现了 PriorityOrdered 接口、Ordered 接口的 BeanPostProcessor 解决 // 最次要的就是把这些 bean 通过 spring bean 工厂创立进去, 并增加到一个寄存 BeanPostProcessor 的 list 中, 再利用播送 // 机制调用 // 我感觉这里用 list 而不必 set 的起因有两个 // 1. list 是有序的, 因为有些 BeanPostProcessor 会实现 PriorityOrdered 接口、Ordered 接口, 所以要依照肯定的程序执行 // 2. 播送机制时要遍历汇合, list 遍历速度快一些 registerBeanPostProcessors(beanFactory); // Initialize message source for this context. // 国际化 initMessageSource(); // Initialize event multicaster for this context. // 初始化 spring 事件驱动模型的执行者 initApplicationEventMulticaster(); // 该办法没有做任何事, 外部无任何逻辑 onRefresh(); // 注册本人手动增加的监听器和 spring 扫描进去的监听器 // 手动增加的监听器: 调用 spring 上下文的 addApplicationListener 办法, eg: AnnotationConfigApplicationContext 上下文的办法 // spring 扫描进去的监听器: 有 @Component 注解标识的监听器 // 这里有人会问: 万一我一个监听器同时加了 @Component 注解也手动调用了 addApplicationListener 增加呢？// 没关系, 那就执行两次呗, 因为 spring 解决手动增加的和扫描进去的监听器是不一样的, 手动增加的是一个 java 对象, 而 spring 扫描进去 // 的监听器是一个 bean, 所以这两个监听器是同一类型的不同对象 // 但要留神的是, 手动增加的监听器是一个 java object, 而 spring 扫描进去的是一个 bean registerListeners(); // 开始创立非形象、非原型、非懒加载的 bean 以及解决 bean 的主动拆卸 finishBeanFactoryInitialization(beanFactory); // 实现刷新, 公布相应的事件 finishRefresh();} catch (BeansException ex) {if (logger.isWarnEnabled()) { logger.warn("Exception encountered during context initialization -" + "cancelling refresh attempt:" + ex); } // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset 'active' flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } finally { // Reset common introspection caches in Spring's core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches();} } } -
总结
- 由源码中的正文可知:
refresh办法次要做的就是 填充 spring 的整个 bean 环境(之前的 spring 环境都是空壳), 包含扫描 bean，初始化非形象、单例、非懒加载的 bean, 以及初始化 spring 事件驱动模型。 - 这里提供下 spring 上下文环境的图, 不便了解大抵构造
- 由源码中的正文可知:
二、本篇博客的配角: invokeBeanFactoryPostProcessor 办法
- 流程图
-
源码正文
public static void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) { // Invoke BeanDefinitionRegistryPostProcessors first, if any. Set<String> processedBeans = new HashSet<>(); // 传入的 bean 工厂 DefaultListableBeanFactory 也是一个 BeanDefinitionRegistry, 它实现了这个接口 if (beanFactory instanceof BeanDefinitionRegistry) {BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory; // 用来存储手动增加 BeanFactoryPostProcessor 的处理器, // eg: context.addBeanFactoryPostProcessor(new MyBeanDefinitionRegistryPostProcessor()); // 其中 context 是 AnnotationConfigApplicationContext 对象, 然而它只是执行到了父类 AbstractApplicationContext 的办法 List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>(); // 用来存储手动增加 BeanDefinitionRegistryPostProcessor 的处理器, 也是执行上述正文中说的办法 // 因为 BeanFactoryPostProcessor 有一个子类叫 BeanDefinitionRegistryPostProcessor // regularPostProcessors 和 registryProcessors 这两个 list 只是为了存储手动增加的 BeanFactoryPostProcessor List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>(); for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) { BeanDefinitionRegistryPostProcessor registryProcessor = (BeanDefinitionRegistryPostProcessor) postProcessor; // 对于手动增加的 BeanDefinitionRegistryPostProcessor 会在这里第一次被调用, 所以这里是后置处理器第一次被调用的中央 registryProcessor.postProcessBeanDefinitionRegistry(registry); // 存储手动增加的 BeanDefinitionRegistryPostProcessor, 后续会用到 registryProcessors.add(registryProcessor); } else { // 存储手动增加的 BeanFactoryPostProcessor, 后续会用到 regularPostProcessors.add(postProcessor); } } // 这个 list 是用来存储 spring 内置的 BeanFactoryPostProcessor List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>(); // 这里是调用实现了 PriorityOrdered 接口的 BeanDefinitionRegistryPostProcessor 后置处理器 // 这里只是获取, 调用是在上面的 invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry); 实现的 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); } } sortPostProcessors(currentRegistryProcessors, beanFactory); registryProcessors.addAll(currentRegistryProcessors); // 这里首先调用的类是 spring 内置 beanName 叫 org.springframework.context.annotation.internalConfigurationAnnotationProcessor, // 类名叫 ConfigurationClassPostProcessor 的 bean // 因为在 spring 内置的 6 个 bean 中只有它是实现了 BeanDefinitionRegistryPostProcessor 接口 // 所以 ConfigurationClassPostProcessor 类这一次被调用的次要目标是: // 1. 为 bean 工厂生成 factoryId 并记录起来 // 2. 循环解析传入的配置类(即传入 register 办法中的几个 Class 类对应的类) // 2.1 依据类获取他们的 BeanDefinition, 来判断 BeanDefinition 是否为 AnnotatedBeanDefinition 类型(因为目前是思考 java config 模式, 所以只思考这种类型) // 2.2 判断传入类是否加了 @Configuration 注解或者 (@Component 和 @ComponentScan 和 @Import 和 ImportResource 注解) 或者外部是否有办法增加了 @Bean 注解并解析他们 invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry); currentRegistryProcessors.clear(); // Next, invoke the BeanDefinitionRegistryPostProcessors that implement Ordered. postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false); for (String ppName : postProcessorNames) {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); invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry); currentRegistryProcessors.clear(); // Finally, invoke all other BeanDefinitionRegistryPostProcessors until no further ones appear. 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();} // Now, invoke the postProcessBeanFactory callback of all processors handled so far. // 这里是第一次调用手动增加到 spring 的 BeanDefinitionRegistryPostProcessor 的重写 BeanFactoryPostProcessors 接口的 (postProcessBeanFactory) 办法 // 因为 BeanDefinitionRegistryPostProcessor 是继承 BeanFactoryPostProcessor 类。所以也重写了 BeanFactoryPostProcessor 的办法 // 在第一次调用时只调用了 BeanDefinitionRegisterPostProcessor 中的办法 invokeBeanFactoryPostProcessors(registryProcessors, beanFactory); // 这里是第一次调用手动增加到 spring 的 BeanFactoryPostProcessor invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory); } else { // Invoke factory processors registered with the context instance. invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory); } // Do not initialize FactoryBeans here: We need to leave all regular beans // uninitialized to let the bean factory post-processors apply to them! // 这里是调用非手动增加的 BeanFactoryPostProcessor 后置处理器, 即应用了 @Component 注解 // 因为在上一步调用 ConfigurationClassPostProcessor 这种类型 (BeanDefinitionRegistryBeanFactory) 的后置处理器时, 对包曾经扫描胜利，// 并将扫描进去的类信息封装成 ScannedGenericBeanDefinition 的 BeanDefinition 了, 所以依据类型找出的来的 bean 包含以注解的形式注册的 // BeanFactoryPostProcessor，但也包含 ConfigurationClassPostProcessor, 因为它实现的 BeanDefinitionRegistryBeanFactory 接口也 // 继承了 BeanFactoryPostProcessor 接口 String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false); // Separate between BeanFactoryPostProcessors that implement PriorityOrdered, // Ordered, and the rest. List<BeanFactoryPostProcessor> priorityOrderedPostProcessors = new ArrayList<>(); List<String> orderedPostProcessorNames = new ArrayList<>(); List<String> nonOrderedPostProcessorNames = new ArrayList<>(); for (String ppName : postProcessorNames) {if (processedBeans.contains(ppName)) {// skip - already processed in first phase above} 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); } } // First, invoke the BeanFactoryPostProcessors that implement PriorityOrdered. // 解析实现了 PriorityOrdered 接口的 BeanFactoryPostProcessor 并按程序执行 sortPostProcessors(priorityOrderedPostProcessors, beanFactory); invokeBeanFactoryPostProcessors(priorityOrderedPostProcessors, beanFactory); // 解析实现了 Ordered 接口的 BeanFactoryPostProcessor 并按程序执行 List<BeanFactoryPostProcessor> orderedPostProcessors = new ArrayList<>(); for (String postProcessorName : orderedPostProcessorNames) {orderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class)); } sortPostProcessors(orderedPostProcessors, beanFactory); invokeBeanFactoryPostProcessors(orderedPostProcessors, beanFactory); // 调用实现了没有实现 PriorityOrdered 和 Ordered 接口的 BeanFactoryPostProcessor 的后置处理器 List<BeanFactoryPostProcessor> nonOrderedPostProcessors = new ArrayList<>(); for (String postProcessorName : nonOrderedPostProcessorNames) {nonOrderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class)); } invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, beanFactory); // Clear cached merged bean definitions since the post-processors might have // modified the original metadata, e.g. replacing placeholders in values... beanFactory.clearMetadataCache();}
三、我的项目测试 demo
3.1 我的项目构造
3.1.1 构造全景图
3.1.2 各类详情与作用
- 我的项目入口(启动 spring 环境的入口)
- 全配置类, 定义扫描的包
- 手动增加的 BeanDefinitionRegistryPostProcessor
- 手动增加的 BeanFactoryPostProcessor
- 由 spring 扫描进去的 BeanDefinitionRegistryPostProcessor 但无实现 Ordered 和 PriorityOrdered 接口
- 由 spring 扫描进去的 BeanDefinitionRegistryPostProcessor 实现了 Ordered 接口, 且权重为 1 => 权重低, 优先执行
- 由 spring 扫描进去的 BeanDefinitionRegistryPostProcessor 实现了 Ordered 接口, 且权重为 2 => 权重低, 优先执行
- 由 spring 扫描进去的 BeanDefinitionRegistryPostProcessor 实现了 PriorityOrdered 接口, 且权重为 1 => 权重低, 优先执行
- 由 spring 扫描进去的 BeanDefinitionRegistryPostProcessor 实现了 PriorityOrdered 接口, 且权重为 2 => 权重低, 优先执行
- 由 spring 扫描进去的 BeanFactoryPostProcessor
- 由 spring 扫描进去的 BeanFactoryPostProcessor 实现了 Ordered 接口, 且权重为 1 => 权重越低, 越优先执行
- 由 spring 扫描进去的 BeanFactoryPostProcessor 实现了 Ordered 接口, 且权重为 2 => 权重越低, 越优先执行
- 由 spring 扫描进去的 BeanFactoryPostProcessor 实现了 PriorityOrdered 接口, 且权重为 1 => 权重越低, 越优先执行
- 由 spring 扫描进去的 BeanFactoryPostProcessor 实现了 PriorityOrdered 接口, 且权重为 2 => 权重越低, 越优先执行
3.2 执行流程及原理
3.2.1 解决手动增加的 BeanFactoryPostProcessor(蕴含 BeanDefinitionRegistryPostProcessor 和 BeanFactoryPostProcessor)
3.2.2 执行 BeanDefinitionRegistryPostProcessor 类型且实现了 PriorityOrdered 接口的后置处理器
此步骤十分重要, 后续将专门为此步骤总结一篇博客, 来具体形容它做了些什么事
3.2.3 执行 BeanDefinitionRegistryPostProcessor 类型且实现了 Ordered 接口的后置处理器，执行过程与第二步大同小异
3.2.4 执行 BeanDefinitionRegistryPostProcessor 类型且未实现 Ordered 接口和 PriorityOrdered 接口的后置处理器，执行过程与第三步大同小异
3.2.5 解决 BeanDefinitionRegistryPostProcessor 类型的 BeanFactoryPostProcessor
-
上述 4 步都是调用 BeanDefinitionRegistryPostProcessor 类型的后置处理器, 前面将开始调用 BeanFactoryPostProcessor 类型的后置处理器。因为还有 手动增加 BeanDefinitionRegistryPostProcessor 也是 BeanFactoryPostProcessor 类型的后置处理器(继承), 所以此步骤将开始调用手动增加的 BeanDefinitionRegistryPostProcessor 后置处理器的 BeanFactoryPostProcessor 中的办法以及手动增加的 BeanFactoryPostProcessor
// Now, invoke the postProcessBeanFactory callback of all processors handled so far. // 这里是第一次调用手动增加到 spring 的 BeanDefinitionRegistryPostProcessor 的重写 BeanFactoryPostProcessors 接口的 (postProcessBeanFactory) 办法 // 因为 BeanDefinitionRegistryPostProcessor 是继承 BeanFactoryPostProcessor 类。所以也重写了 BeanFactoryPostProcessor 的办法 // 在第一次调用时只调用了 BeanDefinitionRegisterPostProcessor 中的办法 invokeBeanFactoryPostProcessors(registryProcessors, beanFactory); // 这里是第一次调用手动增加到 spring 的 BeanFactoryPostProcessor invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
3.2.6 执行以 @Component 模式增加并实现了 PriorityOrdered 接口的 BeanFactoryPostProcessor 后置处理器
3.2.7 执行以 @Component 模式增加并实现了 Ordered 接口的 BeanFactoryPostProcessor 后置处理器
3.3 对于 ”3.2.3 执行 BeanDefinitionRegistryPostProcessor 类型且实现了 Ordered 接口的后置处理器，执行过程与第二步大同小异 ” 的两个疑难
- 原图
| 问题 | 答案 |
|---|---|
| Q1: 为什么这里也执行了实现 PriorityOrdered 接口的后置处理器？下面不是曾经执行过了吗？ | 因为 PriorityOrdered 接口继承了 Ordered 接口, 所以在解决实现 Ordered 类型的接口时, 也会把实现 PriorityOrdered 接口的后置处理器也拿进去。同时之前确实曾经执行过了实现了 PriorityOrdered 接口的后置处理器(ConfigurationClassPostProcessor), 但这是一个非凡的后置处理器, 因为它，咱们能力在前面获取 @Component 注解模式增加的后置处理器。最重要的是在执行它的时候, bean 工厂中只有一个实现了 PriorityOrdered 接口的 BeanDefinitionRegistryPostProcessor 类型的后置处理器, 所以 spring 才用了 processedBeans 的 set 汇合来存储曾经执行过的后置处理器 |
| Q2: 为什么只执行了 postProcessorNames 的 2,3,4,5 下标的后置处理器？ | 因为它们都实现了 Ordered 接口, 只管有些后置处理器实现的是 PriorityOrdered 接口, 但 PriorityOrdered 接口继承了 Ordered 接口 |
三、小结
- invokeBeanFactoryPostProcessor办法的次要作用就是调用后置处理器, 这里最须要次要到的一个后置处理器就是 ConfigurationClassPostProcessor, 它不仅做了扫描工作还做了为全配置类生成 cglib 代理对象的工作(因为它有两个身份: 一个是BeandefinitionRegistryPostProcessor 另一个是BeanFactoryPostProcessor)
-
对于 BeanDefinitionRegistryPostProcesso r 和BeanFactoryPostProcessor 后置处理器的区别和作用
类型 提供 api 作用 BeanDefinitionRegistryPostProcessor BeanDefinitionRegistry 是一个 beanDefinition 的注册器, 个别用它来注册一个 beanDefinition BeanFactoryPostProcessor ConfigurableListableBeanFactory 其实就是 spring 的 bean 工厂, 只不过是用父类来接管。bean 工厂都能够拿到了, 咱们能够对 bean 做不可形容的事件了，比方扭转 bean 的 class 为它创立代理对象, -
应用 BeanDefinitionRegistryPostProcessor和 BeanFactoryPostProcessor 后置处理器的注意事项
- 得明确每个后置处理器的执行程序 eg: 手动增加的BeanDefinitionRegistryPostProcessor 类型的后置处理器, 比 spring 内置和以 @Component 形式增加的后置处理器都先执行
- 相熟实现不同接口的后置处理器的执行程序, eg: BeanDefinitionRegistryPostProcessor和 BeanFactoryPostProcessor 类型的后置处理器都是优先解决实现 PriorityOrdered 接口
- spring 源码学习对应 GitHub 地址 https://github.com/AvengerEug/spring/tree/develop/resourcecode-study
- I am a slow walker, but I never walk backwards.
正文完
