目录

一、对IOC和DI的基本认识

（一）理解IoC，即“控制反转”

（二）IoC具体做什么？

（三）理解IoC和DI的关系

二、对IOC容器初始化的理解

三、对DI依赖注入的理解

参考书籍、文献和资料

干货分享，感谢您的阅读！当前没有去添加对应的源码，只是自己的一些总结，可能理解有错误或不到位，还请指出。

一、对IOC和DI的基本认识

（一）理解IoC，即“控制反转”

在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。理解好Ioc的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”，那我们来深入分析一下：

●谁控制谁，控制什么：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对象的创建以及外部资源获取（不只是对象包括比如文件等）。

●为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象：由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转，依赖对象的获取被反转了。

（二）IoC具体做什么？

IoC不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。

• 传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；
• 有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。
• IoC对编程实现由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。

（三）理解IoC和DI的关系

DI—Dependency Injection，即“依赖注入”：是组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。

理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：

●谁依赖于谁：当然是应用程序依赖于IoC容器；

●为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；

●谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；

●注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

IoC和DI由什么关系呢？其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。

二、对IOC容器初始化的理解

IOC容器初始化的基本步骤主要是两个方面：

• 初始化的入口由容器实现中的refresh()方法调用来完成。
• 对Bean定义载入IOC容器使用的方法是loadBeanDefinition()。

大致过程如下：

• 通过ReasourceLoader来完成资源文件的定位，DefaultResourceLoader是默认的实现，同时上下文本身就给出了ResourceLoader的实现，可以通过类路径、文件系统、URL等方式来定位资源。
• 如果XmlBeanFactory作为IOC容器，那么需要为它指定Bean定义的资源，也就是说Bean定义文件是通过抽象成Resource来被IOC容器处理，容器通过BeanDefinitionReader来完成定义信息的解析和Bean信息的注册，往往使用XmlBeanDefinitionReader来解析Bean的XML定义文件---实际的处理过程是委托给BeanDefinitionParserDelegate来完成的，从而得到Bean的定义信息，这些信息在Spring中使用BeanDefinition来表示（这个名字可以让我们想到loadBeanDefinition()、registerBeanDefinition()这些相关的方法，他们都是为处理BeanDefinition服务的）。
• 解析得到BeanDefinition以后，需要在IOC容器中注册，这由IOC实现BeanDefinitionRegister接口来实现，注册过程就是在IOC容器内容维护一个HashMap来保存得到的BeanDefinition的过程，这个HashMap是IOC容器持有Bean信息的场所，以后Bean的操作都是围绕这个HashMap来实现。
• 之后我们通过BeanFactory和ApplicationContext来享受Spring IOC的服务了，在使用IOC容器的时候我们注意到，除了少量粘合代码，绝大多数以正确IOC风格编写的应用程序代码完全不关心如何到达工厂，因为容器将把这些对象与容器管理的其他对象钩在了一起，基本的策略是把工厂放到已知的地方，最好放在对预期使用的上下文有意义的地方，以及代码要实际访问工厂的地方。
• Spring本身提供了对声明式载入Web应用程序用法的应用程序上下文，并将其存储在ServletContext的框架实现中。

三、对DI依赖注入的理解

当Spring IOC容器完成了Bean定义资源的定位、载入和解析注册，IOC容器就可以管理Bean定义的相关数据了，但是此时IOC容器还没有对所管理的Bean进行依赖注入，依赖注入 在以下两种情况下发生：

• 用户第一次调用getBean()方法时，IOC容器触发依赖注入。
• 当用户在配置文件中将元素配置了lazy-init=false属性时，即让容器在解析注册Bean定义时进行预实例化，触发依赖注入。

Beanfactory接口定义了Spring IOC容器的基本功能规范，是Spring IOC容器所应遵守的最低层和最基本的编程规范。BeanFactory接口中定义了几个getBean()方法，用于用户向IOC容器索取被管理的Bean的方法，通过分析其子类的具体实现来理解Spring IOC容器在用户索取Bean时如何完成依赖注入。

