001-Spring框架

Spring开发的应用中的对象可以不依赖于Spring的API

反转控制(IOC)最经典的实现

AOP功能，方便进行面向切面的编程

Spring是一个容器，因为它包含并且管理应用对象的生命周期

Spring 中可以使用XML和Java注解组合这些对象

通过配置就可以完成对事务的管理，不需要手动编程

Spring不排斥各种优秀的开源框架，内部提供了对各种优秀框架的支持

架构图

Spring 核心组件

Spring 常用模块

对现有的类结构没有影响

maven项目

普通web项目

applicationContext.xml

使用spring框架创建对象，给属性赋值

在pom中增加依赖

手动添加jar包到项目路径下

BeanFactory-框架基础设施

ApplicationContext

WebApplicationContext 是专门为 Web 应用准备的，它允许从相对于 Web 根目录的路径中装载配置文件完成初始化工作。

从WebApplicationContext 中可以获得 ServletContext 的引用，

整个 Web 应用上下文对象将作为属性放置到 ServletContext 中，以便 Web 应用环境可以访问 Spring 应用上下文。

图解、

图解spring容器

未知目标类型，需要类型强转

容器中只有一个对应类型bean，可以正常

容器中有多个对象类型的bean，异常

唯一匹配

单例模式

Bean的默认作用域

多线程下不安全

DefaultSingletonBeanRegistry类里的singletonObjects哈希表保存了单例对象。

Spring容器可以管理singleton作用域下bean的生命周期，在此作用域下，Spring能够精确地知道bean何时被创建，何时初始化完成，以及何时被销毁

默认情况下是容器初始化的时候创建，但也可设定运行时再初始化bean

原型的/多例的

原型模式每次使用时创建

根据经验，对有状态的bean使用prototype作用域，而对无状态的bean使用singleton作用域。

当容器创建了bean的实例后，bean的实例就交给了客户端的代码管理，

Spring容器将不再跟踪其生命周期,并且不会管理那些被配置成prototype作用域的bean的生命周期。

请求：request

在一次Http请求中，容器会返回该Bean的同一实例。而对不同的Http请求则会产生新的Bean，而且该bean仅在当前Http Request内有效。

请求对应一个bean对象，只在web环境中有效

一次request一个实例

对不同的Http请求则会产生新的Bean，而且该bean仅在当前Http Request内有效,当前Http请求结束，该bean实例也将会被销毁。

<bean id="loginAction" class="com.cnblogs.Login" scope="request"/>

会话：session

在一次Http Session中，容器会返回该Bean的同一实例。而对不同的Session请求则会创建新的实例，该bean实例仅在当前Session内有效。

一次会话对应一个bean对象，只在web环境中有效

在一次Http Session中，容器会返回该Bean的同一实例

而对不同的Session请求则会创建新的实例，该bean实例仅在当前Session内有效。

同Http请求相同，每一次session请求创建新的实例，而不同的实例之间不共享属性，且实例仅在自己的session请求内有效，请求结束，则实例将被销毁。

<bean id="userPreference" class="com.ioc.UserPreference" scope="session"/>

在一个全局的Http Session中，容器会返回该Bean的同一个实例，仅在使用portlet context时有效。

Spring IOC容器可以管理bean的生命周期，Spring允许在bean生命周期内特定的时间点执行指定的任务

1.实例化Bean

2.设置Bean的属性

3.检查Aware相关接口并设置相关依赖

4.检查BeanPostProcessor接口并进行前置处理

5.检查Bean在Spring配置文件中配置的init-method属性并自动调用其配置的初始化方法。

6.检查BeanPostProcessor接口并进行后置处理

7.当Bean不再需要时，会经过清理阶段

8. 最后，配置了destroy-method属性，会自动调用其配置的销毁方法

图解

在配置bean时，通过init-method和destroy-method 属性为bean指定初始化和销毁方法

bean 标签有两个重要的属性（init-method和destroy-method）。

