皮皮网

1.springbean初始化和实例化？
2.spring源码解析bean初始化与依赖注入四
3.Spring 初始化
4.Spring IoC：getBean 详解
5.Spring源码-09-Bean工厂之getBean方法

springbean初始化和实例化？

       spring配置bean实例化有哪些方式

       1.实例化bean的源码三种方法:

       （1）构造器

       !--体验1--

       beanid="personService"class="com.persia.PersonServiceBean"

       !--index代表方法的参数序号，由0开始，源码基本的源码类型Type可以不声明--

       constructor-argindex="0"value="构造注入的name"/

       constructor-argindex="1"type="com.persia.IDaoBean"ref="personDao"/

       /bean

       对应类

       publicPersonServiceBean(Stringname,IDaoBeanpersonDao){

       this.name=name;

       this.personDao=personDao;

       }

       !--体现2--

       beanid="personDao"class="cn.itcast.dao.impl.PersonDaoBean"/

       beanid="personServiceBean"class="cn.itcast.service.impl.PersonServiceBean"

       lazy-init="true"init-method="init"destroy-method="destory"

       !--ref属性对应idpersonDao值name属性对应接口的getter方法名称--

       propertyname="personDao"ref="personDao"/

       !--体验3--

       !--注入属性值--

       propertyname="name"value=""/

       !--Set的注入--

       propertyname="sets"

       set

       valuesets：第一个值/value

       valuesets：第二个值/value

       valuesets：第三个值/value

       /set

       /property

       !--List的注入--

       propertyname="lists"

       list

       valuelists：第一个值/value

       valuelists：第二个值/value

       valuelists：第三个值/value

       /list

       /property

       !--Properties的注入--

       propertyname="properties"

       props

       propkey="props-key1"：第一个值/prop

       propkey="props-key2"：第二个值/prop

       propkey="props-key3"：第三个值/prop

       /props

       /property

       !--Map的注入--

       propertyname="maps"

       map

       entrykey="maps-key1"value="：第一个值"/

       entrykey="maps-key2"value="：第二个值"/

       entrykey="maps-key3"value="：第三个值"/

       /map

       /property

       /bean

       （2）静态工厂：

       !--静态工厂获取bean--

       beanid="personService2"class="com.persia.PersonServiceBeanFactory"factory-method="createInstance"/

       对应类

       publicstaticPersonServiceBeancreateInstance(){

       returnnewPersonServiceBean();

       }

       （3）实例工厂：

       没有静态方法，因此配置时，源码先实例化工厂，源码在实例化需要的源码时间统计网站源码bean。

       !--实例工厂获取bean，源码先实例化工厂再实例化bean--

       beanid="fac"class="com.persia.PersonServiceBeanInsFactory"/

       beanid="personService3"factory-bean="fac"factory-method="createInstance"/

       对应类

       publicPersonServiceBeancreateInstance(){

       returnnewPersonServiceBean();

       }

       2.bean的源码作用域

       默认情况为单例方式：scope=”singleton”

       singleton

       单实例作用域，这是源码Spring容器默认的作用域，使用singleton作用域生成的源码是单实例，在整个Bean容器中仅保留一个实例对象供所有调用者共享引用。源码单例模式对于那些无会话状态的源码Bean（如辅助工具类、DAO组件、源码业务逻辑组件等）是源码最理想的选择。

       prototype

       原型模式，源码这是多实例作用域，针对每次不同的请求，Bean容器均会生成一个全新的Bean实例以供调用者使用。prototype作用域非常适用于那些需要保持会话状态的Bean实例，有一点值得注意的就是，Spring不能对一个prototype

       Bean的整个生命周期负责，容器在初始化、装配好一个prototype实例后，将它交给客户端，随后就对该prototype实例不闻不问了。因此，客户端要负责prototype实例的生命周期管理。

       request

       针对每次HTTP请求，Spring容器会根据Bean的定义创建一个全新的Bean实例，

       且该Bean实例仅在当前HTTPrequest内有效，因此可以根据需要放心地更改所建实例的内部状态，

       而其他请求中根据Bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。

       当处理请求结束，request作用域的Bean实例将被销毁。该作用域仅在基于web的Spring

       ApplicationContext情形下有效。

       session

       针对某个HTTP

       Session，Spring容器会根据Bean定义创建一个全新的Bean实例，且该Bean实例仅在当前HTTPSession内有效。

       与request作用域一样，我们可以根据需要放心地更改所创建实例的内部状态，而别的HTTPSession中根据Bean定义创建的实例，

       将不会看到这些特定于某个HTTPSession的状态变化。当HTTPSession最终被废弃的时候，在该HTTP

       Session作用域内的Bean实例也会被废弃掉。该作用域仅在基于Web的SpringApplicationContext情形下有效。

       globalsession

       global

       session作用域类似于标准的HTTP

       Session作用域，不过它仅仅在基于portlet的骰子 游戏源码Web应用中才有意义。portlet规范定义了全局Session的概念，它被所有构成某个portlet

       Web应用的各种不同的portlet所共享。在globalsession作用域中定义的Bean被限定于全局portlet

       Session的生命周期范围内。如果我们是在编写一个标准的基于Servlet的Web应用，并且定义了一个或多个具有global

       session作用域的Bean，系统会使用标准的HTTPSession作用域，并且不会引起任何错误。该作用域仅在基于Web的Spring

       ApplicationContext情形下有效。

       3.bean的生命周期

       （1）什么时候实例化？

       对于单例的形式，在容器实例化的时候对bean进行实例化的。

       ApplicationContextctx=newClassPathXmlApplicationContext(newString[]{ "applicationContext.xml"});

       单实例可以通过lazy-init=”true”，在getBean时进行实例化。

       在beans里面default-lazy-init=”true”对所有bean进行延迟处理。

       对于prototype，则是在getBean的时候被实例化的。

       （2）在bean被实例化之后执行资源操作等方法：

       Init-method=””

       （3）在bean销毁之前执行的方法：

       Destroy-method=””

       什么时候被销毁？随着spring容器被关闭时被销毁。

       调用spring容器的close方法来正常关闭。以前是随着应用程序执行完而关闭。

       在Spring装载配置文件后，Spring工厂实例化完成，开始处理

       （1）使用默认构造方法或指定构造参数进行Bean实例化。

       （2）根据property标签的配置调用Bean实例中的相关set方法完成属性的赋值。

       （3）如果Bean实现了BeanNameAware接口，则调用setBeanName()方法传入当前Bean的ID。

       （4）如果Bean实现了BeanFactoryAware接口，则调用setBeanFactory()方法传入当前工厂实例的引用。

       （5）如果Bean实现了ApplicationContextAware接口，则调用setApplicationContext()方法传入当前ApplicationContext实例的引用。

       （6）如果有BeanPostProcessor与当前Bean关联，则与之关联的对象的postProcess-BeforeInitialzation()方法将被调用。

       （7）如果在配置文件中配置Bean时设置了init-method属性，则调用该属性指定的初始化方法。

       （8）如果有BeanPostProcessor与当前Bean关联，则与之关联的对象的postProcess-AfterInitialzation()方法将被调用。

       （9）Bean实例化完成，处于待用状态，可以被正常使用了。

       （）当Spring容器关闭时，如果Bean实现了DisposableBean接口，则destroy()方法将被调用。

       （）如果在配置文件中配置Bean时设置了destroy-method属性，则调用该属性指定的方法进行销毁前的一些处理。

       （）Bean实例被正常销毁。

       Spring系列（一）SpringMVCbean解析、注册、实例化流程源码剖析

       最近在使用SpringMVC过程中遇到了一些问题，网上搜索不少帖子后虽然找到了答案和解决方法，签名驱动源码但这些答案大部分都只是给了结论，并没有说明具体原因，感觉总是有点不太满意。

       更重要的是这些所谓的结论大多是抄来抄去，基本源自一家，真实性也有待考证。

       那作为程序员怎么能知其所以然呢？

       此处请大家内心默读三遍。

       用过Spring的人都知道其核心就是IOC和AOP，因此要想了解Spring机制就得先从这两点入手，本文主要通过对IOC部分的机制进行介绍。

       在开始阅读之前，先准备好以下实验材料。

       IDEA是一个优秀的开发工具，如果还在用Eclipse的建议切换到此工具进行。

       IDEA有很多的快捷键，在分析过程中建议大家多用Ctrl+Alt+B快捷键，可以快速定位到实现函数。

       Springbean的加载主要分为以下6步：

       查看源码第一步是找到程序入口，再以入口为突破口，一步步进行源码跟踪。

       JavaWeb应用中的入口就是web.xml。

       在web.xml找到ContextLoaderListener，此Listener负责初始化SpringIOC。

       contextConfigLocation参数设置了bean定义文件地址。

       下面是ContextLoaderListener的官方定义：

       翻译过来ContextLoaderListener作用就是负责启动和关闭SpringrootWebApplicationContext。

       具体WebApplicationContext是什么？开始看源码。

       从源码看出此Listener主要有两个函数，一个负责初始化WebApplicationContext，一个负责销毁。

       继续看initWebApplicationContext函数。

       在上面的代码中主要有两个功能：

       进入CreateWebAPPlicationContext函数

       进入determineContextClass函数。

       进入configureAndReFreshWebApplicaitonContext函数。

       WebApplicationContext有很多实现类。但从上面determineContextClass得知此处wac实际上是XmlWebApplicationContext类，因此进入XmlWebApplication类查看其继承的refresh()方法。

       沿方法调用栈一层层看下去。

       获取beanFactory。

       beanFactory初始化。

       加载bean。

       读取XML配置文件。

       XmlBeanDefinitionReader读取XML文件中的bean定义。

       继续查看loadBeanDefinitons函数调用栈，进入到XmlBeanDefinitioReader类的loadBeanDefinitions方法。

       最终将XML文件解析成Document文档对象。

       上一步完成了XML文件的解析工作，接下来将XML中定义的bean注册到webApplicationContext，继续跟踪函数。tor源码包

       用BeanDefinitionDocumentReader对象来注册bean。

       解析XML文档。

       循环解析XML文档中的每个元素。

       下面是默认命名空间的解析逻辑。

       不明白Spring的命名空间的可以网上查一下，其实类似于package，用来区分变量来源，防止变量重名。

       这里我们就不一一跟踪，以解析bean元素为例继续展开。

       解析bean元素，最后把每个bean解析为一个包含bean所有信息的BeanDefinitionHolder对象。

       接下来将解析到的bean注册到webApplicationContext中。接下继续跟踪registerBeanDefinition函数。

       跟踪registerBeanDefinition函数，此函数将bean信息保存到到webApplicationContext的beanDefinitionMap变量中，该变量为map类型，保存Spring容器中所有的bean定义。

       Spring实例化bean的时机有两个。

       一个是容器启动时候，另一个是真正调用的时候。

       相信用过Spring的同学们都知道以上概念，但是为什么呢？

       继续从源码角度进行分析，回到之前XmlWebApplication的refresh（）方法。

       可以看到获得beanFactory后调用了finishBeanFactoryInitialization()方法，继续跟踪此方法。

       预先实例化单例类逻辑。

       获取bean。

       doGetBean中处理的逻辑很多，为了减少干扰，下面只显示了创建bean的函数调用栈。

       创建bean。

       判断哪种动态代理方式实例化bean。

       不管哪种方式最终都是通过反射的形式完成了bean的实例化。

       我们继续回到doGetBean函数，分析获取bean的逻辑。

       上面方法中首先调用getSingleton(beanName)方法来获取单例bean，如果获取到则直接返回该bean。方法调用栈如下：

       getSingleton方法先从singletonObjects属性中获取bean对象,如果不为空则返回该对象，否则返回null。

       那singletonObjects保存的是什么？什么时候保存的呢？

       回到doGetBean（）函数继续分析。如果singletonObjects没有该bean的对象，进入到创建bean的逻辑。处理逻辑如下：

       下面是判断容器中有没有注册bean的逻辑，此处beanDefinitionMap相信大家都不陌生，在注册bean的流程里已经说过所有的bean信息都会保存到该变量中。

       如果该容器中已经注册过bean，nodejs 表格 源码继续往下走。先获取该bean的依赖bean，如果镩子依赖bean，则先递归获取相应的依赖bean。

       依赖bean创建完成后，接下来就是创建自身bean实例了。

       获取bean实例的处理逻辑有三种，即Singleton、Prototype、其它(request、session、globalsession)，下面一一说明。

       如果bean是单例模式，执行此逻辑。

       获取单例bean，如果已经有该bean的对象直接返回。如果没有则创建单例bean对象，并添加到容器的singletonObjectsMap中，以后直接从singletonObjects直接获取bean。

       把新生成的单例bean加入到类型为MAP的singletonObjects属性中，这也就是前面singletonObjects（）方法中获取单例bean时从此Map中获取的原因。

       Prototype是每次获取该bean时候都新建一个bean，因此逻辑比较简单，直接创建一个bean后返回。

       从相应scope获取对象实例。

       判断scope，获取实例函数逻辑。

       在相应scope中设置实例函数逻辑。

       以上就是Springbean从无到有的整个逻辑。

       从源码角度分析bean的实例化流程到此基本接近尾声了。

       回到开头的问题，ContextLoaderListener中初始化的WebApplicationContext到底是什么呢？

       通过源码的分析我们知道WebApplicationContext负责了bean的创建、保存、获取。其实也就是我们平时所说的IOC容器，只不过名字表述不同而已。

       本文主要是讲解了XML配置文件中bean的解析、注册、实例化。对于其它命名空间的解析还没有讲到，后续的文章中会一一介绍。

       希望通过本文让大家在以后使用Spring的过程中有“一切尽在掌控之中”的感觉，而不仅仅是稀里糊涂的使用。

