14.Spring整体流程(上)

184 阅读11分钟

Spring源码部分已经写了13篇文章,在这13篇文章中我们讲了BeanDefinition、BeanFactory、AnnotatedBeanDefinitionReader、ClassPathBeanDefinitionScanner、BeanFactoryPostProcessor、BeanDefinitionRegistry。讲了Spring中个人感觉最重要的一个类ConfigurationClassPostProcessor。

之前讲Spring讲的是Spring的部分,或者说只是讲了Spring中的一些组件。但是这些组件是如何协作完成bean的创建与初始化。我们是知道的,不识庐山真面目,只缘身在此山中!

下面的规划是不畏浮云遮望眼,只缘身在最高层!

计划是先站在整体的角度,不过分关注细节,把Spring的整体的流程梳理出来。等我们对Spring的整体有一定的感知以后,再从源码的角度出发,去讲Spring源码中的细节。整个过程会很枯燥或者说痛苦,但是如果能坚持下来必定是收获满满!

等把Spring创建Bean的源码讲完以后,我们会将Spring的循环依赖讲清楚。

最后细讲Spring初始化Bean的源码,也就是代理、切面、事务这一块的内容。

下面开始Spring创建Bean整体流程说明的上半部分。

示例代码

//1.构造AnnotationConfigApplicationContext
AnnotationConfigApplicationContext applicationContext 
                            = new AnnotationConfigApplicationContext();
//2.注册Appconfig为BeanDefintion
applicationContext.register(AppConfig.class);
//
applicationContext.refresh();

1.构造AnnotationConfigApplicationContext

1.0实例化DefaultListableBeanFactory

AnnotationConfigApplicationContext继承自GenericApplicationContext
调用构造方法时需要首先调用父类GenericApplicationContext的构造方法
在GenericApplicationContext的构造方法中会实例化DefaultListableBeanFactory
public GenericApplicationContext() {
   this.beanFactory = new DefaultListableBeanFactory();
}

1.1实例化AnnotatedBeanDefinitionReader

public AnnotationConfigApplicationContext() {
   this.reader = new AnnotatedBeanDefinitionReader(this);
   this.scanner = new ClassPathBeanDefinitionScanner(this);
}

1.1.1注册5个内置的RootBeanDefinition

//这里很重要 注册了5个RootBeanDefinition 
//ConfigurationClassPostProcessor就是在这里被注入的!

//BeanFactoryPostProcessor
//ConfigurationClassPostProcessor主要用于解析beanDefinition
RootBeanDefinition def= new RootBeanDefinition(ConfigurationClassPostProcessor.class);

//BeanPostProcessor
//对@Autowired和@Inject注解的处理
RootBeanDefinition def = new RootBeanDefinition(AutowiredAnnotationBeanPostProcessor.class);

//BeanPostProcessor 具体:InstantiationAwareBeanPostProcessor
//对@PostConstruct和@PreDestroy @Resource等注解的处理
RootBeanDefinition def = new RootBeanDefinition(CommonAnnotationBeanPostProcessor.class);

//SmartInitializingSingleton在创建完bean以后处理
//对@EventListener注解的处理
//主要是标注了@EventListener 的方法进行解析
//在processBean方法中使用DefaultEventListenerFactory的createApplicationListener方法
//转换为一个ApplicationListenerMethodAdapter
//然后放到spring容器中     
RootBeanDefinition def = new RootBeanDefinition(EventListenerMethodProcessor.class);

//EventListenerMethodProcessor中依靠DefaultEventListenerFactory
//创建ApplicationListener
RootBeanDefinition def = new RootBeanDefinition(DefaultEventListenerFactory.class);

1.2实例化ClassPathBeanDefinitionScanner

public AnnotationConfigApplicationContext() {
   this.reader = new AnnotatedBeanDefinitionReader(this);
   this.scanner = new ClassPathBeanDefinitionScanner(this);
}

ClassPathBeanDefinitionScanner的includeFilters注册了@Component 。

@Component 包含 @Controller @Repository @Service

在这里构造了并没有用到。只有使用下面的AnnotationConfigApplicationContext构造方法才能用到。