用它们你可以自己定制初始化和注销方法。它们也有相应的注解（@PostConstruct和@PreDestroy）。

<bean id="" class="" init-method="初始化方法" destroy-method="销毁方法">

bean后置处理器允许在调用初始化方法前后对bean进行额外的处理

bean后置处理器对IOC容器里的所有bean实例逐一处理，而非单一实例。其典型应用是：检查bean属性的正确性或根据特定的标准更改bean的属性。

bean后置处理器时需要实现接口： org.springframework.beans.factory.config.BeanPostProcessor

添加bean后置处理器后bean的生命周期变为7个

① 通过构造器或工厂方法创建bean实例

② 为bean的属性设置值和对其他bean的引用

③ 调用bean的初始化方法

④ bean可以使用了

⑤ 当容器关闭时，调用bean的销毁方法

1.进入getBean()方法

2.判断当前bean的作用域是否是单例，

3.新建实例后再将注入属性(populateBean)，并处理回调

扫描类

封装beanDefinition对象  各种信息

放到map

遍历map

验证

得到 class

推断构造方法

得到构造方法

反射 实例化这个对象

后置处理器合并beanDefinition

判断是否允许 循环依赖

提前暴露bean工厂对象

填充属性

执行部分 aware 接口

继续执行部分 aware 接口 生命周期回调方法

完成代理AOP

beanProstprocessor 的前置方法

实例化为bean

放到单例池

销毁

构造器方式注入（通过bean的构造器赋值）

setter方法注入

静态工厂注入（略）

接口注入（略）

实例工厂（略）

p命名空间注入属性值（略）

最好的解决方案是

手动装配

注解实现自动装配

情况

三级缓存

缓存 存放

构造器方式无法解决，只能抛出异常

多例方式无法解决，只能抛出异常

单例模式可以解决

1.首先根据配置文件找到对应的包，读取包中的类，，找到所有含有@bean，@service等注解的类，利用反射解析它们，包括解析构造器，方法，属性等等，然后封装成各种信息类放到container(其实是一个map)里（ioc容器初始化）

2.获取类时，首先从container中查找是否有这个类，如果没有，则报错，如果有，则通过构造器信息将这个类new出来

3.如果这个类含有其他需要注入的属性，则进行依赖注入，如果有则还是从container找对应的解析类，new出对象，并通过之前解析出来的信息类找到setter方法(setter方法注入)，然后用该方法注入对象（这就是依赖注入）。如果其中有一个类container里没找到，则抛出异常

4.如果有嵌套bean的情况，则通过递归解析

5.如果bean的scope是singleton，则会重用这个bean不再重新创建，将这个bean放到一个map里，每次用都先从这个map里面找。如果scope是session，则该bean会放到session里面。

总结：通过解析 xml 文件，获取到bean的属性(id,name,class,scope,属性等等)里面的内容，利用反射原理创建配置文件里类的实例对象，存入到 Spring 的 bean 容器中

是什么？

原理

Spring的生命周期+1

Spring是否可以注入java集合？如何注入？

子主题

子主题

首先创建一个fruit.properties 的资源文件：

然后编写主类代码：

运行结果：Apple。

通俗来讲就是根据给出的类名（字符串方式）来动态地生成对象，

这种编程方式可以让对象在生成时才被决定到底是哪一种对象。

只是在Spring 中要生产的对象都在配置文件中给出定义，目的就是提高灵活性和可维护性。

其中PHP5 的技术书籍中，有时候也被翻译成“映射”。

有关反射的概念和用法，大家应该都很清楚。

比如像Java 中的Hibernate、Spring 框架，

.Net 中NHibernate、Spring.NET 框架

都是把”反射“做为最基本的技术手段。

反射技术其实很早就出现了，但一直被忽略，没有被进一步的利用。

当时的反射编程方式相对于正常的对象生成方式要慢至少得10 倍。

现在的反射技术经过改良优化，已经非常成熟，