SpringBean的初始化

       本文基于上一篇文章进行续写

       上一篇文章地址:SpringBean实例化及构造器选择

       1.BeanPostProcessor

       查看源码发现BeanPostProcessor提供了两个初始化前后的方法,新建一个接口并重写该接口的这两个方法

       1.新建一个InstantiationAwareBeanPostProcessorSpring方法并实现InstantiationAwareBeanPostProcessor接口

       InstantiationAwareBeanPostProcessor实现了BeanPostProcessor,所以此处使用InstantiationAwareBeanPostProcessorSpring也可以调用上述2个接口方法

       2.UserService类实现InitializingBean接口,并重写afterPropertiesSet方法

       3.利用客户端进行调用

       4.运行结果

spring的bean到底在什么时候实例化

       spring的bean在被依赖的时候实例化；

       分为以下几种Bean：

       1.如果指定的是convertrService,beanPostProcessor等实例的时候，则会在ApplicationContext初始化的时候就实例化；

       2.如果指定的是自定义的Bean，那么会在第一次访问的时候实例化；

       [被依赖的时候实例化,更明确的说是第一次访问]

springioc容器之Bean实例化和依赖注入 spring中的bean对象和java对象是有些许差别的，spring中的bean包含了java对象，并且是基于java对象在spring中做了一些列的加工，所以说spring中的bean比java对象更加丰富。在spring中bean的实例化有2个时机：