//BeanPostProcessor
//对@Autowired和@Inject注解的处理
public AnnotationConfigApplicationContext(String... basePackages) {
    this();
    scan(basePackages);
    refresh();
}

2.注册Appconfig为BeanDefintion

执行org.springframework.context.annotation.AnnotationConfigApplicationContext#register方法 跟进org.springframework.context.annotation.AnnotatedBeanDefinitionReader#doRegisterBean方法

将Appconfig解析为1个AnnotatedGenericBeanDefinition

2.1.解析设置属性到bd

2.2put到beanDefintionMap

在上一篇我们已经解释过这个map就是单纯用来存储beanDefinition的,spring后面会遍历这个map根据map当中的beanDefinition来实例化bean,如果Appconfig类的beanDefintion存在map当中那么他必然会被spring容器实例化成为一个bean。

为什么Appconfig会需要实例化呢?

在这里并没有实例化。

因为Appconfig当中有很多加了@Bean的方法,这些方法需要被调用,故而需要实例化,但是Appconfig类的实例化很复杂比一般类实例化过程复杂很多,涉及到代理涉及到cglib等等。

为什么Appconfig类是通过register(Appconfig.class);手动put到map当中呢?为什么不是扫描出来的呢?

一般类都是通过扫描出来的,其实也很简单,因为他无法扫描自己,一般类是spring通过解析Appconfig上的@ComponentScan注解然后被扫描到,但是配置类无法扫描自己;

3.refresh

3.0prepareBeanFactory()

添加了2个BeanPostProcessor:ApplicationContextAwareProcessor和ApplicationListenerDetector

protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
   // Tell the internal bean factory to use the context's class loader etc.
   //AppClassloader
   beanFactory.setBeanClassLoader(getClassLoader());
   //bean表达解析器 为了让beanFactory能够解析bean表达式
   beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
   beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));

   // Configure the bean factory with context callbacks.
   //核心代码 扩展点之一
   //aop也是通过BeanPostProcessor与IOC容器建立了联系
   //ApplicationContextAwareProcessor 实现了BeanPostProcessor
   //在postProcessBeforeInitialization 调用了invokeAwareInterfaces
   //在invokeAwareInterfaces中为bean注入Spring容器内置的对象
   beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));
   //设置忽略以下aware接口
   //为什么要忽略?
   //因为下面的这5个aware接口已经通过ApplicationContextAwareProcessor做了处理
   //需要在bean中注入内置对象 实现对应接口即可。
   //具体可参考
   //https://blog.csdn.net/qq_36951116/article/details/99587519

   /*

        //自动注入会报错
    @Autowired
    ApplicationEventPublisherAware aware;

   */
   beanFactory.ignoreDependencyInterface(EnvironmentAware.class);
   beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);
   beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);
   beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);
   beanFactory.ignoreDependencyInterface(MessageSourceAware.class);
   beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);

   // BeanFactory interface not registered as resolvable type in a plain factory.
   // MessageSource registered (and found for autowiring) as a bean.
   // 自动装配规则设置 当在进行ioc初始化如果1个接口有多个实现 使用指定的对象注入
   // 和@Primary作用差不多
   beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);
   beanFactory.registerResolvableDependency(ResourceLoader.class, this);
   beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);
   beanFactory.registerResolvableDependency(ApplicationContext.class, this);

   // Register early post-processor for detecting inner beans as ApplicationListeners.
   beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));


   //增加对aspectJ的支持在java中 织入分为编译器织入 类加载器织入 加载期织入
   //编译器织入指的是在java编译器采用特殊的编译器 将切面织入java类中
   //而类加载器织入则是通过特殊的类加载器在字节码加载到jvm时织入切面
   //运行期织入指的是cglib 或者 jdk 进行切面织入
   //aspectJ提供了2种注入方式 编译器织入 运行期织入
   //loadTimeWeaver 就是加载期织入

   // Detect a LoadTimeWeaver and prepare for weaving, if found.
   //启用加载时织入,需要将@EnableLoadTimeWeaving加到配置类上
   if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
      beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
      // Set a temporary ClassLoader for type matching.
      beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
   }

   // Register default environment beans.
   //注入3个bean Environment SystemProperties SystemEnvironment
   if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) {
      beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());
   }
   if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) {
      beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());
   }
   if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) {
      beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().getSystemEnvironment());
   }
}

