前言
上一篇bean加载的文章分析了bean加载核心入口AbstractBeanFactory#doGetBean(String, Class, Object[], boolean)的上半部分，该部分主要逻辑在显式调用getBean时会被执行，更具体的来说是获得单例对象和通过自定义FactoryBean创建对象时会执行上半部分；而下半部分会在初始化和获得prototype多例对象时被执行，本文就是对这下半部分做深入分析

为了分析方便，我们再截取一次下半部分内容的代码，代码清单1

        //    (1)
    if (isPrototypeCurrentlyInCreation(beanName)) {
        throw new BeanCurrentlyInCreationException(beanName);
    }

    //    (2)
    BeanFactory parentBeanFactory = getParentBeanFactory();
    if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
        // Not found -> check parent.
        String nameToLookup = originalBeanName(name);
        if (args != null) {
            // Delegation to parent with explicit args.
            return (T) parentBeanFactory.getBean(nameToLookup, args);
        }
        else {
            // No args -> delegate to standard getBean method.
            return parentBeanFactory.getBean(nameToLookup, requiredType);
        }
    }
        //    (3)
    if (!typeCheckOnly) {
        markBeanAsCreated(beanName);
    }

    try {
                //    (4)
        final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
        checkMergedBeanDefinition(mbd, beanName, args);

        //    (5)
        String[] dependsOn = mbd.getDependsOn();
        if (dependsOn != null) {
            for (String dependsOnBean : dependsOn) {
                getBean(dependsOnBean);
                registerDependentBean(dependsOnBean, beanName);
            }
        }
                //    (6)
        // Create bean instance.
        if (mbd.isSingleton()) {
            sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
                public Object getObject() throws BeansException {
                    try {
                        return createBean(beanName, mbd, args);
                    }
                    catch (BeansException ex) {
                        // Explicitly remove instance from singleton cache: It might have been put there
                        // eagerly by the creation process, to allow for circular reference resolution.
                        // Also remove any beans that received a temporary reference to the bean.
                        destroySingleton(beanName);
                        throw ex;
                    }
                }
            });
            bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
        }
                //    (7)
        else if (mbd.isPrototype()) {
            // It's a prototype -> create a new instance.
            Object prototypeInstance = null;
            try {
                beforePrototypeCreation(beanName);
                prototypeInstance = createBean(beanName, mbd, args);
            }
            finally {
                afterPrototypeCreation(beanName);
            }
            bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
        }
                //    (8)
        else {
            String scopeName = mbd.getScope();
            final Scope scope = this.scopes.get(scopeName);
            if (scope == null) {
                throw new IllegalStateException("No Scope registered for scope '" + scopeName + "'");
            }
            try {
                Object scopedInstance = scope.get(beanName, new ObjectFactory<Object>() {
                    public Object getObject() throws BeansException {
                        beforePrototypeCreation(beanName);
                        try {
                            return createBean(beanName, mbd, args);
                        }
                        finally {
                            afterPrototypeCreation(beanName);
                        }
                    }
                });
                bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
            }
            catch (IllegalStateException ex) {
                throw new BeanCreationException(beanName,
                        "Scope '" + scopeName + "' is not active for the current thread; " +
                        "consider defining a scoped proxy for this bean if you intend to refer to it from a singleton",
                        ex);
            }
        }
    }
    catch (BeansException ex) {
        cleanupAfterBeanCreationFailure(beanName);
        throw ex;
    }