反射方式生成对象和通常对象生成方式，速度已经相差不大了，大约为1-2 倍的差距。

我们可以把IOC 容器的工作模式看做是工厂模式的升华，可以把IOC 容器看作是一个工厂

这个工厂里要生产的对象都在配置文件中给出定义，然后利用编程语言提供的反射机制，根据配置文件中给出的类名生成相应的对象。

从实现来看，IOC 是把以前在工厂方法里写死的对象生成代码，改变为由配置文件来定义，

也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。

一些工作量不大的项目或者产品，不太适合使用IOC框架产品。

另外，如果团队成员的知识能力欠缺，对于IOC 框架产品缺乏深入的理解，也不要贸然引入。

最后，特别强调运行效率的项目或者产品，也不太适合引入IOC 框架产品，像WEB2.0 网站就是这种情况。

执行加减乘除运算

在程序执行期间追踪正在发生的活动（记录日志）

此种实现方式分析

手动添加jar包

添加依赖

通过 @Configuration 和 @Bean 这两个注解实现的

封装了各个抽离的功能点的类，Spring AOP就是负责实施切面的框架，它将切面所定义的横切逻辑织入到切面所指定的连接点中

类是对物体特征的抽象，切面就是对横切关注点的抽象

对哪些方法进行拦截，拦截后怎么处理，这些关注点称之为横切关注点。

增强包含了用于添加到目标连接点上的一段执行逻辑，又包含了用于定位连接点的方位信息也就是需要执行的具体操作，

简单理解为切面中的一个方法

通知（advice）

所谓通知指的就是指拦截到连接点之后要执行的代码，

通知分为前置、后置、异常、最终、环绕通知五类。

定义义了“故事”发生的地点。例如某个类或者方法名，Spring中允许我们使用正则来指定

对连接点进行拦截的定义

切入点匹配的执行点称作连接点。

如果说切入点是查询条件，那连接点就是被选中的具体的查询结果（具体的数据记录）。

简单记忆，就是业务类中的各个方法中执行增强的位置。

被拦截到的点，因为Spring只支持方法类型的连接点，所以在Spring中连接点指的就是被拦截到的方法，实际上连接点还可以是字段或者构造器。

AOP框架创建的对象。一个类被AOP织入增强之后，就产生了一个结果类，它是融合了原类和增强逻辑的代理类。

增强逻辑的织入的目标类

代理的目标对象

将切面应用到目标对象并导致代理对象创建的过程

在不修改代码的前提下，引入可以在运行期为类动态地添加一些方法或字段。

切面可以理解为由增强处理和切入点组成，既包含了横切逻辑的定义，也包含了连接点的定义。

面向切面编程主要关心两个问题，即：在什么位置，执行什么功能。

图解

&lt;!-- 组件扫描 --&gt;&lt;context:component-scan base-package=&quot;com.kgc.spring.aspectj&quot;&gt;&lt;/context:component-scan&gt;

&lt;aop:aspectj-autoproxy/&gt;

基于注解使用AspectJ: 主要的作用是当Spring IOC容器侦测到bean配置文件中的&lt;aop:aspectj-autoproxy&gt;元素时，会自动为 与AspectJ切面匹配的bean创建代理

要在Spring中声明AspectJ切面，只需要在IOC容器中将切面声明为bean实例。使用Component

当在Spring IOC容器中初始化AspectJ切面之后，Spring IOC容器就会为那些与 AspectJ切面相匹配的bean创建代理。

在AspectJ注解中，切面只是一个带有@Aspect注解的Java类，它往往要包含很多通知。

通知是标注有某种注解的简单的Java方法

AspectJ支持5种类型的通知注解

语法

举例

含义

重用切入点表达式

通过注解@Order(值)改变优先级

默认int类型最大值 2147483647 值越小优先级越高

Spring 最重要的两个功能，就是依赖注入（DI）和面向切面编程 （AOP）。

AOP 为我们提供了处理问题的全局化视角，使用得当可以极大提高编程效率。