添加ApplicationContextAwareProcessor

/***
添加ApplicationContextAwareProcessor的BeanPostProcessor。
**/
beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));
//忽略aware接口 为什么要忽略?
//因为下面的这5个aware接口会通过上面添加的ApplicationContextAwareProcessor做处理
//ApplicationContextAwareProcessor会调用aware的接口方法在bean中注入内置对象
//所以需要在bean中注入内置对象,实现对应接口即可。通过自动注入反而会报错。
beanFactory.ignoreDependencyInterface(EnvironmentAware.class);
beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);
beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);
beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);
beanFactory.ignoreDependencyInterface(MessageSourceAware.class);
beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);

添加ApplicationListenerDetector

/***  
1.在Bean初始化完成之后:
    如果Bean是单例且bean instanceof ApplicationListener,加入到this.applicationListeners中。

2.在Bean销毁之前搞事情: 
    如果Bean是一个ApplicationListener,则会从ApplicationEventMulticaster(事件广播器)中提前删除。
**/
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));

3.1invokeBeanFactoryPostProcessors():先执行BDRPP

invokeBeanFactoryPostProcessors方法。

3.1.1遍历BeanDefinitionRegistryPP

3.1.2创建BeanDefinitionRegistryPP

3.1.3执行BeanDefinitionRegistryPP

3.1.4执行ConfigurationClassPostProcessor

3.1.5判断是否是配置类&是否被执行过

3.1.6构建解析器,解析配置类

递归解析配置类的内部类

处理@PropertySource配置文件

递归处理@CompentScan

递归处理@Import

@Import注解注入Bean的方式有如下三种

基于Configuration Class

基于ImportSelector&DeferredImportSelector接口

基于ImportBeanDefinitionRegistrar接口

需要注意的是:ImportSelector、DeferredImportSelector、ImportBeanDefinitionRegistrar这三个接口都必须依赖于@Import一起使用,而@Import可以单独使用。

基于ImportSelector接口和ImportBeanDefinitionRegistrar接口的方式都可以从方法上获取AnnotationMetadata(注解元信息)。

那么基于Configuration Class的方式该如何获取AnnotationMetadata呢?

只需要实现ImportAware就可以了。

具体流程

立刻处理ImportSelector,

延迟处理DeferredImportSelector

会在每次parse方法结束后调用 this.deferredImportSelectorHandler.process();

最后调用deferredImportSelector的selectImports

ImportBeanDefinitionRegistrar和@Import注解导入的普通类都会加入集合统一在LoadBeanDefinitions处理!

处理@ImportResource注解

只是将文件加入集合

处理加了@Bean的方法

只是将@Bean的方法加入了1个集合

递归处理接口@Bean默认方法

只是将@Bean的方法加入了1个集合

如果配置类有父类,返回配置类的父类继续解析

loadBeanDefinitions

1.将@Bean注解的方法解析为bd 

2.解析ImportedResource指定的文件导入beanDefinition

1.处理ImportBeanDefinitionRegistrar即@Import导入的类 
调用ImportBeanDefinitionRegistrar的然后全部加入BeanDefinitionMap

//处理@Bean对应的方法
//将他们注册到beanDefinitionMap中
//其实是注册了一个bean
for (BeanMethod beanMethod : configClass.getBeanMethods()) {
    loadBeanDefinitionsForBeanMethod(beanMethod);
}
//导入ImportedResources
//解析文件导入beanDefinition
loadBeanDefinitionsFromImportedResources
            (configClass.getImportedResources());
//导入Registrars注册的bd

3.2invokeBeanFactoryPostProcessors():再执行BFPP

3.2.1遍历BeanFactoryPostProcessor

3.2.2创建BeanFactoryPostProcessor

3.2.3执行BeanFactoryPostProcessor

3.2.4执行ConfigurationClassPostProcessor