下面从springioc容器初始化的时候，预实例化的bean为线索来追溯bean的实例化和依赖注入过程，这个过程涵盖了getBean方法。

在springioc容器初始化的时候，触发了所有预实例化的bean的加载，这里必须是非抽象、单例和非懒加载的bean才符合条件进行预实例化。具体bean的实例化是在getBean方法中。

这里通过getSingleton先从缓存中获取bean实例。

从缓存中获取很好理解，分别从spring容器的一级缓存singletonObjects、二级缓存earlySingletonObjects和三级缓存singletonFactories中获取bean实例。在初次获取bean的时候，这里的缓存肯定为空的，但是对于存在循环依赖的bean，这里的一级或二级缓存就不是空的。在有循环依赖的bean中，这里一级缓存会存在不为空的情况，这个时候通过singletonFactory.getObject的时候，返回的可能是一个bean实例，也有可能是一个提前进行aop的代理对象(正常情况下aop是发生在bean初始化的时候完成的)，对于有循环依赖并且需要进行aop的bean，在这里会进行提前aop代理对象的生成。

当缓存中没有找到bean实例的时候：

通过singletonFactory.g

spring源码解析bean初始化与依赖注入四

       深入解析Spring源码的bean初始化与依赖注入部分，我们将继续从上一篇文章的

       org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean方法入手。

       随后，方法调用

       org.springframework.beans.factory.support.AbstractBeanFactory#registerDisposableBeanIfNecessary进行注册

       紧接着，调用

       org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean获取bean实例。

       在这一过程中，我们到达了

       org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#destroySingleton用于销毁单例bean。

       然后，再次深入

       org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#createBean方法进行bean的创建。

       紧接着，调用

       org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#resolveBeforeInstantiation对bean进行前置解析。

       之后，再次返回

       org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#createBean进行bean实例化。

       然后，调用

       org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean再次获取bean实例。

       紧接着，进入

       org.springframework.beans.factory.support.DefaultListableBeanFactory#preInstantiateSingletons进行单例bean的预实例化。

       最终，完成bean的初始化后触发回调。

       返回

       org.springframework.context.support.AbstractApplicationContext#refresh执行上下文刷新，完成bean初始化与依赖注入。

       至此，本次关于Spring源码中bean初始化与依赖注入的解析告一段落，以上内容仅供学习参考。

