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