//用于增强配置类 给FULL类型的配置类BD增加2个增强回调
enhanceConfigurationClasses(beanFactory);
//这里注册了一个ImportAwareBeanPostProcessor 也是一个BeanPostProcessor
//用于处理实现了ImportAware接口并且带有@Configuration的类
beanFactory.addBeanPostProcessor(new ImportAwareBeanPostProcessor(beanFactory));

3.2.5执行EventListenerMethodProcessor

public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
    this.beanFactory = beanFactory;
    Map<String, EventListenerFactory> beans =   
        beanFactory.getBeansOfType(EventListenerFactory.class, false, false);
    List<EventListenerFactory> factories = new ArrayList<>(beans.values());
    AnnotationAwareOrderComparator.sort(factories);
    this.eventListenerFactories = factories;
}

EventListenerMethodProcessor是1个BeanFactoryPostProcessor,将带有@EventListener注解的方法解析为一个ApplicationListenerAdapter,在这里只会查找并实例化所有的EventListenerFactory,在实例的生命周期结束以后 ,会遍历所有的bean,调用所有SmartInitializingSingleton的afterSingletonsInstantiated方法。

3.3.registerBeanPostProcessors()

注册并实例化

/**
 //创建reader阶段
 AutowiredAnnotationProcessor               实现了PriorityOrdered
 CommonAnnotationProcessor                  实现了PriorityOrdered
 AnnotationAwareAspectJAutoProxyCreator     实现了ordered
 */
String[] postProcessorNames 
    = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false);

/**
 //prepare阶段
 ApplicationContextAwareProcessor
 //prepare阶段
 ApplicationListenerDetector
 //ConfigurationClassPostProcessor作为bfpp被加入
 ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor
*/

//上面3个+下面3个 + 1个 BeanPostProcessorChecker = 7

3.4.finishBeanFactoryInitialization():实例化非懒加载的单例bean

3.4.1preInstantiateSingletons

3.4.1.1扫描beanDefinition放入map

3.4.1.2合并BeanDefinition

3.4.1.3判断FactoryBean类型

FactoryBean类型和非FactoryBean类型走的代码逻辑不一样,但是最终的目的都是为了创建bean。

FactoryBean类型会走下面的代码逻辑

Object bean = getBean(FACTORY_BEAN_PREFIX + beanName);

非FactoryBean类型会走下面的代码逻辑

getBean(beanName);

一般我们的类都是非FactoryBean类型,非FactoryBean类型的类的数量远远大于FactoryBean类型的类的数量。

所以本次只讲FactoryBean类型的类的getBean方法。

FactoryBean类型的类如何创建Bean后面会专门讲。

3.4.1.4.getBean

AbstractBeanFactory#getBean(java.lang.String)
AbstractAutowireCapableBeanFactory#createBean(java.lang.String,RootBeanDefinition, java.lang.Object[])

3.4.1.5createBean

3.4.1.5.1resolveBeforeInstantiation

AbstractAutowireCapableBeanFactory#createBean(java.lang.String, RootBeanDefinition, java.lang.Object[])

在createBean中有如下代码

try {
    // Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.
    // 翻译过来就是给BeanPostProcessors一个机会去返回1个代理而不是目标类的的实例。
    //也就是说我们可以通过BeanPostProcessors偷梁换柱,返回自己想要的Bean,而不是Bean的实例。
    //打个比方有个第三方的框架UserInterface接口 
    //它的实现类是UserServiceA,并且默认注入的是UserServiceA
    //现在有1个需求,想默认注入自定义的UserServiceB怎么实现呢
    //这个时候就可以使用BeanPostProcessor偷梁换柱
    //在BeanPostProcessor中判断 beanName = userService,直接创建1个UserServiceB即可。
    //resolveBeforeInstantiation最大的作用就是给程序员一个机会,干预Bean的创建!
    //并且如果resolveBeforeInstantiation方法有返回bean会直接返回bean
    //下面的createBean方法中的doCreateBean方法不会执行。
    //注意resolveBeforeInstantiation方法返回的对象也是会被代理的!
    Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
    if (bean != null) {
        return bean;
    }
}

在resolveBeforeInstantiation方法中会执行以下2行代码

AbstractAutowireCapableBeanFactory#applyBeanPostProcessorsBeforeInstantiation