Spring 初始化

        基于spring 4.1.6

        第行 super(parent); 实例化父类，AbstractXmlApplicationContext、AbstractRefreshableConfigApplicationContext、AbstractRefreshableApplicationContext、AbstractApplicationContext

        第行 refresh();

        第4行

        prepareRefresh();

        // Tell the subclass to refresh the internal bean factory.

        ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

        第行

        finishRefresh();

        第7行 ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

        第2行 refreshBeanFactory(); 该方法两个子类均有实现

        AbstractRefreshableApplicationContext 和 GenericApplicationContext，前面 FileSystemXmlApplicationContext 有 AbstractRefreshableApplicationContext 实例化。

        第行

        DefaultListableBeanFactory beanFactory = createBeanFactory();

        第行

        XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);

        第行，loadBeanDefinitions(resources); 为什么是 XmlBeanDefinitionReader 这个类？

        因为，BeanDefinitionReader接口好多实现类，XmlBeanDefinitionReader只是其中一个子类，因为步骤4有定义啦。

        第5行，documentReader.registerBeanDefinitions(doc, createReaderContext(resource));

        第行，parseBeanDefinitions(root, this.delegate);

        第行，如果是spring的基础命名元素解析（import、bean、beans、alias）解析：

        parseDefaultElement(ele, delegate);

        拓展元素解析：delegate.parseCustomElement(ele); 拓展元素涉及到aop相关，后面的内容讨论。

        下面以解析bean为例

        以上完成读取、解析、注册，然后到 2、AbstractApplicationContext 的 finishBeanFactoryInitialization(beanFactory);

        补充然后，

        实例化 DefaultListableBeanFactory 的时候，调用 preInstantiateSingletons 完成bean实例化，不是抽象的bean，是单例的bean，非懒加载。

        refresh() 方法中调用 finishBeanFactoryInitialization(beanFactory);

        第行，getBean方法，到还是，应该是到、DefaultListableBeanFactory，因为前面有实例化该类。

        第行，Object singletonInstance = getSingleton(beanName); 获取单例对象，应该是到步，步没用吗？可能是内部用吧。

        getBean 遍历

        public Object getBean(String name) throws BeansException {

        return doGetBean(name, null, null, false);

        }

        getBean --> doGetBean --> createBean --> doCreateBean --> createBeanInstance -- > instanceBean

        第行，return createBean(beanName, mbd, args);

        第行，Object beanInstance = doCreateBean(beanName, mbd, args); 执行完，用BeanWrapper包装。

        第行，instanceWrapper = createBeanInstance(beanName, mbd, args);

        最后一行，instantiateBean(beanName, mbd)

        第行，beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);执行完，用 BeanWrapper包装。

        第9行，return getInstantiationStrategy().instantiate(mbd, beanName, parent);

        第行，return BeanUtils.instantiateClass(constructorToUse);

        protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)

        设置 mbd.postProcessed = true;

        如果缓存中没有单例的bean，则需要从头开始创建单例bean，这里主要是重载 getSingleton()方法实现单例bean的加载。

        包含前后处理方法，beforeSingletonCreation(beanName); 和 afterSingletonCreation(beanName);