我们都知道对于scope = "prototype"的对象来说，Spring是不会在真正使用该对象前创建它的，这一特性意味着Spring不能解决prototype类型变量的循环依赖问题，道理很简单，当我们真正使用prototype对象时肯定要求内部的依赖关系都建立完毕，而循环依赖的存在使这种对象间关系无法建立，必定就会抛出BeanCurrentlyInCreationException
上一篇文中说过，Spring使用“三级缓存”的形式能部分解决循环依赖问题，我们在这里就可以总结下“部分”指哪些情况：Spring能够解决singleton下使用setter方式形成的循环依赖问题，不能够解决singleton下使用构造器形成的循环依赖，以及prototype下的循环依赖。第一种能解决的原因是Spring解析之IoC：bean的加载（一）中分析过的缓存earlySingletonObjects，当我们设置允许早期对象引用暴露allowEarlyReference后，Spring会将通过构造器创建出来的，尚未调用setter建立依赖关系的单例对象放入earlySingletonObjects中，当我们需要一组存在循环依赖的对象时直接从里面取出每个对象手动建立依赖关系即可。但是如果是构造器形成的循环依赖，连创建早期对象都不可能，自然就没法解决循环依赖问题了
重温了Spring解决循环依赖的手段后看标注1，如果获取的是prototype类型的对象且该对象正在创建中，必然就发生了循环依赖，直接抛出异常。标注2是存在父子容器时加载bean的代码逻辑，如果大家用过SpringMVC相信对父子容器都不陌生，大多数情况下Web层的SpringMVC都作为Service层和Dao层Spring容器的子容器存在，子容器可以访问父容器中的bean，反过来则不行，当子容器加载bean时首先判断自身容器中是否存在同名的bean，存在直接获得，不存在就去父容器中查找该名称的bean
标注2的逻辑就是这样，判断如果存在父容器，且当前容器中不存在beanName对应的bean就调用父容器parentBeanFactory的getBean(String, Object...)，又来了一个大循环。标注3中typeCheckOnly表示获得bean的目的是否是为了类型检查，而不是真正使用这个bean，绝大部分情况我们当时是要用bean啦，这时就要调用markBeanAsCreated(String)将创建bean的行为做记录，记录实际上就是将beanName打上已经创建的标识放入Map<String, Boolean> alreadyCreated中
标注4在Spring解析之IoC：bean的加载（一）中已经说过，如果<bean>存在父子关系(注意不是容器的父子关系)，getMergedLocalBeanDefinition(String)会将父子关系的<bean>信息融合在RootBeanDefinition中

图1. 检查融合后的BeanDefinition

checkMergedBeanDefinition(RootBeanDefinition, String, Object[])排除了两种情况下bean的创建：1. <bean>存在abstract属性；2. scope = singleton且参数args有值的情况。第一种情况很好理解，都抽象了还创建毛线啊，而要想通第二种情况我们需要追根溯源看看args来自哪里。显式调用getBean获得对象有一个重载方法Object getBean(String, Object...)，这里的args就是第二个参数，该重载方法提供的目的是解决一个场景：初始化只存在有参构造的类，且参数要在获取时动态指定。创建只存在有参构造器的类很容易，直接<constrcut-arg>指定就好，但是要每次创建的参数值不同再用该方法很明显就挂了啊，还是Object getBean(String, Object...)好使。这也很好的解释了为什么args不能和singleton共存，因为args说明可变性，singleton说明唯一性，相互冲突
标注5涉及到一个之前没有讲过的<bean>属性depends-on，该属性的作用是让depends-on内的对象先于<bean>所代表的对象创建，但这两组对象并不要求有真正的依赖关系，我们举个例子，创建三个类Man、Woman和Family，Family配置depends-on前两个类

图2. Man

图3. Woman

图4. Family

图5. Man、Woman和Family相关配置

图6. depends-on例子运行结果

图7. 处理singleton对象逻辑

图8. DefaultSingletonBeanRegistry的getSingleton(String, ObjectFactory<?>)

图9. DefaultSingletonBeanRegistry的beforeSingletonCreation(String)

图10. DefaultSingletonBeanRegistry的addSingleton(String, Object)

图11. 处理prototype对象逻辑

图12. AbstractBeanFactory的beforePrototypeCreation(String)

图13. 处理其他scope对象逻辑

后记
本文将getBean中最后零碎的逻辑清理干净就是为了将核心创建bean作为一个整体分析，即便如此由于Spring涉及的内容太多，createBean依然比较庞大和杂乱，不管怎么说我们已经吹响了最后的冲锋号，年前必定攻下获得bean这座山头，加油！