AbstractAutowireCapableBeanFactory#applyBeanPostProcessorsAfterInitialization

1.调用BeanPostProcessor#postProcessBeforeInstantiation

2.调用BeanPostProcessor#postProcessAfterInitialization

分别看一下:就是找到BeanPostProcessor然后执行前置方法和后置方法

/***
注意前置方法里做了判断InstantiationAwareBeanPostProcessor
只有InstantiationAwareBeanPostProcessor类型的才会被执行
***/
@Nullable
protected Object applyBeanPostProcessorsBeforeInstantiation(Class<?> beanClass, String beanName) {
    for (BeanPostProcessor bp : getBeanPostProcessors()) {
        if (bp instanceof InstantiationAwareBeanPostProcessor) {
            InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
            Object result = ibp.postProcessBeforeInstantiation(beanClass, beanName);
            if (result != null) {
                return result;
            }
        }
    }
    return null;
}
/***
后置方法并没有像前置方法一样做了判断
***/
@Override
public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
        throws BeansException {
    Object result = existingBean;
    for (BeanPostProcessor processor : getBeanPostProcessors()) {
        Object current = processor.postProcessAfterInitialization(result, beanName);
        if (current == null) {
            return result;
        }
        result = current;
    }
    return result;
}

看一下执行前置方法的逻辑,重点代码是会创建代理

AbstractAutowireCapableBeanFactory#applyBeanPostProcessorsBeforeInstantiation中的逻辑如下

@Nullable
protected Object applyBeanPostProcessorsBeforeInstantiation(Class<?> beanClass, String beanName) {
   for (BeanPostProcessor bp : getBeanPostProcessors()) {
      if (bp instanceof InstantiationAwareBeanPostProcessor) {
         InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
         Object result = ibp.postProcessBeforeInstantiation(beanClass, beanName);
         if (result != null) {
            return result;
         }
      }
   }
   return null;
}

执行InstantiationAwareBeanPostProcessor#postProcessBeforeInstantiation方法。

看看InstantiationAwareBeanPostProcessor的实现类有哪些?

其中有1个AbstractAutoProxyCreator是非常重要的,我们做代理就是通过这个东西。

此时因为没有aop和事务,所以并不会引入AbstractAutoProxyCreator的子类。

此处顺便捎带看下这个方法吧:AbstractAutoProxyCreator#postProcessBeforeInstantiation

@Override
public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) {
    Object cacheKey = getCacheKey(beanClass, beanName);
    if (!StringUtils.hasLength(beanName) || !this.targetSourcedBeans.contains(beanName)) {
        //查看advisedBeans集合是否包含这个类的名字,如果包含就直接返回null了。
        //advisedBeans 就是一个集合,用来保存不需要代理的类。
        //比如我们上面定义的切面本身是不需要被代理的,
        //还有加了@Configuration注解的Config配置类
        //也是不需要代理的,Config其实已经被代理了,之前讲过。
        if (this.advisedBeans.containsKey(cacheKey)) {
            return null;
        }
        //isInfrastructureClass(beanClass) 
        //判断是beanClass的类或接口是否和Advice、Pointcut、Advisor相同,或是否是其超类或超接口。
        //Advice、Pointcut、Advisor等是跟切面相关的,不需要代理。 
        //所以这里不会进入判断 返回的是false
        //shouldSkip返回的是false
        //只要有1个是true户进入判断执行this.advisedBeans.put(cacheKey, Boolean.FALSE);
        //此时说明该bean不会被代理
        //如果2个都是false说明是需要代理
        if (isInfrastructureClass(beanClass) || shouldSkip(beanClass, beanName)) {
            this.advisedBeans.put(cacheKey, Boolean.FALSE);
            return null;
        }
    }
    //继续往下做代理的操作
    TargetSource targetSource = getCustomTargetSource(beanClass, beanName);
    if (targetSource != null) {
        if (StringUtils.hasLength(beanName)) {
            this.targetSourcedBeans.add(beanName);
        }
        Object[] specificInterceptors
                = getAdvicesAndAdvisorsForBean(beanClass, beanName, targetSource);
        Object proxy = createProxy(beanClass, beanName, specificInterceptors, targetSource);
        this.proxyTypes.put(cacheKey, proxy.getClass());
        return proxy;
    }
    return null;
}

