前言
在前一篇文章中介绍了如何构建源码浏览环境，既然构建好了源码环境，本地也能够失常运行，那就开始浏览源码吧！
在浏览源码时，会参考官网文档，很多概念在官网都能够失去答案，有趣味的小伙伴们能够持续浏览，当做温习，写的不足之处，心愿多多领导。
IoC 和 DI
IoC
IoC（Inversion of Control），即管制反转。
之前是在对象外部 new 创立其余对象，而后应用。
而当初 Spring 中有一个容器能够在创立治理这些对象，并且将对象依赖的其余对象注入到这个对象中，这些对象的创立、销毁都由 Spring 进行治理。
相比以前来说，不再由本人管制其余对象的生命周期，这个过程就叫做管制反转。而负责对立治理这些类的容器就叫做 IoC 容器。
DI
IoC is also known as dependency injection (DI).
是不是感觉奇奇怪怪的，为什么说：IoC 也称为 DI。
其实 IoC 和 DI 是同一个概念的不同角度形容。
依赖注入是指组件之间的依赖关系由容器在运行期决定，形象的说，即由容器动静的将某个依赖关系注入到组件之中。
通过依赖注入机制，咱们只须要通过简略的配置，而无需任何代码就可指定指标须要的资源，实现本身的业务逻辑，而不须要关怀具体的资源来自何处，由谁实现。
Spring 是通过 DI 实现 IoC 的。
Container 和 Bean
Bean 是一个由 Spring IoC 容器实例化，组装和治理的对象。
置信大家都写过或者见过上面的代码：
/**
* 从容器中获取对象
* @author liuzhihang
* @date 2020/4/6 19:02
*/
@Component
public class CustomBeanFactory implements ApplicationContextAware {
private static ApplicationContext ctx;
@Override
public void setApplicationContext(ApplicationContext ac) throws BeansException {ctx = ac;}
public static Object getBean(String beanName) {return ctx.getBean(beanName);
}
} 代码逻辑很简略，就是从容器中获取到指定名称的 Bean，而其中 ApplicationContext 接口其实就是 Spring IoC 容器。
当然 ApplicationContext 是一个接口，它有很多实现，而它也继承了 BeanFactory。
尽管 BeanFactory 是 IoC 容器的最根本的模式，然而 ApplicationContext 对其进行了很多扩大，并具备 BeanFactory 的所有性能，通常倡议优先应用 ApplicationContext。
总结
在通过 Spring 官网 理解了 IoC、DI、容器和 Bean 的概念后，再联合平时的应用基本上能够有个大略流程。
当然，这只是一个很粗略的猜测，是否正确，还有待前面持续浏览源码，而后去验证。
相干举荐
- Spring 源码学习 01：源码浏览环境的搭建
- Spring 自调用事务生效，你是怎么解决的？
- APP 莫名解体，开始认为是 Header 中 name 大小写的锅，最初发现原来是容器的错