AOP 之所以如此重要，在于它提供了解决问题的新视角。

通过将业务逻辑抽象出切面，功能代码可以切入指定位置，从而消除重复的模板代码。

使用 AOP 有一种掌握全局的快感，发现业务逻辑中的切面颇有一番趣味

Spring Boot 中使用 AOP 与 Spring 中使用 AOP 几乎没有什么区别，只是建议尽量使用 Java 配置，代替 XML 配置。

本节就来演示下 Spring Boot 中使用 AOP 的常见应用场景。

首先需要构建一个 Spring Boot 项目并引入 AOP 依赖，后续场景演示均是在这个项目上实现的。

Spring Boot 版本选择 2.2.5 ，Group 为 com.imooc ， Artifact 为 spring-boot-aop

生成项目后导入 Eclipse 开发环境

引入 Web 项目依赖与 AOP 依赖。

<!-- Web项目依赖 -->
  <dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
  <!-- AOP -->
  <dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-aop</artifactId>
  </dependency>

为了便于后续的演示，依次新建控制类、服务类、数据访问类，并将其放入对应的包中，项目结构如下：

项目结构

各个类代码如下，注意此处仅仅是为了演示 AOP 的使用，并未真实访问数据库，而是直接返回了测试数据。

//商品控制器类 

//商品服务类 

// 商品数据库访问类

如果要记录对控制器接口的访问日志，可以定义一个切面，切入点即为控制器中的接口方法，然后通过前置通知来打印日志。

//日志切面 
@Component
@Aspect // 标注为切面
public class LogAspect {
 private Logger logger = LoggerFactory.getLogger(this.getClass());

 // 切入点表达式，表示切入点为控制器包中的所有方法
 @Pointcut("within(com.imooc.springbootaop.controller..*)")
 public void LogAspect() {
 }

 // 切入点之前执行
 @Before("LogAspect()")
 public void doBefore(JoinPoint joinPoint) {
  logger.info("访问时间：{}--访问接口:{}", new Date(), joinPoint.getSignature());
 }
}

启动项目后，访问控制器中的方法之前会先执行 doBefore 方法。

控制台打印如下：

在研发项目的性能测试阶段，或者项目部署后，希望查看服务层方法执行的时间。

以便精准的了解项目中，哪些服务方法，执行速度慢，后续，可以针对性的进行性能优化。

此时就可以使用 AOP 的环绕通知，监控服务方法的执行时间。

//服务层方法切面 
@Component
@Aspect // 标注为切面
public class ServiceAspect {
 private Logger logger = LoggerFactory.getLogger(this.getClass());

 // 切入点表达式，表示切入点为服务层包中的所有方法
 @Pointcut("within(com.imooc.springbootaop.service..*)")
 public void ServiceAspect() {
 }

 @Around("ServiceAspect()") // 环绕通知
 public Object deAround(ProceedingJoinPoint joinPoint) throws Throwable {
  long startTime = System.currentTimeMillis();// 记录开始时间
  Object result = joinPoint.proceed();
  logger.info("服务层方法:{}--执行时间:{}毫秒", joinPoint.getSignature(), System.currentTimeMillis() - startTime);
  return result;
 }
}

当服务层方法被调用时，控制台输入日志如下：

正常情况下，用户查看页面或进行更新操作时，耗时超过 1.5 秒，就会感觉到明显的迟滞感。

由于前后端交互也需要耗时，按正态分布的话，大部分交互耗时在 0.4秒 左右。

所以在参与的项目中，会对耗时超过 1.1 秒的服务层方法，进行跟踪分析，通过优化 SQL 语句、优化算法、添加缓存等方式，缩短方法执行时间。

上面的数值均为我个人的经验参考值，还要视乎具体的服务器、网络、应用场景来确定合理的监控临界值。

前后端分离的项目结构中，前端通过 Ajax 请求后端接口，此时最好使用统一的返回值格式供前端处理。

