一、spring
spring概括来说，就是：
- spring是一个开源的框架
- 轻量级、非侵入式的框架
- 支持控制反转（IOC）、面向切面编程（AOP）
- 支持事务的处理，对框架整合的支持
二、spring的结构
首先，需要了解spring的大致框架，有利后面读源码：
可以细分为
| 名称 | 作用 |
|---|---|
| 数据层 | 用于存储数据和数据库相关 |
| web | 网络浏览器相关操作 |
| AOP | 切面编程，提供与业务逻辑无关的代码块 |
| 核心块 | 主要核心代码 |
| 测试 | 如：单例测试 |
具体的详细说明，后面再说，现在有个大概的了解就行了。
三、为什么用Spring
主要是为了解决几个问题
- 类与类之间的调用，new创建，函数调用，初始化导致耦合
- 维护历史代码，不方便修改接口、类的参数个数、类型
- 测试性能
spring的主要核心概念是控制反转( IOC )和面向切面编程（AOP）
3.1控制反转
要了解控制反转( Inversion of Control ), 我觉得有必要先了解软件设计的一个重要思想：依赖倒置原则（Dependency Inversion Principle ）。
什么是依赖倒置原则？ 假设我们设计一辆汽车：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。
这样的设计看起来没问题，但是可维护性却很低。假设设计完工之后，上司却突然说根据市场需求的变动，要我们把车子的轮子设计都改大一码。这下我们就蛋疼了：因为我们是根据轮子的尺寸设计的底盘，轮子的尺寸一改，底盘的设计就得修改；同样因为我们是根据底盘设计的车身，那么车身也得改，同理汽车设计也得改——整个设计几乎都得改！
我们现在换一种思路。我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘， 底盘依赖车身， 车身依赖汽车。
这时候，上司再说要改动轮子的设计，我们就只需要改动轮子的设计，而不需要动底盘，车身，汽车的设计了。
这就是依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。
上层建筑依赖下层建筑——每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎（Tire）类，把它的尺寸变成动态的，而不是一直都是30。我们需要这样改：
3.2优化
（1）将类的实例化变成形参传递
好处：
- 统一管理了类的创建，方便查找逻辑
- 一旦需要重构，减少重构难度
- 有利于单元测试，减少耦合
- 有利于分工合作，各个模块独立开发
坏处：
- 各个类内部，还需要知道谁调用了谁，还有耦合
（2）get，set方法
好处：
- 封闭了直接对属性操作
- 可以直观地查看到，调用属性的位置，是写入还是读取
坏处：
- 各个类内部，还需要知道谁调用了谁，还有耦合
（3）接口
好处：
- 减少耦合
- 规范了实现的方法
坏处：
- 需要重写
3.3
看到这里你应该能理解什么控制反转和依赖注入了。那什么是控制反转容器(IoC Container)呢？其实上面的例子中，对车类进行初始化的那段代码发生的地方，就是控制反转容器。
思想就是：
不直接从父类，一步步到子类地不停构建。而是直接从子类开始倒推，并尽可能减少对父类的依赖
- 减少new对象
- 不需要具体了解父类结构
显然你也应该观察到了，因为采用了依赖注入，在初始化的过程中就不可避免的会写大量的new。这里IoC容器就解决了这个问题。这个容器可以自动对你的代码进行初始化，你只需要维护一个Configuration（可以是xml可以是一段代码），而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。这是引入IoC Container的第一个好处。
IoC Container的第二个好处是：我们在创建实例的时候不需要了解其中的细节。在上面的例子中，我们自己手动创建一个车instance时候，是从底层往上层new的：
这个过程中，我们需要了解整个Car/Framework/Bottom/Tire类构造函数是怎么定义的，才能一步一步new/注入。
而IoC Container在进行这个工作的时候是反过来的，它先从最上层开始往下找依赖关系，到达最底层之后再往上一步一步new（有点像深度优先遍历）：
这里IoC Container可以直接隐藏具体的创建实例的细节，在我们来看它就像一个工厂：
我们就像是工厂的客户。我们只需要向工厂请求一个Car实例，然后它就给我们按照Config创建了一个Car实例。我们完全不用管这个Car实例是怎么一步一步被创建出来。
实际项目中，有的Service Class可能是十年前写的，有几百个类作为它的底层。假设我们新写的一个API需要实例化这个Service，我们总不可能回头去搞清楚这几百个类的构造函数吧？IoC Container的这个特性就很完美的解决了这类问题——因为这个架构要求你在写class的时候需要写相应的Config文件，所以你要初始化很久以前的Service类的时候，前人都已经写好了Config文件，你直接在需要用的地方注入这个Service就可以了。这大大增加了项目的可维护性且降低了开发难度。
这里只是很粗略的讲了一下我自己对IoC和DI的理解。主要的目的是在于最大限度避免晦涩难懂的专业词汇，用尽量简洁，通俗，直观的例子来解释这些概念。如果让大家能有一个类似“哦！原来就是这么个玩意嘛！”的印象，我觉得就OK了。想要深入了解的话，可以上网查阅一些更权威的资料。这里推荐一下 Dependency injection 和 Inversion of Control Containers and the Dependency Injection pattern 这两篇文章，讲的很好很详细。
参考：
https://www.zhihu.com/question/23277575/answer/169698662
Inversion of Control Containers and the Dependency Injection pattern