Spring Ioc源码分析系列--Bean实例化过程(二)
前言
上篇文章Spring Ioc源码分析系列--Bean实例化过程(一)简单分析了getBean()方法，还记得分析了什么吗？不记得了才是正常的，记住了才是怪人，忘记了可以回去翻翻，翻不翻都没事， 反正最后都会忘了。
这篇文章是给上篇填坑的，上篇分析到真正创建Bean的createBean(beanName, mbd, args)就没有继续深入去分析了，绕得太深，说不清楚。那么这一篇，就续上这个口子，去分析createBean(beanName, mbd, args)方法。
源码分析
话不多说，我们直接来到createBean(beanName, mbd, args)方法的源码。具体的实现是在AbstractAutowireCapableBeanFactory#createBean(beanName, mbd, args)里，可以直接定位到这里。
createBean()方法
跟进代码查看，这个方法也比较简单，主要分为了以下几点：
- 初始化化
Class对象。调用resolveBeanClass(mbd, beanName)方法获取class对象，这里会去解析类全限定名，最终是通过反射方法Class<?> resolvedClass = ClassUtils.forName(className, classLoader)获取Class对象。 - 检查覆盖方法。对应的是
mbdToUse.prepareMethodOverrides()方法，这里会对一些重载方法进行标记预处理，如果同方法名的方法只存在一个，那么会将覆盖标记为未重载，以避免 arg 类型检查的开销。 - 应用后置处理器。在实例化对象前，会经过后置处理器处理，这个后置处理器的提供了一个短路机制，就是可以提前结束整个Bean的生命周期，直接从这里返回一个Bean。
- 创建Bean。调用
doCreateBean()方法进行Bean的创建，在Spring里面，带有do开头的一般是真正干活的方法，所以Ioc创建Bean到这里，才是真正要到干活的地方了。
我们庖丁解牛先把方法不同的功能按照逻辑拆分了，那接下来，就详细分析一下每个部分。
/** * Central method of this class: creates a bean instance, * populates the bean instance, applies post-processors, etc. * * 此类的中心方法：创建 bean 实例、填充 bean 实例、应用后处理器等。 * * @see #doCreateBean */ @Override protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) throws BeanCreationException { if (logger.isTraceEnabled()) { logger.trace("Creating instance of bean '" + beanName + "'"); } RootBeanDefinition mbdToUse = mbd; // Make sure bean class is actually resolved at this point, and // clone the bean definition in case of a dynamically resolved Class // which cannot be stored in the shared merged bean definition. //锁定class ，根据设置的 class 属性或者根据 className 来解析 Class // 解析得到beanClass，为什么需要解析呢？如果是从XML中解析出来的标签属性肯定是个字符串嘛 // 所以这里需要加载类，得到Class对象 Class<?> resolvedClass = resolveBeanClass(mbd, beanName); if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) { mbdToUse = new RootBeanDefinition(mbd); mbdToUse.setBeanClass(resolvedClass); } // Prepare method overrides.验证及准备覆盖的方法 // 对XML标签中定义的lookUp属性进行预处理， // 如果只能根据名字找到一个就标记为非重载的，这样在后续就不需要去推断到底是哪个方法了， // 对于@LookUp注解标注的方法是不需要在这里处理的， // AutowiredAnnotationBeanPostProcessor会处理这个注解 try { mbdToUse.prepareMethodOverrides(); } catch (BeanDefinitionValidationException ex) { throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(), beanName, "Validation of method overrides failed", ex); } try { // Give BeanPostProcessors a chance to return a proxy instead of the target bean instance. //给BeanPostProcessors一个露脸的机会 // 在实例化对象前，会经过后置处理器处理 // 这个后置处理器的提供了一个短路机制，就是可以提前结束整个Bean的生命周期，直接从这里返回一个Bean // 不过我们一般不会这么做，它的另外一个作用就是对AOP提供了支持， // 在这里会将一些不需要被代理的Bean进行标记，就本IoC系列文章而言，你可以暂时理解它没有起到任何作用 Object bean = resolveBeforeInstantiation(beanName, mbdToUse); //若果有自定义bean则直接返回了bean，不会再走后续的doCreateBean方法 if (bean != null) { return bean; } } catch (Throwable ex) { throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName, "BeanPostProcessor before instantiation of bean failed", ex); } try { // 不存在提前初始化的操作，开始正常的创建流程 // doXXX方法，真正干活的方法，doCreateBean，真正创建Bean的方法 Object beanInstance = doCreateBean(beanName, mbdToUse, args); if (logger.isTraceEnabled()) { logger.trace("Finished creating instance of bean '" + beanName + "'"); } return beanInstance; } catch (BeanCreationException | ImplicitlyAppearedSingletonException ex) { // 省略部分异常.. } } } 初始化Class对象
很显然初始化Class对象的代码在resolveBeanClass(mbd, beanName)方法里，跟进代码查看。
/** * Resolve the bean class for the specified bean definition, * resolving a bean class name into a Class reference (if necessary) * and storing the resolved Class in the bean definition for further use. * * 为指定的 bean 定义解析 bean 类，将 bean 类名称解析为 Class 引用（如果需要）并将解析的 Class 存储在 bean 定义中以供进一步使用。 * * @param mbd the merged bean definition to determine the class for * @param beanName the name of the bean (for error handling purposes) * @param typesToMatch the types to match in case of internal type matching purposes * (also signals that the returned {@code Class} will never be exposed to application code) * 在内部类型匹配的情况下要匹配的类型（也表示返回的 {@code Class} 永远不会暴露给应用程序代码） * @return the resolved bean class (or {@code null} if none) * @throws CannotLoadBeanClassException if we failed to load the class */ @Nullable protected Class<?> resolveBeanClass(final RootBeanDefinition mbd, String beanName, final Class<?>... typesToMatch) throws CannotLoadBeanClassException { try { // 如果已经创建过，直接返回 if (mbd.hasBeanClass()) { return mbd.getBeanClass(); } if (System.getSecurityManager() != null) { return AccessController.doPrivileged((PrivilegedExceptionAction<Class<?>>) () -> doResolveBeanClass(mbd, typesToMatch), getAccessControlContext()); } else { // 否则进行创建 return doResolveBeanClass(mbd, typesToMatch); } } catch (PrivilegedActionException pae) { // 省略部分异常处理 } } 跟进doResolveBeanClass(mbd, typesToMatch)方法，我们这里传入的typesToMatch参数对象数组为空，所以不会走排除部分类的逻辑，接下来是使用evaluateBeanDefinitionString()方法计算表达式如果传入的className有占位符，会在这里被解析，最终正常我们会走到mbd.resolveBeanClass(beanClassLoader)方法里。
private Class<?> doResolveBeanClass(RootBeanDefinition mbd, Class<?>... typesToMatch) throws ClassNotFoundException { // 获取类加载器 ClassLoader beanClassLoader = getBeanClassLoader(); ClassLoader dynamicLoader = beanClassLoader; boolean freshResolve = false; if (!ObjectUtils.isEmpty(typesToMatch)) { // When just doing type checks (i.e. not creating an actual instance yet), // use the specified temporary class loader (e.g. in a weaving scenario). // 当只是进行类型检查（即尚未创建实际实例）时，请使用指定的临时类加载器（例如在编织场景中）。 ClassLoader tempClassLoader = getTempClassLoader(); if (tempClassLoader != null) { dynamicLoader = tempClassLoader; freshResolve = true; if (tempClassLoader instanceof DecoratingClassLoader) { DecoratingClassLoader dcl = (DecoratingClassLoader) tempClassLoader; for (Class<?> typeToMatch : typesToMatch) { dcl.excludeClass(typeToMatch.getName()); } } } } String className = mbd.getBeanClassName(); if (className != null) { Object evaluated = evaluateBeanDefinitionString(className, mbd); if (!className.equals(evaluated)) { // A dynamically resolved expression, supported as of 4.2... if (evaluated instanceof Class) { return (Class<?>) evaluated; } else if (evaluated instanceof String) { className = (String) evaluated; freshResolve = true; } else { throw new IllegalStateException("Invalid class name expression result: " + evaluated); } } if (freshResolve) { // When resolving against a temporary class loader, exit early in order // to avoid storing the resolved Class in the bean definition. // 当针对临时类加载器解析时，请提前退出以避免将解析的类存储在 bean 定义中。 if (dynamicLoader != null) { try { // 使用临时动态加载器加载 class 对象 return dynamicLoader.loadClass(className); } catch (ClassNotFoundException ex) { if (logger.isTraceEnabled()) { logger.trace("Could not load class [" + className + "] from " + dynamicLoader + ": " + ex); } } } // 反射加载 class 对象 return ClassUtils.forName(className, dynamicLoader); } } // Resolve regularly, caching the result in the BeanDefinition... // 正常解析，将结果缓存在 BeanDefinition... return mbd.resolveBeanClass(beanClassLoader); } 跟进mbd.resolveBeanClass(beanClassLoader)方法，可以看到这里就是使用反射初始化Class对象，然后缓存在BeanDefinition中。到这里，已经完成了从一个字符串的类名到一个Class对象的转换了，我们已经得到了一个可以使用的Class对象。
/** * Determine the class of the wrapped bean, resolving it from a * specified class name if necessary. Will also reload a specified * Class from its name when called with the bean class already resolved. * * 确定被包装的 bean 的类，必要时从指定的类名解析它。当使用已解析的 bean 类调用时，还将从其名称中重新加载指定的类。 * * @param classLoader the ClassLoader to use for resolving a (potential) class name * @return the resolved bean class * @throws ClassNotFoundException if the class name could be resolved */ @Nullable public Class<?> resolveBeanClass(@Nullable ClassLoader classLoader) throws ClassNotFoundException { String className = getBeanClassName(); if (className == null) { return null; } Class<?> resolvedClass = ClassUtils.forName(className, classLoader); this.beanClass = resolvedClass; return resolvedClass; } 检查覆盖方法
初始化class对象已经完成了，接下来会去处理重载方法，处理的逻辑在mbdToUse.prepareMethodOverrides()方法里。
摘取《Spring源码深度解析》里面的一段话：
很多读者可能会不知道这个方法的作用，因为在 Spring 的配置里面根本就没有诸如
override-method之类的配置， 那么这个方法到底是干什么用的呢？ 其实在 Spring 中确实没有override-method这样的配置，但是在 Spring 配置中是存在lookup-method和replace-method的，而这两个配置的加载其实就是将配置统一存放在BeanDefinition中的methodOverrides属性里，而这个函数的操作其实也就是针对于这两个配置的。
lookup-method通常称为获取器注入，spring in action 中对它的描述是，一种特殊的方法注入，它是把一个方法声明为返回某种类型的 bean，而实际要返回的 bean 是在配置文件里面配置的，可用在设计可插拔的功能上，解除程序依赖。 这里会对一些重载方法进行标记预处理，如果同方法名的方法只存在一个，那么会将覆盖标记为未重载，以避免 arg 类型检查的开销。
这种骚操作我们基本是不会使用的，所以简单看一下代码，浅尝辄止，有兴趣可以去翻翻。
/** * Validate and prepare the method overrides defined for this bean. * Checks for existence of a method with the specified name. * * 验证并准备为此 bean 定义的方法覆盖。检查具有指定名称的方法是否存在。 * * @throws BeanDefinitionValidationException in case of validation failure */ public void prepareMethodOverrides() throws BeanDefinitionValidationException { // Check that lookup methods exist and determine their overloaded status. // 检查查找方法是否存在并确定它们的重载状态。 if (hasMethodOverrides()) { getMethodOverrides().getOverrides().forEach(this::prepareMethodOverride); } } 可以看到这里就获取所有methodOverrides，然后遍历去调用prepareMethodOverride()方法，跟进prepareMethodOverride()方法。可以看到这里就是做个简单的标记。
/** * Validate and prepare the given method override. * Checks for existence of a method with the specified name, * marking it as not overloaded if none found. * * 验证并准备给定的方法覆盖。检查具有指定名称的方法是否存在，如果没有找到，则将其标记为未重载。 * * @param mo the MethodOverride object to validate * @throws BeanDefinitionValidationException in case of validation failure */ protected void prepareMethodOverride(MethodOverride mo) throws BeanDefinitionValidationException { int count = ClassUtils.getMethodCountForName(getBeanClass(), mo.getMethodName()); if (count == 0) { throw new BeanDefinitionValidationException( "Invalid method override: no method with name '" + mo.getMethodName() + "' on class [" + getBeanClassName() + "]"); } else if (count == 1) { // Mark override as not overloaded, to avoid the overhead of arg type checking. // 将覆盖标记为未重载，以避免 arg 类型检查的开销。 mo.setOverloaded(false); } } 应用后置处理器
在实例化对象前，会经过后置处理器处理，这个后置处理器的提供了一个短路机制，就是可以提前结束整个Bean的生命周期，直接从这里返回一个Bean。不过我们一般不会这么做，它的另外一个作用就是对AOP提供了支持，在这里会将一些不需要被代理的Bean进行标记，就本IoC系列文章而言，你可以暂时理解它没有起到任何作用。
跟进代码resolveBeforeInstantiation(beanName, mbdToUse)查看。
/** * Apply before-instantiation post-processors, resolving whether there is a * before-instantiation shortcut for the specified bean. * * 应用实例化前后处理器，解析指定 bean 是否存在实例化前快捷方式。 * 实例化前的快捷方式的意思这里可能会直接返回一个定义的代理，而不需要在把目标类初始化 * * @param beanName the name of the bean * @param mbd the bean definition for the bean * @return the shortcut-determined bean instance, or {@code null} if none */ //注意单词Instantiation和Initialization区别 @Nullable protected Object resolveBeforeInstantiation(String beanName, RootBeanDefinition mbd) { Object bean = null; if (!Boolean.FALSE.equals(mbd.beforeInstantiationResolved)) { // Make sure bean class is actually resolved at this point. if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { // 确定给定的 bean 的类型 Class<?> targetType = determineTargetType(beanName, mbd); if (targetType != null) { // 提供一个提前初始化的时机，这里会直接返回一个实例对象 bean = applyBeanPostProcessorsBeforeInstantiation(targetType, beanName); if (bean != null) { // 如果提前初始化成功，则执行 postProcessAfterInitialization() 方法，注意单词Instantiation和Initialization区别 // 关于这一块的逻辑，细心的一点的会发现，这里漏了实例化后置处理、初始化前置处理这两个方法。 // 而是在提前返回对象后，直接执行了初始化后置处理器就完成了bean的整个流程， // 相当于是提供了一个短路的操作，不再经过Spring提供的繁杂的各种处理 bean = applyBeanPostProcessorsAfterInitialization(bean, beanName); } } } // 设置是否已经提前实例化 mbd.beforeInstantiationResolved = (bean != null); } return bean; } 跟进applyBeanPostProcessorsBeforeInstantiation()代码查看。这里只要有一个 InstantiationAwareBeanPostProcessor 返回的结果不为空，则直接返回，说明多个 InstantiationAwareBeanPostProcessor 只会生效靠前的一个，注意单词Instantiation和Initialization区别。
/** * spring bean 初始化流程 * Bean 初始化（Initialization） * 1.@PoseConstruct 方法 * 2.实现InitializingBean 接口的afterPropertiesSet()方法 * 3.自定义初始化方法 */ @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); // 如果为空，表示不作任何调整 // 这里只要有一个 InstantiationAwareBeanPostProcessor 返回的结果不为空，则直接返回， // 说明多个 InstantiationAwareBeanPostProcessor 只会生效靠前的一个 if (result != null) { return result; } } } return null; } 跟进applyBeanPostProcessorsAfterInitialization()方法，逻辑跟上面的是类似的，注意单词Instantiation和Initialization区别。
@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; } 创建Bean
经过上面的步骤，有惊无险，我们来到了doCreateBean(beanName, mbdToUse, args)方法，这是真正进行Bean创建的地方，所以这里才是真的进入正文，前面都是打酱油走走过程。
当经历过 resolveBeforelnstantiation() 方法后，程序有两个选择 ，如果创建了代理或者说重写了 InstantiationAwareBeanPostProcessor 的 postProcessBeforelnstantiation() 方法并在方法 postProcessBeforelnstantiation() 中改变了 bean， 则直接返回就可以了 ， 否则需要进行常规 bean 的创建。 而这常规 bean 的创建就是在 doCreateBean() 中完成的。
直接跟进doCreateBean()代码查看，代码很长，你忍一下。
/** * Actually create the specified bean. Pre-creation processing has already happened * at this point, e.g. checking {@code postProcessBeforeInstantiation} callbacks. * <p>Differentiates between default bean instantiation, use of a * factory method, and autowiring a constructor. * * 实际创建指定的bean。 * 此时已经进行了预创建处理，例如检查 {@code postProcessBeforeInstantiation} 回调。 * <p>区分默认 bean 实例化、使用工厂方法和自动装配构造函数。 * * @param beanName the name of the bean * @param mbd the merged bean definition for the bean * @param args explicit arguments to use for constructor or factory method invocation * @return a new instance of the bean * @throws BeanCreationException if the bean could not be created * @see #instantiateBean * @see #instantiateUsingFactoryMethod * @see #autowireConstructor */ protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args) throws BeanCreationException { // 这个方法真正创建了Bean,创建一个Bean会经过 创建对象 > 依赖注入 > 初始化 // 这三个过程，在这个过程中，BeanPostProcessor会穿插执行， // Instantiate the bean. BeanWrapper instanceWrapper = null; if (mbd.isSingleton()) { instanceWrapper = this.factoryBeanInstanceCache.remove(beanName); } if (instanceWrapper == null) { //根据指定bean使用对应的策略创建新的实例，如工厂方法，构造函数自动注入，简单初始化 // 这里真正的创建了对象 instanceWrapper = createBeanInstance(beanName, mbd, args); } final Object bean = instanceWrapper.getWrappedInstance(); Class<?> beanType = instanceWrapper.getWrappedClass(); if (beanType != NullBean.class) { mbd.resolvedTargetType = beanType; } // Allow post-processors to modify the merged bean definition. // 按照官方的注释来说，这个地方是Spring提供的一个扩展点， // 对程序员而言，我们可以通过一个实现了MergedBeanDefinitionPostProcessor的后置处理器 // 来修改bd中的属性，从而影响到后续的Bean的生命周期 // 不过官方自己实现的后置处理器并没有去修改bd， // 而是调用了applyMergedBeanDefinitionPostProcessors方法 // 这个方法名直译过来就是-应用合并后的bd,也就是说它这里只是对bd做了进一步的使用而没有真正的修改 synchronized (mbd.postProcessingLock) { // bd只允许被处理一次 if (!mbd.postProcessed) { try { // 应用合并后的bd applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName); } catch (Throwable ex) { throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Post-processing of merged bean definition failed", ex); } // 标注这个bd已经被MergedBeanDefinitionPostProcessor的后置处理器处理过 // 那么在第二次创建Bean的时候，不会再次调用applyMergedBeanDefinitionPostProcessors mbd.postProcessed = true; } } // Eagerly cache singletons to be able to resolve circular references // even when triggered by lifecycle interfaces like BeanFactoryAware. //是否需要提前暴露mbd.isSingleton() && this.allowCircularReferences && // isSingletonCurrentlyInCreation(beanName) boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName)); if (earlySingletonExposure) { if (logger.isTraceEnabled()) { logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references"); } //为避免后期循环依赖，可以在bean初始化完成前将创建实例的ObjectFactory加入工厂 //getEarlyBeanReference对bean再一次依赖引用，主要应用SmartInstantiationAwareBeanPostProcessor //其中我们熟悉的AOP就是在这里将advice动态织入bean中，若没有则直接返回bean，不做任何处理 addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)); } // Initialize the bean instance. // 初始化实例 Object exposedObject = bean; try { //对bean进行填充，对各个属性进行注入，可能存在依赖其他bean的属性，则会递归初始化依赖bean populateBean(beanName, mbd, instanceWrapper); //调用初始化方法 exposedObject = initializeBean(beanName, exposedObject, mbd); } catch (Throwable ex) { if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) { throw (BeanCreationException) ex; } else { throw new BeanCreationException( mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex); } } if (earlySingletonExposure) { Object earlySingletonReference = getSingleton(beanName, false); //earlySingletonReference只有在检测到循环依赖的情况下才不为空 if (earlySingletonReference != null) { //如果exposedObject没有在初始化方法中被改变，也就是没有被增强 if (exposedObject == bean) { exposedObject = earlySingletonReference; } else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) { String[] dependentBeans = getDependentBeans(beanName); Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length); //检测依赖 for (String dependentBean : dependentBeans) { if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) { actualDependentBeans.add(dependentBean); } } /** * 因为bean创建完成后，其依赖的bean也一定是创建完成的 * 如果actualDependentBeans不为空，则说明依赖的bean还没有被完全创建好 * 也就是说还存在循环依赖 */ if (!actualDependentBeans.isEmpty()) { throw new BeanCurrentlyInCreationException(beanName, "Bean with name '" + beanName + "' has been injected into other beans [" + StringUtils.collectionToCommaDelimitedString(actualDependentBeans) + "] in its raw version as part of a circular reference, but has eventually been " + "wrapped. This means that said other beans do not use the final version of the " + "bean. This is often the result of over-eager type matching - consider using " + "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example."); } } } } // Register bean as disposable. try { //根据scope注册bean registerDisposableBeanIfNecessary(beanName, bean, mbd); } catch (BeanDefinitionValidationException ex) { throw new BeanCreationException( mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex); } return exposedObject; } 分析一下这个函数设计思路：
- 如果是单例则需要首先清除缓存。
- 实例化 bean ，将 BeanDefinition 转换为 BeanWrapper。 转换是一个复杂的过程，但是我们可以尝试概括大致的功能，如下所示。
- 如果存在工厂方法则使用工厂方法进行实例化。
- 如果一个类有多个构造函数，每个构造函数都有不同的参数，所以需要根据参数锁定构造 函数并进行实例化。
- 如果既不存在工厂方法也不存在带有参数的构造函数，则使用默认的构造函数进行 bean 的实例化。
MergedBeanDefinitionPostProcessor的应用。 bean 合并后的处理，Autowired注解正是通过此方法实现诸如类型的预解析。- 依赖处理。 在 Spring 中会有循环依赖的情况，例如，当 A 中含有 B 的属性，而 B 中又含有 A 的属性 时就会构成一个循环依赖，此时如果 A 和 B 都是单例，那么在 Spring 中的处理方式就是当创建 B 的时候，涉及自动注入 A 的步骤，并不是直接去再次创建 A，而是通过放入缓存中的
ObjectFactory来创建实例，这样就解决了循环依赖的问题。 - 属性填充。 将所有属性填充至 bean 的实例中。
- 调用初始化方法。在属性填充完成后，这里会进行初始化方法的调用。
- 循环依赖检查。 之前有提到过，在 Sping 中解决循环依赖只对单例有效，而对于
prototype的 bean, Spring 没有好的解决办法，唯一要做的就是抛出异常。 在这个步骤里面会检测已经加载的 bean 是否 已经出现了依赖循环，并判断是再需要抛出异常。 - 注册
DisposableBean。 如果配置了destroy-method，这里需要注册以便于在销毁时候调用。 - 完成创建井返回。
可以看到上面的步骤非常的繁琐，每一步骤都使用了大量的代码来完成其功能，最复杂也是最难以理解的当属循环依赖的处理，在真正进入 doCreateBean() 前我们有必要先了解下循环依赖，这里会在下一篇文章Spring Ioc源码分析系列--自动注入循环依赖的处理图文并茂去分析。
下面就按照上述的点逐个分析，接下来肯定是枯燥无味的，那开始吧。
清除factoryBeanInstanceCache缓存
首先如果是单例，会到factoryBeanInstanceCache中获取是否存在缓存，如果有这里就会从缓存里获取一个instanceWrapper，不需要再去走复杂的创建流程了。
对应代码如下：
if (mbd.isSingleton()) { // 你可以暂时理解为，这个地方返回的就是个null instanceWrapper = this.factoryBeanInstanceCache.remove(beanName); } 实例化 bean
又到了实例化bean，是不是反反复复看了很多次，到底哪里才真的创建一个bean，别慌，这里真的是真正创建bean的地方了，再套娃就是狗。
跟进createBeanInstance(beanName, mbd, args)方法。这个方法干了哪几件事？
- 首先尝试调用
obtainFromSupplier()实例化bean - 尝试调用
instantiateUsingFactoryMethod()实例化bean - 根据给定参数推断构造函数实例化bean
- 以上均无，则使用默认构造函数实例化bean
/** * Create a new instance for the specified bean, using an appropriate instantiation strategy: * factory method, constructor autowiring, or simple instantiation. * * 使用适当的实例化策略为指定的 bean 创建一个新实例：工厂方法、构造函数自动装配或简单实例化。 * * @param beanName the name of the bean * @param mbd the bean definition for the bean * @param args explicit arguments to use for constructor or factory method invocation * @return a BeanWrapper for the new instance * @see #obtainFromSupplier * @see #instantiateUsingFactoryMethod * @see #autowireConstructor * @see #instantiateBean */ protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) { // Make sure bean class is actually resolved at this point. // 确保此时实际解析了 bean 类。 Class<?> beanClass = resolveBeanClass(mbd, beanName); if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) { throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Bean class isn't public, and non-public access not allowed: " + beanClass.getName()); } // 通过bd中提供的instanceSupplier来获取一个对象 // 正常bd中都不会有这个instanceSupplier属性，这里也是Spring提供的一个扩展点，但实际上不常用 Supplier<?> instanceSupplier = mbd.getInstanceSupplier(); if (instanceSupplier != null) { return obtainFromSupplier(instanceSupplier, beanName); } //如果工厂方法不为null，则使用工厂方法初始化策略 // bd中提供了factoryMethodName属性，那么要使用工厂方法的方式来创建对象， // 工厂方法又会区分静态工厂方法跟实例工厂方法 if (mbd.getFactoryMethodName() != null) { return instantiateUsingFactoryMethod(beanName, mbd, args); } // Shortcut when re-creating the same bean... // 在原型模式下，如果已经创建过一次这个Bean了，那么就不需要再次推断构造函数了 // 是否推断过构造函数 boolean resolved = false; // 构造函数是否需要进行注入 boolean autowireNecessary = false; if (args == null) { synchronized (mbd.constructorArgumentLock) { //一个类里面有多个构造函数，每个构造函数都有不同的参数，所以调用前需要根据参数锁定要调用的构造函数或工厂方法 if (mbd.resolvedConstructorOrFactoryMethod != null) { resolved = true; autowireNecessary = mbd.constructorArgumentsResolved; } } } //如果已经解析过则使用解析好的构造函数方法，不需要再次锁定 if (resolved) { if (autowireNecessary) { //构造函数自动注入 return autowireConstructor(beanName, mbd, null, null); } else { //使用默认构造函数进行构造 return instantiateBean(beanName, mbd); } } // Candidate constructors for autowiring? //需要根据参数解析构造函数 Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName); if (ctors != null || mbd.getResolvedAutowireMode() == AUTOWIRE_CONSTRUCTOR || mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args)) { //构造函数自动注入 return autowireConstructor(beanName, mbd, ctors, args); } // Preferred constructors for default construction? // 默认构造的首选构造函数？ ctors = mbd.getPreferredConstructors(); if (ctors != null) { return autowireConstructor(beanName, mbd, ctors, null); } // No special handling: simply use no-arg constructor. //使用默认构造函数 return instantiateBean(beanName, mbd); } 接下来分析以上几点，算了不分析，太长了。我在另一篇文章Spring Ioc源码分析系列--实例化Bean的几种方法会填坑。这里会详细分析上面的几点，好好把握，估计看到这都不知道啥跟啥了。
MergedBeanDefinitionPostProcessor的应用
到这里我们已经实例化了一个bean对象，但是这个bean只是个半成品，空有外壳而无内在，所以接下来的工作就是对里面的内容进行填充。那毫无疑问，按照Spring的尿性，肯定会在真正开始之前给你一个扩展点，让你还要机会在属性填充之前修改某些东西。我们经常使用的@Autowired注解就是在这里实现的，后续会写一篇Spring Ioc源码分析系列--@Autowired注解的实现原理结合源码和例子去分析它的实现。
跟进代码查看，比较简单，就是获取所有的MergedBeanDefinitionPostProcessor，然后依次执行它的postProcessMergedBeanDefinition()方法。
/** * Apply MergedBeanDefinitionPostProcessors to the specified bean definition, * invoking their {@code postProcessMergedBeanDefinition} methods. * * 将 MergedBeanDefinitionPostProcessors 应用于指定的 bean 定义， * 调用它们的 {@code postProcessMergedBeanDefinition} 方法。 * * 可以看到这个方法的代码还是很简单的， * 就是调用了MergedBeanDefinitionPostProcessor的postProcessMergedBeanDefinition方法 * * @param mbd the merged bean definition for the bean * @param beanType the actual type of the managed bean instance * @param beanName the name of the bean * @see MergedBeanDefinitionPostProcessor#postProcessMergedBeanDefinition */ protected void applyMergedBeanDefinitionPostProcessors(RootBeanDefinition mbd, Class<?> beanType, String beanName) { for (BeanPostProcessor bp : getBeanPostProcessors()) { if (bp instanceof MergedBeanDefinitionPostProcessor) { MergedBeanDefinitionPostProcessor bdp = (MergedBeanDefinitionPostProcessor) bp; bdp.postProcessMergedBeanDefinition(mbd, beanType, beanName); } } } 依赖处理
这部分主要是为了处理循环依赖而做的准备，这里会根据earlySingletonExposure参数去判断是否允许循环依赖，如果允许，则会调用addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean))方法将bean的早期引用放入到singletonFactories中。关于循环依赖的详细处理过程，可以在下一篇文章Spring Ioc源码分析系列--自动注入循环依赖的处理里看到。
// Eagerly cache singletons to be able to resolve circular references // even when triggered by lifecycle interfaces like BeanFactoryAware. //是否需要提前暴露mbd.isSingleton() && this.allowCircularReferences && // isSingletonCurrentlyInCreation(beanName) boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName)); if (earlySingletonExposure) { if (logger.isTraceEnabled()) { logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references"); } //为避免后期循环依赖，可以在bean初始化完成前将创建实例的ObjectFactory加入工厂 //getEarlyBeanReference对bean再一次依赖引用，主要应用SmartInstantiationAwareBeanPostProcessor //其中我们熟悉的AOP就是在这里将advice动态织入bean中，若没有则直接返回bean，不做任何处理 addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)); } 跟进addSingletonFactory()方法，可以看到这里会先把早期引用放入到singletonFactories三级缓存中。
/** * Add the given singleton factory for building the specified singleton * if necessary. * * 如有必要，添加给定的单例工厂以构建指定的单例。 * * <p>To be called for eager registration of singletons, e.g. to be able to * resolve circular references. * * 被提前注册的单例Bean调用，例如用来解决循环依赖 * * @param beanName the name of the bean * @param singletonFactory the factory for the singleton object */ protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) { Assert.notNull(singletonFactory, "Singleton factory must not be null"); synchronized (this.singletonObjects) { if (!this.singletonObjects.containsKey(beanName)) { this.singletonFactories.put(beanName, singletonFactory); this.earlySingletonObjects.remove(beanName); this.registeredSingletons.add(beanName); } } } 那放入到singletonFactories里面的是什么呢？从上面可以看到，这是一个lambada表达式，调用的方法的是getEarlyBeanReference()，跟进代码查看。
/** * Obtain a reference for early access to the specified bean, * typically for the purpose of resolving a circular reference. * * 获取对指定 bean 的早期访问的引用，通常用于解析循环引用。 * * @param beanName the name of the bean (for error handling purposes) * @param mbd the merged bean definition for the bean * @param bean the raw bean instance * @return the object to expose as bean reference */ protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) { Object exposedObject = bean; if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { for (BeanPostProcessor bp : getBeanPostProcessors()) { if (bp instanceof SmartInstantiationAwareBeanPostProcessor) { SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp; // 对 bean 再一次依赖引用 // 主要应用 SmartInstantiationAwareBeanPostProcessor, // 其中我们熟知的 AOP 就是在这里将 advice 动态织入 bean 中， 若没有则直接返回 bean ，不做任何处理 exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName); } } } return exposedObject; } 属性填充
到这里会已经完成了bean的实例化，早期引用的暴露，那接下来就到了属性填充的部分，开始对bean进行各种赋值，让一个空壳半成品bean完善成一个有血有肉的正常bean。
这里可能存在依赖其他bean的属性，则会递归初始化依赖bean。
在 populateBean() 函数中提供了这样的处理流程。
InstantiationAwareBeanPostProcessor处理器的postProcessAfterinstantiation函数的应用， 此函数可以控制程序是否继续进行属性填充。- 根据注入类型（ byName/byType ），提取依赖的 bean，并统一存入
PropertyValues中。 - 应用
InstantiationAwareBeanPostProcessor处理器的postProcessPropertyValues方法， 对属性获取完毕填充前对属性的再次处理，典型应用是RequiredAnnotationBeanPostProcessor类中对属性的验证。 - 将所有
PropertyValues中的属性填充至BeanWrapper中。
跟进代码查看，又很长，这一块的代码真的是又臭又长。但是注释很详细，可以跟着看看。
/** * Populate the bean instance in the given BeanWrapper with the property values * from the bean definition. * * 使用 bean 定义中的属性值填充给定 BeanWrapper 中的 bean 实例。 * * @param beanName the name of the bean * @param mbd the bean definition for the bean * @param bw the BeanWrapper with bean instance */ @SuppressWarnings("deprecation") // for postProcessPropertyValues protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) { if (bw == null) { if (mbd.hasPropertyValues()) { throw new BeanCreationException( mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance"); } else { // Skip property population phase for null instance. //没有可填充的属性 return; } } // Give any InstantiationAwareBeanPostProcessors the opportunity to modify the // state of the bean before properties are set. This can be used, for example, // to support styles of field injection. boolean continueWithPropertyPopulation = true; //给InstantiationAwareBeanPostProcessors最后一次机会在属性设置前来改变 bean //如：可以用来支持属性注入的类型 // 满足两个条件，不是合成类 && 存在InstantiationAwareBeanPostProcessor // 其中InstantiationAwareBeanPostProcessor主要作用就是作为Bean的实例化前后的钩子 // 外加完成属性注入，对于三个方法就是 // postProcessBeforeInstantiation 创建对象前调用 // postProcessAfterInstantiation 对象创建完成，@AutoWired注解解析后调用 // postProcessPropertyValues（已过期，被postProcessProperties替代） 进行属性注入 // 下面这段代码的主要作用就是我们可以提供一个InstantiationAwareBeanPostProcessor // 提供的这个后置处理如果实现了postProcessAfterInstantiation方法并且返回false // 那么可以跳过Spring默认的属性注入，但是这也意味着我们要自己去实现属性注入的逻辑 // 所以一般情况下，我们也不会这么去扩展 if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { for (BeanPostProcessor bp : getBeanPostProcessors()) { if (bp instanceof InstantiationAwareBeanPostProcessor) { InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp; //返回值为是否继续填充bean if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) { continueWithPropertyPopulation = false; break; } } } } //如果后处理器发出停止填充命令则终止后续操作 if (!continueWithPropertyPopulation) { return; } // 这里其实就是判断XML是否提供了属性相关配置 PropertyValues pvs = (mbd.hasPropertyValues() ? mbd.getPropertyValues() : null); // 确认注入模型 int resolvedAutowireMode = mbd.getResolvedAutowireMode(); // 主要处理byName跟byType两种注入模型，byConstructor这种注入模型在创建对象的时候已经处理过了 // 这里都是对自动注入进行处理，byName跟byType两种注入模型均是依赖setter方法 // byName,根据setter方法的名字来查找对应的依赖，例如setA,那么就是去容器中查找名字为a的Bean // byType,根据setter方法的参数类型来查找对应的依赖，例如setXx(A a)，就是去容器中查询类型为A的bean if (resolvedAutowireMode == AUTOWIRE_BY_NAME || resolvedAutowireMode == AUTOWIRE_BY_TYPE) { MutablePropertyValues newPvs = new MutablePropertyValues(pvs); // Add property values based on autowire by name if applicable. if (resolvedAutowireMode == AUTOWIRE_BY_NAME) { //根据名称注入 autowireByName(beanName, mbd, bw, newPvs); } // Add property values based on autowire by type if applicable. if (resolvedAutowireMode == AUTOWIRE_BY_TYPE) { //根据类型注入 autowireByType(beanName, mbd, bw, newPvs); } // pvs是XML定义的属性 // 自动注入后，bean实际用到的属性就应该要替换成自动注入后的属性 pvs = newPvs; } //后置处理器已经初始化 // 检查是否有InstantiationAwareBeanPostProcessor // 前面说过了，这个后置处理器就是来完成属性注入的 boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors(); //需要依赖检查 // 是否需要依赖检查，默认是不会进行依赖检查的 boolean needsDepCheck = (mbd.getDependencyCheck() != AbstractBeanDefinition.DEPENDENCY_CHECK_NONE); // 下面这段代码有点麻烦了，因为涉及到版本问题 // 其核心代码就是调用了postProcessProperties完成了属性注入 PropertyDescriptor[] filteredPds = null; // 存在InstantiationAwareBeanPostProcessor，我们需要调用这类后置处理器的方法进行注入 if (hasInstAwareBpps) { if (pvs == null) { pvs = mbd.getPropertyValues(); } for (BeanPostProcessor bp : getBeanPostProcessors()) { if (bp instanceof InstantiationAwareBeanPostProcessor) { InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp; // 这句就是核心 // Autowired 是通过 AutowiredAnnotationBeanPostProcessor#postProcessProperties() 实现的 PropertyValues pvsToUse = ibp.postProcessProperties(pvs, bw.getWrappedInstance(), beanName); if (pvsToUse == null) { if (filteredPds == null) { // 得到需要进行依赖检查的属性的集合 filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching); } //对所有需要依赖检查的属性做后置处理 // 这个方法已经过时了，放到这里就是为了兼容老版本 pvsToUse = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName); if (pvsToUse == null) { return; } } pvs = pvsToUse; } } } // 需要进行依赖检查 if (needsDepCheck) { if (filteredPds == null) { // 得到需要进行依赖检查的属性的集合 filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching); } //依赖检查，对应depends-on属性，3.0已经弃用此属性 // 对需要进行依赖检查的属性进行依赖检查 checkDependencies(beanName, mbd, filteredPds, pvs); } // 将XML中的配置属性应用到Bean上 if (pvs != null) { //将属性应用到bean中 applyPropertyValues(beanName, mbd, bw, pvs); } } 这里看到这里会根据byName或者byType方式寻找依赖，然后调用applyPropertyValues()将属性注入到BeanWrapperImpl里。
先来看autowireByName()方法，顾名思义，这里会根据属性名去获取依赖。
/** * Fill in any missing property values with references to * other beans in this factory if autowire is set to "byName". * * 如果 autowire 设置为“byName”，则使用对该工厂中其他 bean 的引用填充任何缺少的属性值。 * * @param beanName the name of the bean we're wiring up. * Useful for debugging messages; not used functionally. * @param mbd bean definition to update through autowiring * @param bw the BeanWrapper from which we can obtain information about the bean * @param pvs the PropertyValues to register wired objects with */ protected void autowireByName( String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) { //寻找bw中需要依赖注入的属性值 // 得到符合下面条件的属性名称 // 1.有setter方法 // 2.需要进行依赖检查 // 3.不包含在XML配置中 // 4.不是简单类型（基本数据类型，枚举，日期等） // 这里可以看到XML配置优先级高于自动注入的优先级 // 不进行依赖检查的属性，也不会进行属性注入 String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, bw); for (String propertyName : propertyNames) { if (containsBean(propertyName)) { //递归初始化相关bean Object bean = getBean(propertyName); // 将自动注入的属性添加到pvs中去 pvs.add(propertyName, bean); //注册依赖 registerDependentBean(propertyName, beanName); if (logger.isTraceEnabled()) { logger.trace("Added autowiring by name from bean name '" + beanName + "' via property '" + propertyName + "' to bean named '" + propertyName + "'"); } } else { if (logger.isTraceEnabled()) { logger.trace("Not autowiring property '" + propertyName + "' of bean '" + beanName + "' by name: no matching bean found"); } } } } 接下来看autowireByType()，该方法会根据属性的类型去获取依赖。也比较简单明了。
/** * Abstract method defining "autowire by type" (bean properties by type) behavior. * <p>This is like PicoContainer default, in which there must be exactly one bean * of the property type in the bean factory. This makes bean factories simple to * configure for small namespaces, but doesn't work as well as standard Spring * behavior for bigger applications. * * 定义“按类型自动装配”（按类型的 bean 属性）行为的抽象方法。 * <p>这类似于 PicoContainer 默认值，其中 bean 工厂中必须只有一个属性类型的 bean。 * 这使得 bean 工厂易于为小型命名空间配置，但不能像标准 Spring 行为那样为大型应用程序工作。 * * @param beanName the name of the bean to autowire by type * @param mbd the merged bean definition to update through autowiring * @param bw the BeanWrapper from which we can obtain information about the bean * @param pvs the PropertyValues to register wired objects with */ protected void autowireByType( String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) { // 这个类型转换器，主要是在处理@Value时需要使用 TypeConverter converter = getCustomTypeConverter(); if (converter == null) { converter = bw; } Set<String> autowiredBeanNames = new LinkedHashSet<>(4); //寻找bw中需要依赖注入的属性 // 得到符合下面条件的属性名称 // 1.有setter方法 // 2.需要进行依赖检查 // 3.不包含在XML配置中 // 4.不是简单类型（基本数据类型，枚举，日期等） // 这里可以看到XML配置优先级高于自动注入的优先级 String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, bw); for (String propertyName : propertyNames) { try { PropertyDescriptor pd = bw.getPropertyDescriptor(propertyName); // Don't try autowiring by type for type Object: never makes sense, // even if it technically is a unsatisfied, non-simple property. // 不要尝试为 Object 类型按类型自动装配：永远没有意义，即使它在技术上是一个不令人满意的、不简单的属性。 if (Object.class != pd.getPropertyType()) { //探测指定属性的set方法 // 这里获取到的就是setter方法的参数，因为我们需要按照类型进行注入嘛 MethodParameter methodParam = BeanUtils.getWriteMethodParameter(pd); // Do not allow eager init for type matching in case of a prioritized post-processor. // 如果是PriorityOrdered在进行类型匹配时不会去匹配factoryBean // 如果不是PriorityOrdered，那么在查找对应类型的依赖的时候会会去匹factoryBean // 这就是Spring的一种设计理念，实现了PriorityOrdered接口的Bean被认为是一种 // 最高优先级的 Bean，这一类的Bean在进行为了完成装配而去检查类型时， // 不去检查 factoryBean // 具体可以参考PriorityOrdered接口上的注释文档 boolean eager = !PriorityOrdered.class.isInstance(bw.getWrappedInstance()); // 将参数封装成为一个依赖描述符 // 依赖描述符会通过:依赖所在的类,字段名/方法名,依赖的具体类型等来描述这个依赖 DependencyDescriptor desc = new AutowireByTypeDependencyDescriptor(methodParam, eager); /** * 解析指定beanName的属性所匹配的值，并把解析到的属性名存储在autowiredBeanNames中， * 当属性存在多个封装bean时，如： * @Autowire * private List<A> list; * 将会找到所有匹配A类型的bean并将其注入 * 解析依赖，这里会处理@Value注解 * 另外，通过指定的类型到容器中查找对应的bean */ Object autowiredArgument = resolveDependency(desc, beanName, autowiredBeanNames, converter); if (autowiredArgument != null) { // 将查找出来的依赖属性添加到pvs中，后面会将这个pvs应用到bean上 pvs.add(propertyName, autowiredArgument); } // 注册bean直接的依赖关系 for (String autowiredBeanName : autowiredBeanNames) { //注册依赖 registerDependentBean(autowiredBeanName, beanName); if (logger.isTraceEnabled()) { logger.trace("Autowiring by type from bean name '" + beanName + "' via property '" + propertyName + "' to bean named '" + autowiredBeanName + "'"); } } autowiredBeanNames.clear(); } } catch (BeansException ex) { throw new UnsatisfiedDependencyException(mbd.getResourceDescription(), beanName, propertyName, ex); } } } 属性依赖都获取完了，接下来就是按部就班的进行注入了。
跟进applyPropertyValues()方法，逻辑比较复杂。但是最终是调用了反射，给对应的属性进行了赋值，这里深入的就不再展开了。
/** * Apply the given property values, resolving any runtime references * to other beans in this bean factory. Must use deep copy, so we * don't permanently modify this property. * * 应用给定的属性值，解析对此 bean 工厂中其他 bean 的任何运行时引用。必须使用深拷贝，所以我们不会永久修改这个属性。 * * @param beanName the bean name passed for better exception information * @param mbd the merged bean definition * @param bw the BeanWrapper wrapping the target object * @param pvs the new property values */ protected void applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs) { if (pvs.isEmpty()) { return; } if (System.getSecurityManager() != null && bw instanceof BeanWrapperImpl) { ((BeanWrapperImpl) bw).setSecurityContext(getAccessControlContext()); } MutablePropertyValues mpvs = null; List<PropertyValue> original; if (pvs instanceof MutablePropertyValues) { mpvs = (MutablePropertyValues) pvs; if (mpvs.isConverted()) { // Shortcut: use the pre-converted values as-is. // 快捷方式：按原样使用转换前的值。 try { bw.setPropertyValues(mpvs); return; } catch (BeansException ex) { throw new BeanCreationException( mbd.getResourceDescription(), beanName, "Error setting property values", ex); } } original = mpvs.getPropertyValueList(); } else { original = Arrays.asList(pvs.getPropertyValues()); } TypeConverter converter = getCustomTypeConverter(); if (converter == null) { converter = bw; } BeanDefinitionValueResolver valueResolver = new BeanDefinitionValueResolver(this, beanName, mbd, converter); // Create a deep copy, resolving any references for values. // 创建一个深拷贝副本，解析任何值的引用。 List<PropertyValue> deepCopy = new ArrayList<>(original.size()); boolean resolveNecessary = false; for (PropertyValue pv : original) { if (pv.isConverted()) { deepCopy.add(pv); } else { String propertyName = pv.getName(); Object originalValue = pv.getValue(); if (originalValue == AutowiredPropertyMarker.INSTANCE) { Method writeMethod = bw.getPropertyDescriptor(propertyName).getWriteMethod(); if (writeMethod == null) { throw new IllegalArgumentException("Autowire marker for property without write method: " + pv); } originalValue = new DependencyDescriptor(new MethodParameter(writeMethod, 0), true); } // 给定一个 PropertyValue，返回一个值，必要时解析对工厂中其他 bean 的任何引用 Object resolvedValue = valueResolver.resolveValueIfNecessary(pv, originalValue); Object convertedValue = resolvedValue; boolean convertible = bw.isWritableProperty(propertyName) && !PropertyAccessorUtils.isNestedOrIndexedProperty(propertyName); if (convertible) { convertedValue = convertForProperty(resolvedValue, propertyName, bw, converter); } // Possibly store converted value in merged bean definition, // in order to avoid re-conversion for every created bean instance. // 可能将转换后的值存储在合并的 bean 定义中，以避免对每个创建的 bean 实例进行重新转换。 if (resolvedValue == originalValue) { if (convertible) { pv.setConvertedValue(convertedValue); } deepCopy.add(pv); } else if (convertible && originalValue instanceof TypedStringValue && !((TypedStringValue) originalValue).isDynamic() && !(convertedValue instanceof Collection || ObjectUtils.isArray(convertedValue))) { pv.setConvertedValue(convertedValue); deepCopy.add(pv); } else { resolveNecessary = true; deepCopy.add(new PropertyValue(pv, convertedValue)); } } } if (mpvs != null && !resolveNecessary) { mpvs.setConverted(); } // Set our (possibly massaged) deep copy. // 设置我们的（可能是经过按摩的）深拷贝。 try { bw.setPropertyValues(new MutablePropertyValues(deepCopy)); } catch (BeansException ex) { throw new BeanCreationException( mbd.getResourceDescription(), beanName, "Error setting property values", ex); } } 调用初始化方法
初始化方法的调用逻辑在initializeBean(beanName, exposedObject, mbd)里面，跟进代码查看。
一看是不是很清晰，所以以后再遇到问你啥啥啥方法先执行，直接叼面试官。
/** * * initializeBean()方法依次调用四个方法 * 1.invokeAwareMethods() * 2.applyBeanPostProcessorsBeforeInitialization() * 3.invokeInitMethods() * 4.applyBeanPostProcessorsAfterInitialization() * */ protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) { if (System.getSecurityManager() != null) { AccessController.doPrivileged((PrivilegedAction<Object>) () -> { invokeAwareMethods(beanName, bean); return null; }, getAccessControlContext()); } else { // 1.先调用实现 aware 接口的方法 invokeAwareMethods(beanName, bean); } Object wrappedBean = bean; if (mbd == null || !mbd.isSynthetic()) { // 2.调用 BeanPostProcessor#postProcessBeforeInitialization()方法 wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName); } try { // 3.调用初始化方法，例如实现了 InitializingBean#afterPropertiesSet() 方法 invokeInitMethods(beanName, wrappedBean, mbd); } catch (Throwable ex) { throw new BeanCreationException( (mbd != null ? mbd.getResourceDescription() : null), beanName, "Invocation of init method failed", ex); } if (mbd == null || !mbd.isSynthetic()) { // 4.最后调用 BeanPostProcessor#postProcessAfterInitialization() wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName); } return wrappedBean; } 循环依赖检查
这一步主要是实现一个兜底的检测，避免出现注入了一个本该被代理的但是却注入了一个原生bean的情况，这部分会在循环依赖的文章里结合来分析。
先看下代码。
if (earlySingletonExposure) { Object earlySingletonReference = getSingleton(beanName, false); //earlySingletonReference只有在检测到循环依赖的情况下才不为空 if (earlySingletonReference != null) { //如果exposedObject没有在初始化方法中被改变，也就是没有被增强 if (exposedObject == bean) { exposedObject = earlySingletonReference; } else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) { String[] dependentBeans = getDependentBeans(beanName); Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length); //检测依赖 for (String dependentBean : dependentBeans) { if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) { actualDependentBeans.add(dependentBean); } } /** * 因为bean创建完成后，其依赖的bean也一定是创建完成的 * 如果actualDependentBeans不为空，则说明依赖的bean还没有被完全创建好 * 也就是说还存在循环依赖 */ if (!actualDependentBeans.isEmpty()) { throw new BeanCurrentlyInCreationException(beanName, "Bean with name '" + beanName + "' has been injected into other beans [" + StringUtils.collectionToCommaDelimitedString(actualDependentBeans) + "] in its raw version as part of a circular reference, but has eventually been " + "wrapped. This means that said other beans do not use the final version of the " + "bean. This is often the result of over-eager type matching - consider using " + "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example."); } } } } 注册 DisposableBean
这也是一个回调的操作，注册一些销毁的方法。Spring 中不但提供了对于初始化方法的扩展人口 ， 同样也提供了销毁方法的扩展入口，对 于销毁方法的扩展，除了我们熟知的配置属性 destroy-method 方法外，用户还可以注册后处理器 DestructionAwareBeanPostProcessor 来统一处理 bean 的销毁方法，跟进代码registerDisposableBeanIfNecessary()。
/** * Add the given bean to the list of disposable beans in this factory, * registering its DisposableBean interface and/or the given destroy method * to be called on factory shutdown (if applicable). Only applies to singletons. * * 将给定的 bean 添加到该工厂的一次性 bean 列表中， * 注册其 DisposableBean 接口和或在工厂关闭时调用的给定销毁方法（如果适用）。仅适用于单例。 * * @param beanName the name of the bean * @param bean the bean instance * @param mbd the bean definition for the bean * @see RootBeanDefinition#isSingleton * @see RootBeanDefinition#getDependsOn * @see #registerDisposableBean * @see #registerDependentBean */ protected void registerDisposableBeanIfNecessary(String beanName, Object bean, RootBeanDefinition mbd) { AccessControlContext acc = (System.getSecurityManager() != null ? getAccessControlContext() : null); if (!mbd.isPrototype() && requiresDestruction(bean, mbd)) { if (mbd.isSingleton()) { // Register a DisposableBean implementation that performs all destruction // work for the given bean: DestructionAwareBeanPostProcessors, // DisposableBean interface, custom destroy method. // 注册一个为给定 bean 执行所有销毁工作的 DisposableBean 实现：DestructionAwareBeanPostProcessors、DisposableBean 接口、自定义销毁方法。 /** * 单例模式下需要销毁的bean，此方法中会处理实现DisposableBean的bean * 并且对所有的bean使用DestructionAwareBeanPostProcessors处理 * DisposableBean DestructionAwareBeanPostProcessors */ registerDisposableBean(beanName, new DisposableBeanAdapter(bean, beanName, mbd, getBeanPostProcessors(), acc)); } else { // A bean with a custom scope... // 自定义scope处理 Scope scope = this.scopes.get(mbd.getScope()); if (scope == null) { throw new IllegalStateException("No Scope registered for scope name '" + mbd.getScope() + "'"); } scope.registerDestructionCallback(beanName, new DisposableBeanAdapter(bean, beanName, mbd, getBeanPostProcessors(), acc)); } } } 总结
本文主要分析了doCreateBean()方法，但是讲得比较粗糙。回忆一下本文的思路，首先是通过类名反射得到一个class对象，然后推断构造函数去实例化得到一个bean对象，当然这部分没有深入细节去说，分多了一篇文章。然后通过byName和byType两种方式去获取依赖注入，之后通过反射将属性注入到对象中。除去一些边边角角的校验，总的思路就是这样，还是相对清晰的，就是细节比较多。
这里牵扯的东西比较多，也算是Ioc里面比较难啃的部分了。我回看一遍我写的文章，觉得整体言不达意，脑子里想十分，说出来可能只有六分，写出来的就剩三分了。
个人水平有限，如有错误，还请指出。
如果有人看到这里，那在这里老话重提。与君共勉，路漫漫其修远兮，吾将上下而求索。
