前言
不得不说，阅读源码是一件很让人头疼的事情，枯燥乏味，稍有不慎便落入代码的潮水中窒息而死。我想，每一位程序员就像穿梭丛林的冒险家，试图在这枯燥的旅途中，找寻着被隐藏的宝藏。
重要的是，我们应当如何在这代码丛林，找到我们的宝藏，或者应该说是我，应该怎么找到我想要的，也许，带着问题去找寻宝藏，是一个不错的方法。我觉得，我们没有必要去完全读懂这座宝库的一切，而应该转变观念，这是一座宝库，我们只取我们需要的，也许获取不到最大化的收益，但是我们收获了，至少前进了一小步。这次，我想去探索Spring这座令人称赞的城堡。
我想要了解什么
概念
（1）什么是Spring Ioc?以及为什么我们需要它？
（2）Bean管理的具体机制以及在容器中的生命周期？
实现细节
（1）核心类的层级结构是怎么样的？
（2）在容器初始化时，经历了什么过程？每个过程的具体实现是怎么样的？
（3）对于不同的加载方式（XML文件、注解等）Spring是怎么做到Bean载入的？
（4）在经历过初始化后，Spring是如何管理里面的Bean的？
探索
（一）什么是Ioc/DI?
Ioc（Inversion Of Control）：控制反转。控制反转并非是什么技术，而是一种设计理念与思路。
这里有两个关键词：控制、反转。引申出来的思考：
第一：谁控制谁？
第二：控制如何反转？
了解一件事物，我们需要尝试去理解它被设计出来时为了解决什么问题？
在传统的Java程序设计中，我想我们每一个程序员都习惯于直接new一个对象出来，这里很容易产生对象的依赖。
举例说明：
老婆–依赖–>程序员A
（此处应有图）
一个程序员需要自己主动找老婆（存在依赖），这时候即很容易出现耦合，一旦业务上出现变更（比如看这个老婆不顺眼了要换老婆），就需要程序员自己去主动变更。
这时候会思考的程序员就出现了。程序员天天做加班狗，哪有时间去找老婆，找老婆这种事情太麻烦了，换老婆更麻烦，因此他选择了将创造老婆这种事情交给婚介中心。这时候作为第三方的婚介中心（容器）只要接收程序员的要求（比如要求：白富美），ok，那么第三方的婚介中心就帮程序员组装成一个符合要求的老婆出来。这时候控制权就交给了容器去把控了。这样，我们在实现中不用关注这两个对象（程序员和老婆）的依赖细节，只需要交付给容器去处理就ok了。
老婆 程序员
婚介中心
（此处应有图）
经过上面的举例，我们需要明白两个事情。这也是我们往下分析源码的支点，否则很容易迷失在源码当中。
第一：控制反转是什么？以及它的好处。
第二：容器在这个过程中做了什么事情？
关于第二个问题：
Ioc容器时具有依赖注入功能的容器，Ioc容器负责实例化、定位、配置应用程序中的对象以及建立这些对象的依赖关系。
因此，理解了这一层，我们阅读源码就有思路了。
（1）Spring是如何创建这个容器的？
（2）这个容器的生命周期是怎么样的？
（3）构成容器的要素有什么？
（4）容器有哪些加载Bean的方式？加载过程中，如何实现资源定位？如何实现对象的实例化？
（5）在初始化完成后，Bean的生命周期是怎么样的?
（6）容器是如何处理对象之间的依赖关系的？
等等一系列问题，只要了解了Ioc的概念，便会自然而然的产生。
那么我们闭上眼睛，尝试根据控制反转的思路，假设我们去实现这样一个容器，我们该怎么实现？
很自然地，我们会想：
我们需要一个容器，这个容器有对象的各种信息，这些信息可以以各种方式去存放，最简单的就是放在配置文件，配置文件应该是结构化的，只有结构化的文件，在容器初始化的时候才能更加顺畅的读取。
总结一下，这个容器：
（1）能描述需要创建的对象与对象的关系；
（2）具体的描述方式可以采用xml、properties文件等语义化的配置文件；
（3）描述对象关系的文件需要一定的解析标准。外部的配置文件可以有自己的文件定义。如xml的文件与properties文件的格式明显不同，但是通过一些转换后，将其映射统一的描述定义。
你看，我们就开始进入了Spring Ioc的思路去了。以这种方式去阅读Spring的相关源码会更加不容易迷失在代码中。