最近看到一位大神的博客，springIOC过程写的那叫一个详细，自己看了一遍之后想把自己看到的整理一份出来，顺便自己也写个博客，加深一下印象，可以以后随时查阅复习。 文末附手动实现的简易ioc，理解原理非常好用。 首先上几张图：

上面几张图片（来源于网络）大家应该都看过或者大概知道，接下来开始分析ioc的加载过程：

一般开始都是这样一句代码：

意思是加载xml文件创建一个ApplicationContext 的Spring 容器。 那么就从new ClassPathXmlApplicationContext这个构造方法开始看吧。进入源码： 其实可以看到他是来到这里了

上面这个构造方法呢，其实就是new ClassPathXmlApplicationContext("classpath:application.xml") 真正开始的地方。开始之前大家先看看上面第二、第三张图“ApplicationContext 的继承图”和“BeanFactory的继承图”，ClassPathXmlApplicationContext 经过好几次继承才到 ApplicationContext 接口，了解一下ApplicationContext 的大体结构。

ApplicationContext 其实就是一个BeanFactory，

可以看到这个方法里面调用了很多的方法，我们从开始说起：

这就是整个refresh()方法调用的所有方法。这里只是简单描述一下，我们重点来看ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();和finishBeanFactoryInitialization(beanFactory);这两个方法。

先说ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); 这一步上面简单介绍过了，作用是把配置文件解析成一个个BeanBeanDefinition，并且注册到BeanFactory中，点进去源码：

这个方法中第一步refreshBeanFactory();方法的作用是关闭旧的 BeanFactory (如果有)，创建新的 BeanFactory，加载 Bean 定义、注册 Bean 等，然后getBeanFactory();就是返回刚刚创建的 BeanFactory(其实就是DefaultListableBeanFactory)，我们进入refreshBeanFactory();方法，在AbstractRefreshableApplicationContext类中：

下面看customizeBeanFactory(beanFactory);方法，这个方法作用：是否允许 Bean 覆盖、是否允许循环引用，这是什么意思呢？这就要说到BeanDefinition了，这里的 BeanDefinition 就是我们所说的 Spring 的 Bean，我们自己定义的各个 Bean 其实会转换成一个个 BeanDefinition 存在于 Spring 的 BeanFactory 中，下面贴出来开头我说的大神的关于BeanDefinition接口的代码注释：

BeanDefinition 的覆盖问题就是在配置文件中定义 bean 时使用了相同的 id 或 name，默认情况下，allowBeanDefinitionOverriding 属性为 null，如果在同一配置文件中重复了，会抛错，但是如果不是同一配置文件中，会发生覆盖。 循环引用：A 依赖 B，而 B 依赖 A。或 A 依赖 B，B 依赖 C，而 C 依赖 A。 默认情况下，Spring 允许循环依赖，当然如果你在 A 的构造方法中依赖 B，在 B 的构造方法中依赖 A 是不行的。

再看loadBeanDefinitions(beanFactory) 方法，这个方法将根据配置，加载各个 Bean，然后放到 BeanFactory 中。先贴上源码：AbstractXmlApplicationContext类中

这个源码中我们重点看loadBeanDefinitions(beanDefinitionReader);，再点进去源码：

在这段源码中我么可以看到2个reader.loadBeanDefinitions()方法，其实两个最终都到了： AbstractBeanDefinitionReader类中：

这个方法里面，for循环每一个文件是一个resource，最终返回 counter，表示总共加载了多少的 BeanDefinition。 进入loadBeanDefinitions(resource);方法，看源码： XmlBeanDefinitionReader类中的：

在这段代码中可以看到try代码块中一开始是根据外层循环调用的每一个Resource解析成一个InputStream 然后根据这个输入流解析； 这段源码的核心在doLoadBeanDefinitions(inputSource, encodedResource.getResource());继续进源码：

在这个方法里面可以看到doLoadDocument(inputSource, resource);方法是将 xml 文件(输入流和Resource)转换为 Document 对象，然后继续进源码：

