深入理解Spring IOC和AOP
文章目录
- 1. 什么是 Spring 框架?
-
- 1.1Spring简介
- 1.2Spring的好处
- 1.3Spring体系结构
- 2.理解Spring IoC
-
- 2.1IoC简介
- 2.2IoC的好处
- 2.3依赖注入和控制反转
-
- 依赖注入详解
- 依赖注入的三种方式
- 2.4Spring IoC的初始化过程
- 2.5Spring IoC源码阅读
- 2.6Spring IOC的使用
- 3.理解Spring AOP
-
- 3.1AOP简介
- 3.2为什么需要 AOP
- 3.3AOP 实现分类
- 3.4AOP 术语
- 3.5Spring AOP
- AOP，Spring AOP 和 AspectJ AOP
-
- AOP
- 对比Spring AOP 和 AspectJ AOP
-
- Spring AOP：
1. 什么是 Spring 框架?
1.1Spring简介
Spring 是一种轻量级开发框架，旨在提高开发人员的开发效率以及系统的可维护性。Spring 官网：https://spring.io/。
我们一般说 Spring 框架指的都是 Spring Framework，它是很多模块的集合，使用这些模块可以很方便地协助我们进行开发。这些模块是：核心容器、数据访问/集成,、Web、AOP（面向切面编程）、工具、消息和测试模块。比如：Core Container 中的 Core 组件是Spring 所有组件的核心，Beans 组件和 Context 组件是实现IoC和依赖注入的基础，AOP组件用来实现面向切面编程。
简单来说，Spring是一个轻量级的==控制反转（IoC）和面向切面（AOP）==的容器框架。
Spring 官网列出的 Spring 的 6 个特征:
- 核心技术 ：依赖注入(DI)，AOP，事件(events)，资源，i18n，验证，数据绑定，类型转换，SpEL。
- 测试 ：模拟对象，TestContext框架，Spring MVC 测试，WebTestClient。
- 数据访问 ：事务，DAO支持，JDBC，ORM，编组XML。
- Web支持 : Spring MVC和Spring WebFlux Web框架。
- 集成 ：远程处理，JMS，JCA，JMX，电子邮件，任务，调度，缓存。
- 语言 ：Kotlin，Groovy，动态语言。
1.2Spring的好处
①方便解耦，简化开发:
- Spring就是一个大工厂，专门负责生成Bean，可以将所有对象创建和依赖关系维护由Spring管理。
②AOP编程的支持
- Spring提供面向切面编程，可以方便的实现对程序进行权限拦截、运行监控等功能
③声明式事务的支持:
- 只需要通过配置就可以完成对事务的管理，而无需手动编程
④方便程序的测试:
- Spring对Junit4支持，可以通过注解方便的测试Spring程序
⑤方便集成各种优秀框架:
- Spring不排斥各种优秀的开源框架，其内部提供了对各种优秀框架（如：Struts、Hibernate、MyBatis、Quartz等）的支持
⑥降低JavaEE API的使用难度 Spring:
- 对JavaEE开发中一些难用的API（JDBC、JavaMail、远程调webservice用等），都提供了封装，使这些API应用难度大大降低
1.3Spring体系结构
2.理解Spring IoC
2.1IoC简介
IoC（Inverse of Control:控制反转）是一种设计思想，就是 将原本在程序中手动创建对象的控制权，交由Spring框架来管理。 IoC 在其他语言中也有应用，并非 Spring 特有。 IoC 容器是 Spring 用来实现 IoC 的载体， IoC 容器实际上就是个Map（key，value）,Map 中存放的是各种对象。
如何理解好IoC呢？理解好IoC的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”，那我们来深入分析一下：
-
谁控制谁，控制什么： 传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由IoC容器来控制对 象的创建；谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。
-
为何是反转，哪些方面反转了： 有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。
图例说明：
传统程序设计都是主动去创建相关对象然后再组合起来：
当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了，如图所示:
其实IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。
IoC很好的体现了面向对象设计法则之一—— 好莱坞法则：“别找我们，我们找你”；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。
2.2IoC的好处
将对象之间的相互依赖关系交给 IoC 容器来管理，并由 IoC容器完成对象的注入。这样可以很大程度上简化应用的开发，把应用从复杂的依赖关系中解放出来。 IoC 容器就像是一个工厂一样，当我们需要创建一个对象的时候，只需要配置好配置文件/注解即可，完全不用考虑对象是如何被创建出来的。 在实际项目中一个 Service 类可能有几百甚至上千个类作为它的底层，假如我们需要实例化这个 Service，你可能要每次都要搞清这个 Service 所有底层类的构造函数，这可能会把人逼疯。如果利用 IoC 的话，你只需要配置好，然后在需要的地方引用就行了，这大大增加了项目的可维护性且降低了开发难度。
Spring 时代我们一般通过 XML 文件来配置 Bean，后来开发人员觉得 XML 文件来配置不太好，于是 SpringBoot 注解配置就慢慢开始流行起来。
IoC的思想最核心的地方在于，资源不由使用资源的双方管理，而由不使用资源的第三方管理，这可以带来很多好处。第一，资源集中管理，实现资源的可配置和易管理。第二，降低了使用资源双方的依赖程度，也就是我们说的耦合度。
也就是说，甲方要达成某种目的不需要直接依赖乙方，它只需要达到的目的告诉第三方机构就可以了，比如甲方需要一双袜子，而乙方它卖一双袜子，它要把袜子卖出去，并不需要自己去直接找到一个卖家来完成袜子的卖出。它也只需要找第三方，告诉别人我要卖一双袜子。这下好了，甲乙双方进行交易活动，都不需要自己直接去找卖家，相当于程序内部开放接口，卖家由第三方作为参数传入。甲乙互相不依赖，而且只有在进行交易活动的时候，甲才和乙产生联系。反之亦然。这样做什么好处么呢，甲乙可以在对方不真实存在的情况下独立存在，而且保证不交易时候无联系，想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面，避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系，而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。
这就是IoC的核心思想。生活中这种例子比比皆是，支付宝在整个淘宝体系里就是庞大的IoC容器，交易双方之外的第三方，提供可靠性可依赖可灵活变更交易方的资源管理中心。另外人事代理也是，雇佣机构和个人之外的第三方。
2.3依赖注入和控制反转
在以上的描述中，诞生了两个专业词汇，依赖注入和控制反转
IoC(Inversion of Control)：控制反转。
DI(Dependency Injection)：依赖注入。
控制反转是目的，依赖注入是实现控制反转的手段。
所谓的依赖注入，则是，甲方开放接口，在它需要的时候，能够讲乙方传递进来(注入)
所谓的控制反转，甲乙双方不相互依赖，交易活动的进行不依赖于甲乙任何一方，整个活动的进行由第三方负责管理。
控制反转是一种面向对象的思想，它是一种宽泛的概念，只要一个类将对它内部状态的控制权交由其他机制去完成即为『控制反转』。控制反转是为了降低类与类之间的耦合度。而Spring采用依赖注入这一具体的手段来达到控制反转的目的。
依赖注入详解
DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。**依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。**通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。
理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：
●谁依赖于谁：当然是应用程序依赖于IoC容器；
●为什么需要依赖： 应用程序需要IoC容器来提供对象需要的外部资源；
●谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；
●注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。
IoC和DI由什么关系呢？其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。
一个类内部往往有很多成员变量，如：
class A {
private Person chaimm;
}
上述代码在面向对象中可以描述为：
- A类和Person类之间存在依赖关系；
- A依赖于Person；
- A为依赖类；
- Perosn为被依赖类；
通常情况下，依赖类需要自己去创建并维护被依赖类的对象，如：
class A {
private Person chaimm = new Person();
}
但依赖注入的做法是：将被依赖对象的创建与维护工作交由专门的机构，而依赖类中只需要声明所需要的成员变量。
也就是说，依赖类原本需要主动去获取对象，但采用依赖注入后对象由第三方机构提供，自己仅需声明需要什么对象即可。
这样做的目的就是为了降低两个类之间的耦合程度。
PS：在Spring中，那个创建、管理对象的机构就称为『IoC Service Provider』。
但此时还没体现出依赖注入能降低耦合度这一点，只有当依赖注入与面向接口编程结合起来，才能真正发挥依赖注入的优势。接下来先介绍一下『面向接口编程』。
什么是面向接口编程？
一个类依赖其他类的目的是为了获取其他类所提供的服务，可能这种服务有多种实现，我们可能需要根据不同的场景使用不同的实现。此时，我们可以使用多态，将同一功能的多种实现抽象出一个接口，并为所有实现定义一套相同的API。在使用时声明接口类型的变量而非实现类的变量，并将实现类的对象赋给接口变量，最后用接口变量去调用实现类的服务，如：
class A {
private Super super = new SuperImpl1();
public static void main ( String[] args ) {
// 使用Super提供的服务
super.method1();
super.method2();
super.method3();
}
}
这样，当想使用SuperImpl2提供的功能时，只需替换Super的实现类，其他地方不做任何变化：
private Super super = new SuperImpl2();
上述过程就是面向接口编程的思想：若某一类服务有多种不同的实现，我们需要抽象出一个接口，并在接口中定义一套API。在使用时声明接口类型变量，并用实现类的对象赋值。接下来通过接口类型的变量调用服务即可。当功能发生变化时，仅需替换实现类即可。
在面向接口编程的基础上使用依赖注入的好处
上述过程如果要换一种实现，就必须要修改A类的代码，再重新编译。而使用了依赖注入后，由于依赖类不需要自己创建维护被依赖对象，该过程由IoC Service Provider完成。因此，当需要替换实现类时，只需在IoC Service Provider中修改，被依赖类、依赖类都不会受到影响，此时这两个类是松耦合的。
依赖注入的三种方式
参考博客：推荐基于Lombok的Spring注入方式（基于构造器注入）及快速获取Spring容器中管理的对象
2.4Spring IoC的初始化过程
2.5Spring IoC源码阅读
参考文章：https://javadoop.com/post/spring-IoC
2.6Spring IOC的使用
可参考：
- Spring IOC 一——容器装配Bean的简单使用
- SpringIOC 二—— 容器 和 Bean的深入理解
3.理解Spring AOP
3.1AOP简介
AOP(Aspect-Oriented Programming:面向切面编程)能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任（例如事务处理、日志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。
AOP 是一种编程思想，是面向对象编程（OOP）的一种补充。面向对象编程将程序抽象成各个层次的对象，而面向切面编程是将程序抽象成各个切面。
3.2为什么需要 AOP
想象下面的场景，开发中在多个模块间有某段重复的代码，我们通常是怎么处理的？显然，没有人会靠“复制粘贴”吧。在传统的面向过程编程中，我们也会将这段代码，抽象成一个方法，然后在需要的地方分别调用这个方法，这样当这段代码需要修改时，我们只需要改变这个方法就可以了。然而需求总是变化的，有一天，新增了一个需求，需要再多出做修改，我们需要再抽象出一个方法，然后再在需要的地方分别调用这个方法，又或者我们不需要这个方法了，我们还是得删除掉每一处调用该方法的地方。实际上涉及到多个地方具有相同的修改的问题我们都可以通过 AOP 来解决。
3.3AOP 实现分类
AOP 要达到的效果是，保证开发者不修改源代码的前提下，去为系统中的业务组件添加某种通用功能。AOP 的本质是由 AOP 框架修改业务组件的多个方法的源代码，看到这其实应该明白了，AOP 其实就是代理模式的典型应用。
按照 AOP 框架修改源代码的时机，可以将其分为两类：
- 静态 AOP 实现， AOP 框架在编译阶段对程序源代码进行修改，生成了静态的 AOP 代理类（生成的 *.class 文件已经被改掉了，需要使用特定的编译器），比如 AspectJ。
- 动态 AOP 实现， AOP 框架在运行阶段对动态生成代理对象（在内存中以 JDK 动态代理，或 CGlib 动态地生成 AOP 代理类），如 SpringAOP。
下面给出常用 AOP 实现比较：
关于动态代理可参考我的另一篇博客：实例理解JDK动态代理和Cglib动态代理及其区别
3.4AOP 术语
AOP 领域中的特性术语：
- 通知（Advice）: AOP 框架中的增强处理。通知描述了切面何时执行以及如何执行增强处理。
- 连接点（join point）: 连接点表示应用执行过程中能够插入切面的一个点，这个点可以是方法的调用、异常的抛出。在 Spring AOP 中，连接点总是方法的调用。
- 切点（PointCut）: 可以插入增强处理的连接点。
- 切面（Aspect）: 切面是通知和切点的结合。
- 引入（Introduction）：引入允许我们向现有的类添加新的方法或者属性。
- 织入（Weaving）: 将增强处理添加到目标对象中，并创建一个被增强的对象，这个过程就是织入。
3.5Spring AOP
Spring AOP就是基于动态代理的，如果要代理的对象，实现了某个接口，那么Spring AOP会使用JDK Proxy，去创建代理对象，而对于没有实现接口的对象，就无法使用 JDK Proxy 去进行代理了，这时候Spring AOP会使用Cglib ，这时候Spring AOP会使用 Cglib 生成一个被代理对象的子类来作为代理，如下图所示：
当然也可以使用 AspectJ ,Spring AOP 已经集成了AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。
使用 AOP 之后我们可以把一些通用功能抽象出来，在需要用到的地方直接使用即可，这样大大简化了代码量。我们需要增加新功能时也方便，这样也提高了系统扩展性。日志功能、事务管理等等场景都用到了 AOP 。
Spring AOP的使用，可参考：Spring AOP——Spring 中面向切面编程
AOP，Spring AOP 和 AspectJ AOP
AOP
AOP 要实现的是在我们原来写的代码的基础上，进行一定的包装，如在方法执行前、方法返回后、方法抛出异常后等地方进行一定的拦截处理或者叫增强处理。
AOP 的实现并不是因为 Java 提供了什么神奇的钩子，可以把方法的几个生命周期告诉我们，而是我们要实现一个代理，实际运行的实例其实是生成的代理类的实例。
对比Spring AOP 和 AspectJ AOP
Spring AOP 属于运行时增强，而 AspectJ 是编译时增强。 Spring AOP 基于代理(Proxying)，而 AspectJ 基于字节码操作(Bytecode Manipulation)。
Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。AspectJ 相比于 Spring AOP 功能更加强大，但是 Spring AOP 相对来说更简单，
如果我们的切面比较少，那么两者性能差异不大。但是，当切面太多的话，最好选择 AspectJ ，它比Spring AOP 快很多。
Spring AOP：
- 它基于动态代理来实现。默认地，如果使用接口的，用 JDK 提供的动态代理实现，如果没有接口，使用 CGLIB 实现。大家一定要明白背后的意思，包括什么时候会不用 JDK 提供的动态代理，而用 CGLIB 实现。
- Spring 3.2 以后，spring-core 直接就把 CGLIB 和 ASM 的源码包括进来了，这也是为什么我们不需要显式引入这两个依赖
- Spring 的 IOC 容器和 AOP 都很重要，Spring AOP 需要依赖于 IOC 容器来管理。
- 如果你是 web 开发者，有些时候，你可能需要的是一个 Filter 或一个 Interceptor，而不一定是 AOP。
- Spring AOP 只能作用于 Spring 容器中的 Bean，它是使用纯粹的 Java 代码实现的，只能作用于 bean 的方法。
- Spring 提供了 AspectJ 的支持，一般来说我们用纯的 Spring AOP 就够了。
- 很多人会对比 Spring AOP 和 AspectJ 的性能，Spring AOP 是基于代理实现的，在容器启动的时候需要生成代理实例，在方法调用上也会增加栈的深度，使得 Spring AOP 的性能不如 AspectJ 那么好。
AspectJ：
-
AspectJ 出身也是名门，来自于 Eclipse 基金会，link：https://www.eclipse.org/aspectj
-
属于静态织入，它是通过修改代码来实现的，它的织入时机可以是：
- Compile-time weaving：编译期织入，如类 A 使用 AspectJ 添加了一个属性，类 B 引用了它，这个场景就需要编译期的时候就进行织入，否则没法编译类 B。
- Post-compile weaving：也就是已经生成了 .class 文件，或已经打成 jar 包了，这种情况我们需要增强处理的话，就要用到编译后织入。
- Load-time weaving：指的是在加载类的时候进行织入，要实现这个时期的织入，有几种常见的方法。1、自定义类加载器来干这个，这个应该是最容易想到的办法，在被织入类加载到 JVM 前去对它进行加载，这样就可以在加载的时候定义行为了。2、在 JVM 启动的时候指定 AspectJ 提供的 agent：
-javaagent:xxx/xxx/aspectjweaver.jar。
-
AspectJ 能干很多 Spring AOP 干不了的事情，它是 AOP 编程的完全解决方案。Spring AOP 致力于解决的是企业级开发中最普遍的 AOP 需求（方法织入），而不是力求成为一个像 AspectJ 一样的 AOP 编程完全解决方案。
-
因为 AspectJ 在实际代码运行前完成了织入，所以大家会说它生成的类是没有额外运行时开销的。
关于AspectJ的使用，可参考：AspectJ 使用介绍
参考：
- Spring IoC有什么好处呢？
- 谈谈对Spring IOC的理解
- Spring IOC 一——容器装配Bean的简单使用
- SpringIOC 二—— 容器 和 Bean的深入理解
- Spring AOP 使用介绍，从前世到今生
- Spring AOP——Spring 中面向切面编程
- Spring AOP 源码解析
- JavaGuide Spring常见问题总结
- AspectJ 使用介绍
- 实例理解JDK动态代理和Cglib动态代理及其区别
- 推荐基于Lombok的Spring注入方式（基于构造器注入）及快速获取Spring容器中管理的对象