Spring IoC：getBean 详解

       接着 Spring IoC：finishBeanFactoryInitialization 详解，我们正式开始学习获取 bean 实例方法，该方法是 Spring 最核心的方法。

       单击 preInstantiateSingletons 方法里的 getBean(beanName) 代码，进入该方法。

       见 doGetBean 方法详解。

       doGetBean

       1.解析 beanName，主要是解析别名、去掉 FactoryBean 的修饰符 “&”，在 Spring IoC：finishBeanFactoryInitialization 详解 中的代码块4已解析过。

       2.尝试从缓存中获取 beanName 对应的实例，在 Spring IoC：finishBeanFactoryInitialization 详解 中的代码块7已解析过。

       3.1 返回 beanName 对应的实例对象（主要用于 FactoryBean 的特殊处理，普通 bean 会直接返回 sharedInstance 本身），见代码块1详解。

       6.如果不是仅仅做类型检测，而是创建 bean 实例，这里要将 beanName 放到 alreadyCreated 缓存，见代码块5详解。

       7.根据 beanName 重新获取 MergedBeanDefinition，在 Spring IoC：finishBeanFactoryInitialization 详解 中的代码块2已解析过。

       8.2 检查 dep 是否依赖于 beanName，即检查是否存在循环依赖，见代码块6详解。

       8.4 将 dep 和 beanName 的依赖关系注册到缓存中，见代码块7详解。

       9.1 scope 为 singleton 的 bean 创建（新建了一个 ObjectFactory，并且重写了 getObject 方法），见代码块8详解。

       9.1.1、9.2.2、9.3.4 创建 bean 实例，限于篇幅，在下篇文章单独解析。

       9.1.2、9.2.4、9.3.6 返回 beanName 对应的实例对象，见代码块1详解。

       9.2.1 scope 为 prototype 时创建实例前的操作、9.2.3 scope 为 prototype 时 创建实例后的操作，相对应的两个方法，见代码块详解。

       代码块1：getObjectForBeanInstance

       如果对 FactoryBean 不熟悉的，可以回头去看 Spring IoC：finishBeanFactoryInitialization 详解 中对 FactoryBean 的简单介绍。

       6.mbd 为空，但是该 bean 的 BeanDefinition 在缓存中存在，则获取该 bean 的 MergedBeanDefinition，在 Spring IoC：finishBeanFactoryInitialization 详解 中的代码块2已经解析过。

       8.从 FactoryBean 获取对象实例，见代码块2详解。

       代码块2：getObjectFromFactoryBean

       3.调用 FactoryBean 的 getObject 方法获取对象实例，见代码块3详解。

       5.对 bean 实例进行后续处理，执行所有已注册的 BeanPostProcessor 的 postProcessAfterInitialization 方法，见代码块4详解。

       代码块3：doGetObjectFromFactoryBean

       很简单的方法，就是直接调用 FactoryBean 的 getObject 方法来获取到对象实例。

       细心的同学可以发现，该方法是以 do 开头，看过 Spring IoC：源码总览 的同学知道，我在总览里就特别提到以 do 开头的方法是最终进行实际操作的方法，例如本方法就是 FactoryBean 最终实际进行创建 bean 对象实例的方法。

       代码块4：postProcessObjectFromFactoryBean

       这边走的是 AbstractAutowireCapableBeanFactory 里的方法。通过前面的介绍，我们知道创建的 BeanFactory 为 DefaultListableBeanFactory，而 DefaultListableBeanFactory 继承了 AbstractAutowireCapableBeanFactory，因此这边会走 AbstractAutowireCapableBeanFactory 的重写方法。

       在 Spring IoC：registerBeanPostProcessors 详解 中已经学过 BeanPostProcessor，在创建完 bean 实例后，会执行 BeanPostProcessor 的 postProcessAfterInitialization 方法。

       代码块5：markBeanAsCreated

       2.这边会将 beanName 对应的 MergedBeanDefinition 移除，然后在之后的代码重新获取，主要是为了使用最新的 MergedBeanDefinition 来进行创建操作。

       代码块6：isDependent

       这边引入了一个缓存 dependentBeanMap：beanName -> 所有依赖 beanName 对应的 bean 的 beanName 集合。内容比较简单，就是检查依赖 beanName 的集合中是否包含 dependentBeanName，隔层依赖也算。例如：A 依赖了 B，B 依赖了 C，则 A 也算依赖了 C。

       代码块7：registerDependentBean

       这边又引入了一个跟 dependentBeanMap 类似的缓存，dependenciesForBeanMap：beanName -> beanName 对应的 bean 依赖的所有 bean 的 beanName 集合。

       这两个缓存很容易搞混，举个简单例子：例如 B 依赖了 A，则 dependentBeanMap 缓存中应该存放一对映射：其中 key 为 A，value 为含有 B 的 Set；而 dependenciesForBeanMap 缓存中也应该存放一对映射：其中 key 为：B，value 为含有 A 的 Set。

       代码块8：getSingleton

       5.创建单例前的操作，7.创建单例后的操作，这两个方法是对应的，见代码块9详解。

       6.执行 singletonFactory 的 getObject 方法获取 bean 实例，该方法会走文章开头 doGetBean 方法的注释 9.1.1。

       8.如果是新的单例对象，将 beanName 和对应的单例对象添加到缓存中，见代码块详解。

       代码块9：beforeSingletonCreation、afterSingletonCreation

       inCreationCheckExclusions 是要在创建检查排除掉的 beanName 集合，正常为空，可以不管。这边主要是引入了 singletonsCurrentlyInCreation 缓存：当前正在创建的 bean 的 beanName 集合。在 beforeSingletonCreation 方法中，通过添加 beanName 到该缓存，可以预防出现构造器循环依赖的情况。

       为什么无法解决构造器循环依赖？

       我们之前在 Spring IoC：finishBeanFactoryInitialization 详解 中的代码块7提过，getSingleton 方法是解决循环引用的核心代码。解决逻辑的第一句话：“我们先用构造函数创建一个 “不完整” 的 bean 实例”，从这句话可以看出，构造器循环依赖是无法解决的，因为当构造器出现循环依赖，我们连 “不完整” 的 bean 实例都构建不出来。Spring 能解决的循环依赖有：通过 setter 注入的循环依赖、通过属性注入的循环依赖。

       代码块：addSingleton

       代码块：beforePrototypeCreation、afterPrototypeCreation

       该方法和代码块9的两个方法类似。主要是在进行 bean 实例的创建前，将 beanName 添加到 prototypesCurrentlyInCreation 缓存；bean 实例创建后，将 beanName 从 prototypesCurrentlyInCreation 缓存中移除。这边 prototypesCurrentlyInCreation 存放的类型为 Object，在只有一个 beanName 的时候，直接存该 beanName，也就是 String 类型；当有多个 beanName 时，转成 Set 来存放。

       总结

       本文介绍了获取 bean 实例的大部分内容，包括先从缓存中检查、 FactoryBean 的 bean 创建、实例化自己的依赖（depend-on 属性）、创建 bean 实例的前后一些标记等，在下篇文章中，将解析创建 bean 的内容。

       推荐阅读