这里创建了一个BeanDefinitionDocumentReader，然后spring通过BeanDefinitionDocumentReader 会进行委托bean定义的创建； 继续这个方法里面看：documentReader.registerBeanDefinitions(doc, createReaderContext(resource));点进去：

里面的doRegisterBeanDefinitions(root);方法就是从 xml 根节点开始解析文件，经过很多的步骤，一个配置文件终于转换为一颗 DOM 树了，注意，这里指的是其中一个配置文件，不是所有的，可以看到上面有个 for 循环的(loadBeanDefinitions(resource);是在for循环里面的)，进入doRegisterBeanDefinitions(root);方法，

从这段代码中可以看到BeanDefinitionDocumentReader最终是创建了一个BeanDefinitionParserDelegate ，把bean定义的创建委托给了BeanDefinitionParserDelegate 进行创建，这就是委托模式的提现。 同时也可以看到这段代码中先把this.delegate给了一个parent，然后又创建了一个Delegate，然后执行最后又把这个parent给回去了this.delegate，这是为了处理标签嵌套的问题，其实是个类似递归的操作。这里大家可以debugger试试嵌套的情况就明白了。 再看preProcessXml(root)，点进去一看是空实现，并且是protected的，那么很明显这就是一个模板方法模式(模板方法模式不了解的可以看我的这篇文章)，同理postProcessXml(root)也一样，就是在Bean定义创建前后提供扩展点。 那继续进入parseBeanDefinitions(root, this.delegate);看重点

这段代码是循环解析Element 的每一个节点，一般我们的普通bean都是走parseDefaultElement(ele, delegate);默认的解析流程。 但是这里有个else的自定义解析，这个很多人都忽略了，其实如果我们xml的配置文件中定义了 标签，他就会走这个自定义解析，然后解析aop内容，后续会在分析AOP源码，可以看这篇文章)说的时候讲这里。 这里我们还是走普通的beand解析逻辑parseDefaultElement(ele, delegate)，跟进去看：

这个方法见名知意，解析默认的Element，是4个if分支，第一个是解析import类型的，第二个是alias的，第三个是bean的(也就是我们普通bean默认的)，第四个是beans，也就是嵌套的(这里这个嵌套的就回到上面doRegisterBeanDefinitions方法了，也就是为什么说上面其实类似递归的原因) 这里我们只分析普通bean的解析处理，进入processBeanDefinition(ele, delegate);

这段代码首先通过delegate创建一个bean定义的持有者BeanDefinitionHolder，这一步其实BeanDefinition也在里面已经创建出来了。进入delegate.parseBeanDefinitionElement(ele)看

可以看到这段代码中有一个parseBeanDefinitionElement(ele, beanName, containingBean)，返回了一个AbstractBeanDefinition，这个方法里面实际是创建了一个GenericBeanDefinition，这里就不跟进去看了，代码篇幅太长了，这个里面很简单没啥绕的逻辑，大家跟着点点就能看到了。创建完GenericBeanDefinition之后设置了Class属性、构造器等等一些创建Bean实例需要的东西之后就返回了。

然后回到processBeanDefinition(ele, delegate);看BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());，由于这个时候已经创建了BeanDefinition并且有持有者BeanDefinitionHolder进行注册，所以继续跟进

很明显继续跟进到registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());，这里是一个接口调用，肯定是到了DefaultListableBeanFactory，但是在这个接口调用时我们需要注意的是第二个参数，从BeanDefinitionHolder中获取到了BeanDefinition对象，这个就是创建Bean定义持有者的时候顺带获取的BeanDefinition，通过上面的解析我们知道这个时候BeanDefinition已经创建好了，然后跟进这个方法进去：

在这个方法里面就可以看到经过一系列验证等等操作，最后把BeanDefinition放入了beanDefinitionMap，到这里bean定义就完成并注册到org.springframework.beans.factory.support.DefaultListableBeanFactory#beanDefinitionMap里面了

然后我们回到refresh() 方法，就是文章前部分的那个refresh() 方法…TvT 再贴一下refresh() 方法的源码吧，方便阅读： 我直接贴大神带注释的代码吧，看起来更方便一点

