Spring5源码分析一
第一章
从现实生活理解Spring中
常用的设计模式
一、Spring中常用的设计模式
1、我们通常说的23种经典设计模式可以通过下表一目了然：
| 分类 | 设计模式 |
|---|---|
| 创建型 | 工厂方法模式（FactoryMethod）、抽象工厂模式（AbstractFactory）、建造者模式（Builder）、原型模式（Prototype）、单例模式(Singleton) |
| 结构型 | 适配器模式(Adapter)、桥接模式（Bridge）、组合模式（Composite）、装饰器模式（Decorator）、门面模式（Facade）、享元模式（Flyweight）、代理模式（Proxy） |
| 行为型 | 解释器模式（Interpreter）、模板方法模式（TemplateMethod）、责任链模式（ChainofResponsibility）、命令模式（Command）、迭代器模式（Iterator）、调解者模式（Mediator）、备忘录模式（Memento）、观察者模式（Observer）、状态模式（State）、策略模式（Strategy）、访问者模式（Visitor） |
通常来说，设计模式都是混合使用，不会独立应用。利用穷举法充分理解设计模式的应用场景。在平时的应用中，不是用设计模式去生搬硬套，而是根据具体业务问题需要时借鉴。
2、设计模式在应用中遵循六大原则：
a、开闭原则（OpenClosePrinciple）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现
一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的
效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
b、里氏代换原则（LiskovSubstitutionPrinciple）
里氏代换原则(LiskovSubstitutionPrincipleLSP)
面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对"开-闭"原则的补充。实现"开-闭"原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
c、依赖倒转原则（DependenceInversionPrinciple）
这个是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
d、接口隔离原则（InterfaceSegregationPrinciple）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。
e、迪米特法则（最少知道原则）（DemeterPrinciple）
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
f、合成复用原则（CompositeReusePrinciple）
原则是尽量使用合成/聚合的方式，而不是使用继承。
设计模式之间的关系图
接下来我们只介绍在Spring中常用的设计模式。
1.1、简单工厂模式（Factory）
应用场景：又叫做静态工厂方法（StaticFactoryMethod）模式，但不属于23种设计模式之一。简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。
Spring中的BeanFactory就是简单工厂模式的体现，根据传入一个唯一的标识来获得Bean对象，但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 创建型模式 | 是复杂工厂模式的思维模型 | 批量生产、标准化 |
1.2、工厂方法模式（FactoryMethod）
应用场景：通常由应用程序直接使用new创建新的对象，为了将对象的创建和使用相分离，采用工厂模式,即应用程序将对象的创建及初始化职责交给工厂对象。
一般情况下,应用程序有自己的工厂对象来创建Bean.如果将应用程序自己的工厂对象交给Spring管理,那么Spring
管理的就不是普通的Bean,而是工厂Bean。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 创建型模式 | 对于调用者来说，隐藏了复杂的逻辑处理过程，调用者只关心执行结果。对于工厂来说要对结果负责，保证生产出符合规范的产品。 | 流水线生产 |
1.3、单例模式（Singleton）
应用场景：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
Spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例，这是因为Spring管理的是是任意的Java对象。Spring下默认的Bean均为单例。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 创建型模式 | 保证从系统启动到系统终止，全过程只会产生一个实例。当我们在应用中遇到功能性冲突的时候，需要使用单例模式。 | 配置文件、日历、OC容器 |
常用单例模式写法：饿汉式、懒汉式、注册式、序列化。
1.4、原型模式（Prototype）
应用场景：原型模式就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节。
所谓原型模式，就是Java中的克隆技术，以某个对象为原型。复制出新的对象。显然新的对象具备原型对象的特点，效率高（避免了重新执行构造过程步骤）。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 创建型模式 | 首先有一个原型。数据内容相同，但对象实例不同（完全两个个体）。 | 孙悟空吹毫毛 |
1.5、代理模式（Proxy）
应用场景：为其他对象提供一种代理以控制对这个对象的访问。从结构上来看和Decorator模式类似，但Proxy是控制，更像是一种对功能的限制，而Decorator是增加职责。
Spring的Proxy模式在AOP中有体现，比如JdkDynamicAopProxy和Cglib2AopProxy。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 结构型模式 | 执行者、被代理人对于被代理人来说，这件事情是一定要做的，但是我自己又不想做或者没有时间做。对于代理人而言，需要获取到被代理的人个人资料，只是参与整个过程的某个或几个环节。 | 租房中介、售票黄牛、婚介、经纪人、快递、事务代理、非侵入式日志监听 |
1.6、策略模式（Strategy）
应用场景：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独
立于使用它的客户而变化。
Spring中在实例化对象的时候用到Strategy模式，在SimpleInstantiationStrategy有使用。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 行为型模式 | 最终执行结果是固定的。执行过程和执行逻辑不一样。 | 旅游出行方式 |
1.7、模板方法模式（TemplateMethod）
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。TemplateMethod使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
TemplateMethod模式一般是需要继承的。这里想要探讨另一种对TemplateMethod的理解。Spring中的JdbcTemplate，在用这个类时并不想去继承这个类，因为这个类的方法太多，但是我们还是想用到JdbcTemplate
已有的稳定的、公用的数据库连接，那么我们怎么办呢？我们可以把变化的东西抽出来作为一个参数传入JdbcTemplate的方法中。但是变化的东西是一段代码，而且这段代码会用到JdbcTemplate中的变量。怎么办？那我们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法，我们去实现这个方法，就把变化的东西集中到这里了。然后我们再传入这个回调对象到JdbcTemplate，从而完成了调用。这就是TemplateMethod不需要继承的另一种实现方式。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 行为型模式 | 执行流程固定，但中间有些步骤有细微差别（运行时才确定）。可实现批量生产。 | SpringORM数据模型 |
1.8、委派模式（Delegate）
应用场景：不属于23种设计模式之一，是面向对象设计模式中常用的一种模式。这种模式的原理为类B和类A是两个互相没有任何关系的类，B具有和A一模一样的方法和属性；并且调用B中的方法，属性就是调用A中同名的方法和属性。B好像就是一个受A授权委托的中介。第三方的代码不需要知道A的存在，也不需要和A发生直接的联系，通过B就可以直接使用A的功能，这样既能够使用到A的各种功能，又能够很好的将A保护起来了，一举两得。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 行为型模式 | 要和代理模式区分开来。持有被委托人的引用。不关心过程，只关心结果。 | 经理派发工作任务、Dispatcher |
1.9、适配器模式（Adapter）
SpringAOP模块对BeforeAdvice、AfterAdvice、ThrowsAdvice三种通知类型的支持实际上是借助适配器模式来实现的，这样的好处是使得框架允许用户向框架中加入自己想要支持的任何一种通知类型，上述三种通知类型是SpringAOP模块定义的，它们是AOP联盟定义的Advice的子类型。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 结构型模式 | 注重兼容、转换。适配者与被适配这之间没有层级关系，也没有必然联系。满足has-a的关系。 | 编码解码、一拖三充电头、HDMI转VGA、Type-C转USB |
1.10、装饰器模式（Decorator）
应用场景：在我们的项目中遇到这样一个问题：我们的项目需要连接多个数据库，而且不同的客户在每
次访问中根据需要会去访问不同的数据库。我们以往在Spring和Hibernate框架中总是配置一个数据源，因而SessionFactory的DataSource属性总是指向这个数据源并且恒定不变，所有DAO在使用SessionFactory的时候都是通过这个数据源访问数据库。但是现在，由于项目的需要，我们的DAO在访问SessionFactory的时候都不得不在多个数据源中不断切换，问题就出现了：如何让SessionFactory在执行数据持久化的时候，根据客户的需求能够动态切换不同的数据源？我们能不能在Spring的框架下通过少量修改得到解决？是否有什么设计模式可以利用呢？
首先想到在Spring的ApplicationContext中配置所有的DataSource。这些DataSource可能是各种不同类型的，比如不同的数据库：Oracle、SQLServer、MySQL等，也可能是不同的数据源：比如Apache提供的org.apache.commons.dbcp.BasicDataSource、Spring提供的org.springframework.jndi.JndiObjectFactoryBean等。然后SessionFactory根据客户的每次请求，将DataSource属性设置成不同的数据源，以到达切换数据源的目的。
Spring中用到的包装器模式在类名上有两种表现：一种是类名中含有Wrapper，另一种是类名中含有Decorator。基本上都是动态地给一个对象添加一些额外的职责。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 结构型模式 | 1、注重覆盖、扩展。2、装饰器和被装饰器都实现同一个接口，主要目的是为了扩展之后依旧保留OOP关系（同宗同源）。3、满足is-a的关系。 | IO流包装、数据源包装、简历包装 |
1.11、观察者模式（Observer）
应用场景：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象
都得到通知并被自动更新。
Spring中Observer模式常用的地方是Listener的实现。如ApplicationListener。
| 归类 | 特点 | 穷举 |
|---|---|---|
| 行为型模式 | 一般由两个角色组成：发布者和订阅者（观察者）。观察者通常有一个回调，也可以没有。 | 监听器、日志收集、短信通知、邮件通知 |
1.12、各设计模式对比及编程思想总结
| 设计模式 | 一句话归纳 |
|---|---|
| 工厂模式（Factory） | 只对结果负责，不要三无产品。 |
| 单例模式（Singleton） | 保证独一无二。 |
| 适配器模式（Adapter） | 需要一个转换头（兼容）。 |
| 装饰器模式（Decorator） | 需要包装，但不改变本质(同宗同源)。 |
| 代理模式（Proxy） | 办事要求人，所以找代理。 |
| 观察者模式（Observer） | 完成时通知我。 |
| 策略模式（Strategy） | 我行我素，达到目的就行。 |
| 模板模式（Template） | 流程标准化，原料自己加。 |
| 委派模式（Delegate） | 干活是你的（普通员工），功劳是我的（项目经理）。 |
| 原型模式（Prototype） | 拔一根猴毛，吹出千万个。 |
编程思想总结
| Spring思想 | 应用场景（特点） | 一句话归纳 |
|---|---|---|
| AOP | AspectOrientedProgramming(面向切面编程)找出多个类中有一定规律的代码，开发时拆开，运行时再合并。面向切面编程，即面向规则编程。 | 解耦，专人做专事。 |
| OOP | ObjectOrientedProgramming（面向对象编程）归纳总结生活中一切事物。 | 封装、继承、多态。 |
| BOP | BeanOrientedProgramming（面向Bean编程）面向Bean（普通的java类）设计程序。 | 一切从Bean开始。 |
| IOC | InversionofControl（控制反转）将new对象的动作交给Spring管理，并由Spring保存已创建的对象（IOC容器）。 | 转交控制权（即控制权反转）。 |
| DI/DL | DependencyInjection（依赖注入）或者DependencyLookup（依赖查找）依赖注入、依赖查找，Spring不仅保存自己创建的对象，而且保存对象与对象之间的关系。注入即赋值，主要三种方式构造方法、set方法、直接赋值。 | 先理清关系再赋值。 |
第二章
SpringWeb应用开发篇
二、Spring源码版本命名规则及下载安装
2.1、Spring源码版本命名规则
(1)首先看看某些常见软件的版本号：
LinuxKernel:0.0.1,1.0.0,2.6.32,3.0.18…,若用X.Y.Z表示，则偶数Y表示稳定版本，奇数Y表示开发版本。
Windows:Windows98,Windows2000,Windowsxp,Windows7…,最大的特点是杂乱无章，毫无规律。
SSHClient:0.9.8。
OpenStack:2014.1.3,2015.1.1.dev8。
从上可以看出，不同的软件版本号风格各异，随着系统的规模越大，依赖的软件越多，如果这些软件没有遵循一套规范的命名风格，容易造成DependencyHell。所以当我们发布版本时，版本号的命名需要遵循某种规则，其中SemanticVersioning2.0.0定义了一套简单的规则及条件来约束版本号的配置和增长。本文根据SemanticVersionning2.0.0和SemanticVersioning3.0.0选择性的整理出版本号命名规则指南。
(2)版本号命名规则指南
版本号的格式为X.Y.Z(又称Major.Minor.Patch)，递增的规则为：
X表示主版本号，当API的兼容性变化时，X需递增。
Y表示次版本号，当增加功能时(不影响API的兼容性)，Y需递增。
Z表示修订号，当做Bug修复时(不影响API的兼容性)，Z需递增。
详细的规则如下：
X,Y,Z必须为非负整数，且不得包含前导零，必须按数值递增，如1.9.0->1.10.0->1.11.0
0.Y.Z的版本号表明软件处于初始开发阶段，意味着API可能不稳定；1.0.0表明版本已有稳定的API。
当API的兼容性变化时，X必须递增，Y和Z同时设置为0；当新增功能(不影响API的兼容性)或者API被标记为Deprecated时，Y必须递增，同时Z设置为0；当进行bugfix时，Z必须递增。
先行版本号(Pre-release)意味该版本不稳定，可能存在兼容性问题，其格式为：X.Y.Z.[a-c][正整数]，如1.0.0.a1，1.0.0.b99，1.0.0.c1000。
开发版本号常用于CI-CD，格式为X.Y.Z.dev[正整数]，如1.0.1.dev4。
版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如1.0.0<1.0.1<1.1.1<2.0.0；对于先行版本号和开发版本号，有：1.0.0.a100<1.0.0，2.1.0.dev3<2.1.0；当存在字母时，以ASCII的排序来比较，如1.0.0.a1<1.0.0.b1。
注意：版本一经发布，不得修改其内容，任何修改必须在新版本发布！
一些修饰的词
Snapshot:
版本代表不稳定、尚处于开发中的版本
Alpha:内部版本
Beta:测试版
Demo:演示版
Enhance:增强版
Free:自由版
FullVersion:完整版，即正式版
LTS:长期维护版本
Release:发行版
RC:即将作为正式版发布
Standard:标准版
Ultimate:旗舰版
Upgrade:升级版
Spring版本命名规则
2).Release版本则代表稳定的版本
3).GA版本则代表广泛可用的稳定版(GeneralAvailability)
4).M版本则代表里程碑版(M是Milestone的意思）具有一些全新的功能或是具有里程碑意义的版本。
4).RC版本即将作为正式版发布
2.2、Spring5源码下载
第一步：https://github.com/spring-projects/spring-framework/archive/v5.0.2.RELEASE.zip
第二步：下载gradlehttp://downloads.gradle.org/distributions/gradle-1.6-bin.zip
第三步：解压,配置GRADLE_HOME和Path
第四步：验证gradle-v，环境变量是否正确
第五步：点击gradlew.bat构建项目
三、Spring5概述
Spring是一个开源的轻量级JavaSE（Java标准版本）/JavaEE（Java企业版本）开发应用框架，其目的是用于简化企业级应用程序开发。应用程序是由一组相互协作的对象组成。而在传统应用程序开发中，一个完整的应用是由一组相互协作的对象组成。所以开发一个应用除了要开发业务逻辑之外，最多的是关注如何使这些对象协作来完成所需功能，而且要低耦合、高内聚。业务逻辑开发是不可避免的，那如果有个框架出来帮我们来创建对象及管理这些对象之间的依赖关系。可能有人说了，比如"抽象工厂、工厂方法设计模式"不也可以帮我们创建对象，"生成器模式"帮我们处理对象间的依赖关系，不也能完成这些功能吗？可是这些又需要我们创建另一些工厂类、生成器类，我们又要而外管理这些类，增加了我们的负担，如果能有种通过配置方式来创建对象，管理对象之间依赖关系，我们不需要通过工厂和生成器来创建及管理对象之间的依赖关系，这样我们是不是减少了许多工作，加速了开发，能节省出很多时间来干其他事。Spring框架刚出来时主要就是来完成这个功能。Spring框架除了帮我们管理对象及其依赖关系，还提供像通用日志记录、性能统计、安全控制、异常处理等面向切面的能力，还能帮我管理最头疼的数据库事务，本身提供了一套简单的JDBC访问实现，提供与第三方数据访问框架集成（如Hibernate、JPA），与各种JavaEE技术整合（如JavaMail、任务调度等等），提供一套自己的web层框架SpringMVC、而且还能非常简单的与第三方Web框架集成。从这里我们可以认为Spring是一个超级粘合平台，除了自己提供功能外，还提供粘合其他技术和框架的能力，从而使我们可以更自由的选择到底使用什么技术进行开发。而且不管是JAVASE（C/S架构）应用程序还是JAVAEE（B/S架构）应用程序都可以使用这个平台进行开发。让我们来深入看一下Spring到底能帮我们做些什么？
3.1、一切从Bean开始
1996，Java还只是一个新兴的、初出茅庐的编程语言。人们之所以关注她仅仅是因为，可以使用Java的Applet来开发Web应用。但这些开发者很快就发现这个新兴的语言还能做更多的事情。与之前的所有语言不同，Java让模块化构建复杂的系统成为可能（当时的软件行业虽然在业务上突飞猛进，但当时开发用的是传统的面向过程开发思想，软件的开发效率一直踟蹰不前。伴随着业务复杂性的不断加深，开发也变得越发困难。其实，当时也是面向对象思想飞速发展的时期，她在80年代末被提出，成熟于90年代，现今大多数编程语言都是面向对象的，当然这是后话了）。他们为Applet而来，为组件化而留。这便是最早的Java。
同样在这一年的12月，Sun公司发布了当时还名不见经传但后来人尽皆知的JavaBean1.00-A规范。早期的JavaBean规范针对于Java，她定义了软件组件模型。这个规范规定了一整套编码策略，使简单的Java对象不仅可以被重用，而且还可以轻松地构建更为复杂的应用。尽管JavaBean最初是为重用应用组件而设计的，但当时他们却是主要用作构建窗体控件，毕竟在PC时代那才是主流。但相比于当时正如日中天的Delphi、VB和C++，他看起来还是太简易了，以至于无法胜任任何"实际的"工作。
复杂的应用通常需要诸如事物、安全、分布式等服务的支持，但JavaBean并未直接提供。所以到了1998年3月，Sun发布了EJB1.0规范，该规范把Java组件的设计理念延伸到了服务器端，并提供了许多必须的企业级服务，但他也不再像早期的JavaBean那么简单了。实际上，除了名字，EJBBean已经和JavaBean没有任何关系了。
尽管现实中有很多系统是基于EJB构建的，但EJB从来没有实现它最初的设想：简化开发。EJB的声明式编程模型的确简化了很多基础架构层面的开发，例如事务和安全；但另一方面EJB在部署描述符和配套代码实现等方面变得异常复杂。随着时间的推移，很多开发者对EJB已经不再抱有幻想，开始寻求更简洁的方法。
现在Java组件开发理念重新回归正轨。新的编程技术AOP和DI的不断出现，他们为JavaBean提供了之前EJB才能拥有的强大功能。这些技术为POJO提供了类似EJB的声明式编程模型，而没有引入任何EJB的复杂性。当简单的JavaBean足以胜任时，人们便不愿编写笨重的EJB组件了。
客观地讲，EJB的发展甚至促进了基于POJO的编程模型。引入新的理念，最新的EJB规范相比之前的规范有了前所未有的简化，但对很多开发者而言，这一切的一切都来得太迟了。到了EJB3规范发布时，其他基于POJO的开发架构已经成为事实的标准了，而Spring框架也是在这样的大环境下出现的。
3.2、Spring设计的初衷
Spring是为解决企业级应用开发的复杂性而设计，她可以做很多事。但归根到底支撑Spring的仅仅是少许的基本理念，而所有地这些的基本理念都能可以追溯到一个最根本的使命：简化开发。这是一个郑重的承诺，其实许多框架都声称在某些方面做了简化。
而Spring则立志于全方面的简化Java开发。对此，她主要采取了4个关键策略：
1，基于POJO的轻量级和最小侵入性编程；
2，通过依赖注入和面向接口松耦合；
3，基于切面和惯性进行声明式编程；
4，通过切面和模板减少样板式代码；
而他主要是通过：面向Bean、依赖注入以及面向切面这三种方式来达成的。
3.3、BOP编程伊始
Spring是面向Bean的编程（BeanOrientedProgramming,BOP），Bean在Spring中才是真正的主角。Bean在Spring中作用就像Object对OOP的意义一样，Spring中没有Bean也就没有Spring存在的意义。Spring提供了IOC容器通过配置文件或者注解的方式来管理对象之间的依赖关系。
控制反转(其中最常见的方式叫做依赖注入（DependencyInjection，DI），还有一种方式叫"依赖查找"（DependencyLookup，DL），她在C++、Java、PHP以及.NET中都运用。在最早的Spring中是包含有依赖注入方法和依赖查询的，但因为依赖查询使用频率过低，不久就被Spring移除了，所以在Spring中控制反转也被称作依赖注入)，她的基本概念是：不创建对象，但是描述创建它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。容器（在Spring框架中是IOC容器）负责将这些联系在一起。
在典型的IOC场景中，容器创建了所有对象，并设置必要的属性将它们连接在一起，决定什么时间调用方法。
3.4、依赖注入的基本概念
Spring设计的核心org.springframework.beans包（架构核心是org.springframework.core包），它的设计目标是与JavaBean组件一起使用。这个包通常不是由用户直接使用，而是由服务器将其用作其他多数功能的底层中介。下一个最高级抽象是BeanFactory接口，它是工厂设计模式的实现，允许通过名称创建和检索对象。BeanFactory也可以管理对象之间的关系。
BeanFactory支持两个对象模型。
1，单例：模型提供了具有特定名称的对象的共享实例，可以在查询时对其进行检索。Singleton是默认的也是最常用的对象模型。对于无状态服务对象很理想。
2，原型：模型确保每次检索都会创建单独的对象。在每个用户都需要自己的对象时，原型模型最适合。
Bean工厂的概念是Spring作为IOC容器的基础。IOC则将处理事情的责任从应用程序代码转移到框架。
3.5、AOP编程理念
面向切面编程，即AOP，是一种编程思想，它允许程序员对横切关注点或横切典型的职责分界线的行为（例如日志和事务管理）进行模块化。AOP的核心构造是方面（切面），它将那些影响多个类的行为封装到可重用的模块中。
AOP和IOC是补充性的技术，它们都运用模块化方式解决企业应用程序开发中的复杂问题。在典型的面向对象开发方式中，可能要将日志记录语句放在所有方法和Java类中才能实现日志功能。在AOP方式中，可以反过来将日志服务模块化，并以声明的方式将它们应用到需要日志的组件上。当然，优势就是Java类不需要知道日志服务的存在，也不需要考虑相关的代码。所以，用SpringAOP编写的应用程序代码是松散耦合的。
AOP的功能完全集成到了Spring事务管理、日志和其他各种特性的上下文中。
AOP编程的常用场景有：Authentication权限认证、Logging日志、TransctionsManager事务、LazyLoading懒加载、ContextProcess上下文处理、ErrorHandler错误跟踪（异常捕获机制）、Cache缓存。
3.6、Spring5系统架构
Spring总共大约有20个模块，由1300多个不同的文件构成。而这些组件被分别整合在核心容器（CoreContainer）、AOP（AspectOrientedProgramming）和设备支持（Instrmentation）、数据访问及集成（DataAccess/Integeration）、Web、报文发送（Messaging）、Test，6个模块集合中。以下是Spring5的模块结构图：
Spring5官网的说明：
组成Spring框架的每个模块集合或者模块都可以单独存在，也可以一个或多个模块联合实现。每个模块的组成和功能如下：
1.核心容器：由spring-beans、spring-core、spring-context和spring-expression（SpringExpressionLanguage,SpEL）4个模块组成。
spring-beans和spring-core模块是Spring框架的核心模块，包含了控制反转（InversionofControl,IOC）和依赖注入（DependencyInjection,DI）。BeanFactory接口是Spring框架中的核心接口，它是工厂模式的具体实现。BeanFactory使用控制反转对应用程序的配置和依赖性规范与实际的应用程序代码进行了分离。但BeanFactory容器实例化后并不会自动实例化Bean，只有当Bean被使用时BeanFactory容器才会对该Bean进行实例化与依赖关系的装配。
spring-context模块构架于核心模块之上，他扩展了BeanFactory，为她添加了Bean生命周期控制、框架事件体系以及资源加载透明化等功能。此外该模块还提供了许多企业级支持，如邮件访问、远程访问、任务调度等，ApplicationContext是该模块的核心接口，她是BeanFactory的超类，与BeanFactory不同，ApplicationContext容器实例化后会自动对所有的单实例Bean进行实例化与依赖关系的装配，使之处于待用状态。
spring-expression模块是统一表达式语言（EL）的扩展模块，可以查询、管理运行中的对象，同时也方便的可以调用对象方法、操作数组、集合等。它的语法类似于传统EL，但提供了额外的功能，最出色的要数函数调用和简单字符串的模板函数。这种语言的特性是基于Spring产品的需求而设计，他可以非常方便地同SpringIOC进行交互。
2.AOP和设备支持：由spring-aop、spring-aspects和spring-instrument3个模块组成。
spring-aop是Spring的另一个核心模块，是AOP主要的实现模块。作为继OOP后，对程序员影响最大的编程思想之一，AOP极大地开拓了人们对于编程的思路。在Spring中，他是以JVM的动态代理技术为基础，然后设计出了一系列的AOP横切实现，比如前置通知、返回通知、异常通知等，同时，Pointcut接口来匹配切入点，可以使用现有的切入点来设计横切面，也可以扩展相关方法根据需求进行切入。
spring-aspects模块集成自AspectJ框架，主要是为SpringAOP提供多种AOP实现方法。
spring-instrument模块是基于JAVASE中的"java.lang.instrument"进行设计的，应该算是AOP的一个支援模块，主要作用是在JVM启用时，生成一个代理类，程序员通过代理类在运行时修改类的字节，从而改变一个类的功能，实现AOP的功能。在分类里，我把他分在了AOP模块下，在Spring官方文档里对这个地方也有点含糊不清，这里是纯个人观点。
3.数据访问及集成：由spring-jdbc、spring-tx、spring-orm、spring-jms和spring-oxm5个模块组成。
spring-jdbc模块是Spring提供的JDBC抽象框架的主要实现模块，用于简化SpringJDBC。主要是提供JDBC模板方式、关系数据库对象化方式、SimpleJdbc方式、事务管理来简化JDBC编程，主要实现类是JdbcTemplate、SimpleJdbcTemplate以及NamedParameterJdbcTemplate。
spring-tx模块是SpringJDBC事务控制实现模块。使用Spring框架，它对事务做了很好的封装，通过它的AOP配置，可以灵活的配置在任何一层；但是在很多的需求和应用，直接使用JDBC事务控制还是有其优势的。其实，事务是以业务逻辑为基础的；一个完整的业务应该对应业务层里的一个方法；如果业务操作失败，则整个事务回滚；所以，事务控制是绝对应该放在业务层的；但是，持久层的设计则应该遵循一个很重要的原则：保证操作的原子性，即持久层里的每个方法都应该是不可以分割的。所以，在使用SpringJDBC事务控制时，应该注意其特殊性。
spring-orm模块是ORM框架支持模块，主要集成Hibernate,JavaPersistenceAPI(JPA)和JavaDataObjects(JDO)用于资源管理、数据访问对象(DAO)的实现和事务策略。
spring-jms模块（JavaMessagingService）能够发送和接受信息，自SpringFramework4.1以后，他还提供了对spring-messaging模块的支撑。
spring-oxm模块主要提供一个抽象层以支撑OXM（OXM是Object-to-XML-Mapping的缩写，它是一个O/M-mapper，将java对象映射成XML数据，或者将XML数据映射成java对象），例如：JAXB,Castor,XMLBeans,JiBX和XStream等。
4.Web：由spring-web、spring-webmvc、spring-websocket和spring-webflux4个模块组成。
spring-web模块为Spring提供了最基础Web支持，主要建立于核心容器之上，通过Servlet或者Listeners来初始化IOC容器，也包含一些与Web相关的支持。
spring-webmvc模块众所周知是一个的Web-Servlet模块，实现了SpringMVC（model-view-Controller）的Web应用。
spring-websocket模块主要是与Web前端的全双工通讯的协议。（资料缺乏，这是个人理解）
spring-webflux是一个新的非堵塞函数式ReactiveWeb框架，可以用来建立异步的，非阻塞，事件驱动的服务，并且扩展性非常好。
5.报文发送：即spring-messaging模块。
spring-messaging是从Spring4开始新加入的一个模块，主要职责是为Spring框架集成一些基础的报文传送应用。
6.Test：即spring-test模块。
spring-test模块主要为测试提供支持的，毕竟在不需要发布（程序）到你的应用服务器或者连接到其他企业设施的情况下能够执行一些集成测试或者其他测试对于任何企业都是非常重要的。
3.7、Spirng各模块之间的依赖关系
该图是Spring5的包结构，可以从中清楚看出Spring各个模块之间的依赖关系。
如果你想加入Spring源码的学习，笔者的建议是从spring-core入手，其次是spring-beans和spring-aop，随后是spring-context，再其次是spring-tx和spring-orm，最后是spring-web和其他部分。