• getBean方法肯定不陌生，必经之路，然后调用doGetBean，进来以后首先会执行transformedBeanName找别名，看你的Bean上面是否起了别名。然后进行很重要的一步，getSingleton，这段代码就是从你的单例缓存池中获取Bean的实例。那么你第一次进来肯定是没有的，缓存里肯定是拿不到的。也就是一级缓存里是没有的。那么它怎么办呢？他会尝试去二级缓存中去拿，但是去二级缓存中拿并不是无条件的，首先要判断isSingletonCurrentlyInCreation(beanName)他要看你这个对象是否正在创建当中，如果不是直接就退出该方法，如果是的话，他就会去二级缓存earlySingletonObjects里面取，如果没拿到，它还接着判断allowEarlyReference这个东西是否为true。它的意思是说，是否允许让你从单例工厂对象缓存中去拿对象。默认为true。好了，此时如果进来那么就会通过singletonFactory.getObject()去单例工厂缓存中去拿。然后将缓存级别提升至二级缓存也就早期暴露的缓存。
• getSingleton执行完以后会走dependsOn方法，判断是否有dependsOn标记的循环引用，有的话直接卡死，抛出异常。比如说A依赖于B，B依赖于A 通过dependsOn注解去指定。此时执行到这里就会抛出异常。这里所指并非是构造函数的循环依赖。
• beforeSingletonCreation在这里方法里，就把你的对象标记为了早期暴露的对象，提前暴露对象用于创建Bean的实例。
• 紧接着就走创建Bean的流程开始。在创建Bean之前执行了一下resolveBeforeInstantiation。它的意思是说，代理AOPBean定义注册信息但是这里并不是实际去代理你的对象，因为对象还没有被创建。只是代理了Bean定义信息，还没有被实例化。把Bean定义信息放进缓存，以便我想代理真正的目标对象的时候，直接去缓存里去拿。
• 接下来就真正的走创建Bean流程，首先走进真正做事儿的方法doCreateBean然后找到createBeanInstance这个方法，在这里面它将为你创建你的Bean实例信息（Bean的实例）。如果说创建成功了，那么就把你的对象放入缓存中去（将创建好的提前曝光的对象放入singletonFactories三级缓存中）将对象从二级缓存中移除因为它已经不是提前暴露的对象了。但是。如果说在createBeanInstance这个方法中在创建Bean的时候它会去检测你的依赖关系，会去检测你的构造器。然后，如果说它在创建A对象的时候，发现了构造器里依赖了B，然后它又会重新走getBean的这个流程，当在走到这里的时候，又发现依赖了A此时就会抛出异常。为什么会抛出异常，因为，走getBean的时候他会去从你的单例缓存池中去拿，因为你这里的Bean还没有被创建好。自然不会被放进缓存中，所以它是在缓存中拿不到B对象的。反过来也是拿不到A对象的。造成了死循环故此直接抛异常。这就是为什么Spring IOC不能解决构造器循环依赖的原因。因为你还没来的急放入缓存你的对象是不存在的。所以不能创建。同理@Bean标注的循环依赖方法也是不能解决的，跟这个同理。那么多例就更不能解决了。为什么？因为在走createBeanInstance的时候，会判断是否是单例的Bean定义信息mbd.isSingleton()；如果是才会进来。所以多例的Bean压根就不会走进来，而是走了另一段逻辑，这里不做介绍。至此，构造器循环依赖和@Bean的循环依赖还有多例Bean的循环依赖为什么不能解决已经解释清楚。然后如果说，Bean创建成功了。那么会走后面的逻辑。
• 将创建好的Bean放入缓存，addSingletonFactory方法就是将你创建好的Bean放入三级缓存中，并且移除早期暴露的对象。
• 通过populateBean给属性赋值，我们知道，创建好的对象，并不是一个完整的对象，里面的属性还没有被赋值。所以这个方法就是为创建好的Bean为它的属性赋值。并且调用了我们实现的的XXXAware接口进行回调初始化，然后调用我们实现的Bean的后置处理器，给我们最后一次机会去修改Bean的属性。

参考书籍、文献和资料

1.【第二章】 IoC 之 2.1 IoC基础 ——跟我学Spring3 - 《亿级流量网站架构核心技术》~ - ITeye博客

2.《Sring 5 核心原理与30个类手写实战》，谭勇徳，中国公信出版社，2019.