疑问:为什么有事务和aop时没有在这里直接返回回去呢?而是继续往下执行了后置方法

因为在resolveBeforeInstantiation方法中创建代理的前提条件是必须存在targetSource。一般情况下不会主动为bean创建targetSource,所以即使存在aop切面和事务,也不会在这里提前创建好bean返回。

换句话说执行到这里的时候AnnotationAwareAspectJAutoProxyCreator创建了吗?

AnnotationAwareAspectJAutoProxyCreator已经创建了。

后置方法被执行有1个前置条件就是前置方法的返回值不能返回空。

后置方法没啥好说的。也是对Bean进行增强的扩展点。

resolveBeforeInstantiation最大的作用就是给程序员一个机会,干预Bean的创建!并且如果resolveBeforeInstantiation方法有返回bean会直接返回bean,下面的doCreateBean不会执行。

resolveBeforeInstantiation最大的作用就是给程序员一个机会,干预Bean的创建!并且如果resolveBeforeInstantiation方法有返回bean会直接返回bean,下面的doCreateBean不会执行。

resolveBeforeInstantiation最大的作用就是给程序员一个机会,干预Bean的创建!并且如果resolveBeforeInstantiation方法有返回bean会直接返回bean,下面的doCreateBean不会执行。

重要的事情说三遍,嗯,就这样。

3.4.1.5.2doCreateBean

Object beanInstance = doCreateBean(beanName, mbdToUse, args);

3.4.1.5.2.1推断构造方法

3.4.1.5.2.2调用构造方法创建对象

3.4.1.5.2.3applyMergedBeanDefinitionPostProcessor

之前一直没搞明白一个事情,为什么对象已经创建了还要再去改BeanDefinition?

原来这里的applyMergedBeanDefinitionPostProcessor是为了查找出满足条件的属性、方法, 将他们封装起来, 以便后面在填充属性的时候可以直接使用。

也就是说这里的扩展点是通过MergedBeanDefinitionPostProcessor干预Bean属性方法等。供下面初始化的时候使用!

//调用 MergedBeanDefinitionPostProcessor
//查找出满足条件的属性、方法, 将他们封装起来, 以便后面在填充属性的时候可以直接使用
//https://juejin.cn/post/6844904167945797640
applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);

3.4.1.5.2.4.populateBean方法填充属性

3.4.1.5.2.5initializeBean()

初始化bean的操作,突然发现看注释,直接能获取的有效信息很多!

/**
 * Initialize the given bean instance, applying factory callbacks
 * as well as init methods and bean post processors.
 * <p>Called from {@link #createBean} for traditionally defined beans,
 * and from {@link #initializeBean} for existing bean instances.
 * @param beanName the bean name in the factory (for debugging purposes)
 * @param bean the new bean instance we may need to initialize
 * @param mbd the bean definition that the bean was created with
 * (can also be {@code null}, if given an existing bean instance)
 * @return the initialized bean instance (potentially wrapped)
 * @see BeanNameAware
 * @see BeanClassLoaderAware
 * @see BeanFactoryAware
 * @see #applyBeanPostProcessorsBeforeInitialization
 * @see #invokeInitMethods
 * @see #applyBeanPostProcessorsAfterInitialization
 */
  • @see BeanNameAware
  • @see BeanClassLoaderAware
  • @see BeanFactoryAware
  • @see #applyBeanPostProcessorsBeforeInitialization
  • @see #invokeInitMethods
  • @see #applyBeanPostProcessorsAfterInitialization

看注释和我们自己总结的差不多,主要是做了这些事情:

1.invokeAwareMethods(beanName, bean);

2.applyBeanPostProcessorsBeforeInitialization#applyBeanPostProcessorsBeforeInitialization

3.invokeInitMethods

4.applyBeanPostProcessorsAfterInitialization#postProcessAfterInitialization

初始化阶段的流程下篇文章会细讲。但是其中设计到的代理切面事务,会放在专栏最后面讲。