这个注释相当清楚 我们直接来看finishBeanFactoryInitialization(beanFactory);方法吧，到这一步为止BeanFactory 已经创建完成，并且所有的实现了 BeanFactoryPostProcessor 接口的 Bean 都已经初始化并且其中的 postProcessBeanFactory(factory) 方法已经得到回调执行了。而且 Spring 已经“手动”注册了一些特殊的 Bean，如 ‘environment’、‘systemProperties’ 等。剩下的就是初始化 singleton beans 了，我们知道它们是单例的，如果没有设置懒加载，那么 Spring 会在接下来初始化所有的 singleton beans。点进去看源码：

在这段代码中：首先初始化名字为 “conversionService” 的 Bean，为什么是conversionService 呢？原因是注册这个bean之后，类似于前端传给后端的非基础类型和基础类型的包装类之外，其他的就可以考虑采用ConversionService来进行类型等的转换，初始化这个 “conversionService” 实在上面源码中的beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));进行的。然后直接跳过来到beanFactory.preInstantiateSingletons();这个方法，这里开始初始化。点进去： DefaultListableBeanFactory这个类中：

在这段源码中，this.beanDefinitionNames 保存了所有的 beanNames，然后再循环，判断非抽象、非懒加载的 singletons，如果是FactoryBeanFactoryBean 的话，在 beanName 前面加上 ‘&’ 符号，再调用getBean(beanName);，如果是普通的bean，那么直接getBean(beanName);，这里都是在循环中的，循环结束后，所有的非单例bean就初始化完成了，接着下面如果我们定义的 bean 是实现了 SmartInitializingSingleton 接口的，那么在smartSingleton.afterSingletonsInstantiated();这里得到回调，我们直接进入getBean()方法： 可以看到最终到了AbstractBeanFactory类的doGetBean方法：

在这段源码中：

然后在进入createBean(beanName, mbd, args); …TvT AbstractAutowireCapableBeanFactory类中：

这里来到AbstractAutowireCapableBeanFactory类主要是为了采用 @Autowired 注解注入属性值(这个很常用，例子很多啊，就普通的依赖注入注解) 然后看到Class resolvedClass = resolveBeanClass(mbd, beanName);确保 BeanDefinition 中的 Class 被加载； 往下Object bean = resolveBeforeInstantiation(beanName, mbdToUse);让 InstantiationAwareBeanPostProcessor 在这一步有机会返回代理，和AOP有关；继续往下Object beanInstance = doCreateBean(beanName, mbdToUse, args);这是重点，当然是点进去啦：

然后看createBeanInstance(beanName, mbd, args);方法，实例化bean 的

这里我们选无参构造点进去看一下：

在上面的无参构造源码里面，真正的实例化是getInstantiationStrategy().instantiate(mbd, beanName, parent);这段代码，这行执行完成之后，包装成BeanWrapper就直接返回了，我们再点进去instantiate方法看看，在SimpleInstantiationStrategy类中:

在这个方法里面，如果if (!bd.hasMethodOverrides())进入这个if里面，那说明不存在方法覆写，使用 java 反射进行实例化，如果不进入使用 CGLIB进行实例化 下面这个就是反射实例化

另外存在方法覆写就是下面这个CGLIB进行实例化

到这里。终于bean被实例化了，然后再看看属性怎么注入的。。。TvT 回到AbstractAutowireCapableBeanFactory类的doCreateBean方法，我们刚才说到createBeanInstance是实例化，接下来就是属性注入方法：populateBean(beanName, mbd, instanceWrapper);点进去看：

这这段源码中，能到这里说明我们的bean已经实例化完成了(工厂方法或者构造方法)，开始设置属性值，

这段代码中：

好了。到这里，那么IOC的整个过程就完成了，包括容器初始化，bean的初始化、实例化、属性注入，全部跟着源码走了一遍，看起来真复杂，总结一下这个过程吧：

好像查了一下网上其他的资料，自己改改，差不多就是这个流程大家了解一下就行。 文末在给大家分享一个用最简单的方式实现一个SpringIOC的代码：简单实现springIOC 完事收工