此处就可以借助 AOP 来实现正常情况、异常情况返回值的格式统一。

定义返回值类

修改控制层返回值类型

定义切面，处理异常返回值

测试

在执行方法前,判断是否具有权限

权限控制

Controller层的参数校验

信息过滤，页面转发等等功能

统一后端返回值格式

记录访问日志

日志

数学计算器

性能监控后做SQL优化

Spring声明式事务管理配置

事务管理

生活中的代理模式：代购

代码案例：代购香奈儿(Chanel) 香水

实现代理模式，需要走以下几个步骤

代理模式很容易产生错误思维的点

代码案例：代购法国红酒

给目标对象提供一个代理对象，代理对象包含该目标对象，并控制对该目标对象的访问。

静态代理

动态代理

通过代理对象的隔离，可以在对目标对象访问前后增加额外的业务逻辑，实现功能增强。

通过代理对象访问目标对象，可以防止系统大量地直接对目标对象进行不正确地访问，出现不可预测的后果

使用一个代理对象将原始对象包装起来，然后用该代理对象取代原始对象。

任何对原始对象的调用都要通过代理。

代理对象决定是否以及何时将方法调用转到原始对象上。

Spring提供了两种方式来生成代理对象:

CGLib 与 JDK 动态代理之间可以相互补充

具体使用哪种方式生成由AopProxyFactory根据AdvisedSupport对象的配置来决定

默认的策略是如果目标类是接口，则使用JDK动态代理技术，否则使用Cglib来生成代理。

Javassist是什么

Javassist提供了两种级别的API

Javassist特点、优点

Javassist缺点

ASM是什么？

ASM特点、优点

ASM的缺点

两者的使用场景

CGLIB

JDK

如果在dao层，回滚的时候只能回滚到当前方法，但一般我们的service层的方法都是由很多dao层的方法组成的

如果在dao层，commit的次数会过多

“原子”的本意是“不可再分”，事务的原子性表现为一个事务中涉及到的多个操作在逻辑上缺一不可。

事务的原子性要求事务中的所有操作要么都执行，要么都不执行

事务是一个完整的操作。事务的各步操作是不可分的（原子的）；要么都执行，要么都不执行。

“一致”指的是数据的一致，具体是指：所有数据都处于满足业务规则的一致性状态。

一致性原则要求：一个事务中不管涉及到多少个操作，都必须保证事务执行之前数据是正确的，事务执行之后数据仍然是正确的。

如果一个事务在执行的过程中，其中某一个或某几个操作失败了，则必须将其他所有操作撤销，将数据恢复到事务执行之前的状态，这就是回滚。

当事务完成时，数据必须处于一致状态。

在应用程序实际运行过程中，事务往往是并发执行的，所以很有可能有许多事务同时处理相同的数据，

因此每个事务都应该与其他事务隔离开来，防止数据损坏。

隔离性原则要求多个事务在并发执行过程中不会互相干扰。

对数据进行修改的所有并发事务是彼此隔离的，这表明事务必须是独立的，它不应以任何方式依赖于或影响其他事务。

持久性原则要求事务执行完成后，对数据的修改永久的保存下来，不会因各种系统错误或其他意外情况而受到影响。

通常情况下，事务对数据的修改应该被写入到持久化存储器中。

事务完成后，它对数据库的修改被永久保持，事务日志能够保持事务的永久性。

用户通过代码的形式手动控制事务

使用步骤

优缺点

Spring提供对事务的控制管理

大多数情况下声明式事务比编程式事务管理更好：它将事务管理代码从业务方法中分离出来，以声明的方式来实现事务管理。

Spring在不同的事务管理API之上定义了一个抽象层，通过配置的方式使其生效，从而让应用程序开发人员不必了解事务管理API的底层实现细节，就可以使用Spring的事务管理机制。

当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。

事务传播行为用来描述由某一个事务传播行为修饰的方法被嵌套进另一个方法的时候事务如何传播。

例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。