Spring源码--Bean工厂之getBean方法

       Bean实例化与管理是Spring框架的核心功能之一，其中getBean方法作为获取Bean实例的主要手段，具有重要意义。接下来，我们将深入探讨getBean方法及其相关实现，以期更好地理解Spring Bean工厂的工作机制。

       一、getBean方法

       getBean方法是Spring容器对外提供的一种接口，用于根据指定的Bean名称获取对应Bean实例。该方法会根据配置信息和缓存机制，找到并返回所需的Bean。

       二、doGetBean方法

       doGetBean方法是getBean方法的内部实现，负责处理Bean的查找、创建和返回工作。其流程分为以下几个关键步骤：

       1. getSingleton

       若Bean是单例且已存在，则直接返回缓存的实例，无需重新创建。

       2. createBean

       若非单例或未找到缓存实例，将进入创建Bean的流程。此过程涉及实例化、属性填充和初始化三个主要步骤。

       2.1 实例化

       通过调用对应的构造函数或使用默认构造函数创建Bean实例。

       2.2 三级缓存

       在实例化后，新创建的Bean会首先存储于缓存中，随后被添加到Bean作用域的缓存中，以备后续使用。

       2.3 属性填充

       通过依赖注入或属性设置方法填充Bean的属性值，确保其具有所需的功能。

       2.4 初始化

       执行Bean的初始化方法，实现任何特定的初始化逻辑，如配置文件加载或数据库连接等。

       三、流程图

       为了更直观地展示getBean方法的执行流程，以下流程图详细展示了从查找至返回Bean实例的全过程，包括缓存操作、实例化、属性填充和初始化等关键步骤。

       四、循环依赖示意图

       在处理循环依赖时，Spring容器会采取特定策略以避免无限循环。以下示意图展示了两个单例Bean（A和B）之间循环依赖的处理过程，以及Spring如何通过延迟初始化等机制解决这一问题。

       本文通过深入剖析getBean方法及其相关实现，旨在帮助开发者更好地理解Spring Bean工厂的工作机制。通过掌握这些关键概念与流程，可以更高效地利用Spring框架构建可维护且高性能的应用程序。