@Transactional注解的propagation属性中定义

数据库系统必须具有隔离并发运行各个事务的能力，使它们不会相互影响，避免各种并发问题。

一个事务与其他事务隔离的程度称为隔离级别。

SQL标准中规定了多种事务隔离级别，不同隔离级别对应不同的干扰程度，隔离级别越高，数据一致性就越好，但并发性越弱。

@Transactional注解的isolation属性中定义

指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。

对事物资源是否执行只读操作

定义了哪些异常会导致事务回滚而哪些不会。

默认情况下，事务只有遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚，也可以用用户自己定义

共享链接

Spring从不同的事务管理API中抽象出了一整套事务管理机制，让事务管理代码从特定的事务技术中独立出来。开发人员通过配置的方式进行事务管理，而不必了解其底层是如何实现的。

Spring的核心事务管理抽象是PlatformTransactionManager。它为事务管理封装了一组独立于技术的方法。无论使用Spring的哪种事务管理策略(编程式或声明式)，事务管理器都是必须的。

事务管理器可以以普通的bean的形式声明在Spring IOC容器中

1) DataSourceTransactionManager：在应用程序中只需要处理一个数据源，而且通过JDBC存取。

2) JtaTransactionManager：在JavaEE应用服务器上用JTA(Java Transaction API)进行事务管理，基本不用

3) HibernateTransactionManager：用Hibernate框架存取数据库，不涉及

（平台）事务管理器

Spring并不直接管理事务，而是提供了多种事务管理器，通过PlatformTransactionManager这个接口，

Spring为各个平台如JDBC、Hibernate等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。

事务定义属性(事务隔离级别、传播行为、超时、只读、回滚规则)

事务运行状态

常用注解

把一个类作为一个IoC 容器，它的某个方法头上如果注册了@Bean，就会作为这个Spring 容器中的Bean。

作用域

用于指定scope 作用域的（用在类上）。

用于指定初始化方法（用在方法上）。

初始化注解。

用于指定销毁方法（用在方法上）

摧毁注解默认单例启动就加载。

表示延迟初始化。

定义Bean 初始化及销毁时的顺序。

自动装配时当出现多个Bean 候选者时，

被注解为@Primary 的Bean将作为首选者，否则将抛出异常。

默认按类型装配，

如果想使用按名称装配，可以结合@Qualifier注解一起使用。

如下： 
@Autowired
@Qualifier("personDaoBean") 存在多个实例配合使用。

默认按名称装配，

当找不到与名称匹配的bean 才会按类型装配。

泛指组件，当组件不好归类的时候，可以使用这个注解进行标注。

用于标注业务层组件。

用于标注控制层组件

用于标注数据访问组件，即DAO 组件。

指的是组件

@Controller，@Repository 和@Service 注解都被@Component 修饰

用于代码中区分表现层， 持久层和业务层的组件 

泛指组件，代码中，当组件不好归类的时候，可以使用@Component注解进行标注。

用于标注数据访问组件，即DAO 组件。

用于标注业务层组件。

用于标注控制层组件

Application Programming Interface

直接被应用开发人员使用

大多数情况下，都是实现方来制定接口并完成对接口的不同实现，调用方仅仅依赖却无权选择不同实现。

Service Provider Interface。

被框架扩展人员使用

如果是调用方来制定接口，实现方来针对接口来实现不同的实现。调用方来选择自己需要的实现方。

定义一组接口，并写出接口的一个或多个实现

定义一组接口

并写出接口的一个或多个实现，假设是

新建文件，并写入对应的内容

在src/main/resources/ 下建立/META-INF/services 目录

新增一个以接口命名的文件(org.foo.demo.IShout 文件)

内容是要应用的实现类，每行一个类，这里是

使用ServiceLoader 来加载配置文件中指定的实现。

代码输出：

看ServiceLoader 类的签名类的成员变量：

应用程序调用ServiceLoader.load 方法

应用程序通过迭代器接口获取对象实例