一、具体描述
- 容器: Spring 是一个容器, 因为它包含并且管理应用对象的生命周期;
- 轻量级:Spring 是非侵入性的 — 基于 Spring 开发的应用中的对象可以不依赖于 Spring 的 API;
- 依赖注入 (DI — dependency injection、IOC) DI和IOC其实是一回事;
- 面向切面编程 (AOP — Aspect Oriented Programming)
- 框架: Spring 实现了使用简单的组件配置组合成一个复杂的应用。 在 Spring 中可以使用 XML 和 Java 注解组合这些对象
- 一站式:在 IOC 和 AOP 的基础上可以整合各种企业应用的开源框架和优秀的第三方类库
- Spring 上下文/环境,指Spring各种组件组合在一起的工作状态;
1、源码解析
1 | AnnotationConfigApplicationContext |
二、Spring 容器
- 1、在 Spring IOC 容器读取 Bean 配置创建 Bean 实例之前, 必须对它进行实例化。
- 只有在容器实例化后, 才可以从 IOC 容器里获取 Bean 实例并使用。
- 2、Spring 提供了两种类型的 IOC 容器实现。
- BeanFactory: IOC 容器的基本实现。
- ApplicationContext: 提供了更多的高级特性。
是 BeanFactory 的子接口( getBean() 方法所在位置)。
- ClassPathXmlApplicationContext 是 ApplicationContext 实现类,从类路径下加载配置文件。
- 3、BeanFactory 是 Spring 框架的基础设施,面向 Spring 本身;
- ApplicationContext 面向使用 Spring 框架的开发者,几乎所有的应用场合都直接使用
- ApplicationContext 而非底层的 BeanFactory无论使用何种方式, 配置文件时相同的。
1、 IOC(DI)
IOC 控制反转(Inversion of Control)
- 其思想是反转资源获取的方向。传统的资源查找方式要求组件向容器发起请求查找资源。作为回应,容器适时的返回资源。而应用了 IOC 之后, 则是容器主动地将资源推送给它所管理的组件,组件所要做的仅是选择一种合适的方式来接受资源。这种行为也被称为查找的被动形式。
DI 依赖注入(Dependency Injection)依赖容器把资源注入 — IOC 的另一种表述方式:
- 即组件以一些预先定义好的方式(例如: setter 方法)接受来自如容器的资源注入。相对于 IOC 而言,这种表述更直接。
Spring核心 jar 包
- commons-logging-1.x.x.jar
- spring-core-4.0.0.RELEASE.jar
- spring-context-4.0.0.RELEASE.jar
- spring-expression-4.0.0.RELEASE.jar
- spring-beans-4.0.0.RELEASE.jar
配置 bean
1、配置形式: 基于 XML 文件的方式; 基于 注解 的方式;
2、Bean 的配置方式:通过全类名(反射)、通过FactoryBean(静态工厂方法 & 实例工厂方法)
3、通过 IOC 容器 BeanFactory & ApplicationContext
4、依赖注入的方式: 属性注入; 构造器注入。
1 | <bean id="helloWorld" class="Spring1.HelloWorld"> |
applicationContext.xml Spring配置文件
id: Bean的名称
- 在IOC容器中必须是唯一的。
- 若id没有指定,Spring自动将权限定性类名作为Bean的名字。
- id可以指定多个名字,名字之间可用 逗号、分号、或空格分隔。
class: Bean的全类名,通过反射的机制创建Bean的实例,需要默认构造器。获取容器前会初始化类,调用默认构造器。
property: name属性 –> setXxx方法对应注入。value –> 对变量注入的值。
2、XML 配置里的 Bean 自动装配
Spring IOC 容器可以自动装配 Bean。需要做的仅仅是在
byType(根据类型自动装配): 若 IOC 容器中有多个与目标 Bean 类型一致的 Bean。在这种情况, Spring将无法判定哪个 Bean 最合适该属性, 所以不能执行自动装配。
byName(根据名称自动装配): 必须将目标Bean的名称和属性名设置的完全相同。constructor(通过构造器自动装配):当 Bean 中存在多个构造器时, 此种自动装配方式将会很复杂。 不推荐使用。
3、Bean 的作用域
在 Spring 中, 可以在 <bean> 元素的 scope 属性里设置 Bean 的作用域。
默认情况下为singleton
, Spring 只为每个在 IOC 容器里声明的 Bean 创建唯一实例
。整个 IOC 容器范围内都能共享该实例;所有后续的 getBean()调用和Bean引用都将返回这个的Bean该作用域被称为 singleton
,它是所有Bean的默认作用域。
- scope 属性若为 prototype 多例 每次 getBean() 获取Bean都创建一个新实例。
- scope 属性若为 request 每次HTTP请求都会创建一个新的Bean,该作用域仅适用于WebApplicationContext环境。
- scope 属性若为 session 同一个HTTP Session 共享一个Bean,不同的HTTP Session 使用不同的Bean。该作用域仅适用于WebApplicationContext环境。
4、IOC 容器中 Bean 的生命周期
Spring IOC 容器可以管理 Bean 的生命周期, Spring 允许在Bean生命周期特定点执行定制的任务。
Spring IOC 容器对 Bean 的生命周期进行管理的过程:
1、通过构造器或工厂方法创建 Bean 实例,调用默认构造器。
2、为 Bean 的属性设置值和对其他 Bean 的引用。
3、调用 Bean 的初始化方法 init();
4、Bean 初始化完成可以使用。
5、当容器关闭时, 调用 Bean 的销毁方法 destroy();
- 在 Bean 的声明里设置 init-method 和 destroy-method 属性, 为 Bean 指定初始化和销毁方法。
5、创建 Bean 后置处理器后的生命周期 👆比较 4
Bean 后置处理器允许在调用初始化方法前后对 Bean 进行额外的处理。
Bean 后置处理器对 IOC 容器里的所有 Bean 实例逐一处理, 而非单一实例。
- 其典型应用是: 检查 Bean 属性的正确性或根据特定的标准更改 Bean 的属性。对Bean 后置处理器而言, 需要实现 BeanPostProcessor 接口。 在初始化方法被调用前后, Spring 将把每个 Bean 实例分别传递给上述接口的以下两个方法:
- postProcessAfterInitialization();
- postProcessBeforeInitialization();
需要在 applicationContext.xml配置文件 配置这个实现 BeanPostProcessor 接口的类。
添加 Bean 后置处理器后 Spring IOC 容器对 Bean 的生命周期进行管理的过程:
1、通过构造器或工厂方法创建 Bean 实例,调用默认构造器。
2、为 Bean 的属性设置值和对其他 Bean 的引用。
3、将Bean实例传递给Bean后置处理器的 postProcessBeforeInitialization 方法 init() 方法之前调用。
4、调用 Bean 的初始化方法 init();
5、将Bean实例传递给Bean后置处理器的 postProcessAfterInitialization 方法 init() 方法之后调用。
6、Bean 初始化完成可以使用。
7、当容器关闭时, 调用 Bean 的销毁方法 destroy();
6、使用外部属性文件
在配置文件里配置 Bean 时, 有时需要在 Bean 的配置里混入系统部署的细节信息(例如: 文件路径, 数据源配置信息等)。而这些部署细节实际上需要和 Bean 配置相分离。
Spring 2.0 Spring 提供了一个 PropertyPlaceholderConfigurer 的 BeanFactory 后置处理器 (过时)
这个处理器允许用户将 Bean 配置的部分内容外移到属性文件中。
Spring 2.5 之后: 可通过 < context:property-placeholder /> 元素简化
1 | <context:component-scan base-package="Spring"></context:component-scan> |
1 | db.properties |
可以在 Bean 配置文件里使用形式为 ${var} 的变量。
7、通过调用静态工厂方法创建 Bean
- 调用静态工厂方法创建 Bean是将对象创建的过程封装到静态方法中。 当客户端需要对象时, 只需要简单地调用静态方法, 而不同关心创建对象的细节。
- 要声明通过静态方法创建的 Bean, 需要在 Bean 的 class 属性里指定拥有该工厂的方法的类, 同时在 factory-method 属性里指定工厂方法的名称。
- 最后, 使用
元素为该方法传递方法参数。
1 | <!-- 通过静态工厂方法: 一个类中有一个静态方法, 可以返回一个类的实例(了解) --> |
8、通过调用实例工厂方法创建 Bean
- 实例工厂方法: 将对象的创建过程封装到另外一个对象实例的方法里。
- 当客户端需要请求对象时, 只需要简单的调用该实例方法而不需要关心对象的创建细节。
要声明通过实例工厂方法创建的 Bean
1、在 bean 的 factory-bean 属性里指定拥有该工厂方法的 Bean。
2、在 factory-method 属性里指定该工厂方法的名称。
3、使用 construtor-arg 元素为工厂方法传递方法参数。
实现 FactoryBean 接口在 Spring IOC 容器中配置 Bean
- Spring 中有两种类型的 Bean, 一种是普通Bean, 另一种是工厂Bean, 即FactoryBean。
- 工厂 Bean 跟普通Bean不同, 其返回的对象不是指定类的一个实例, 其返回的是该工厂 Bean 的 getObject 方法所返回的对象。
1 | <!-- 实例工厂方法: 先需要创建工厂对象, 再调用工厂的非静态方法返回实例(了解) --> |
9、在 classpath 中扫描组件
组件扫描(component scanning):Spring能够从classpath下自动扫描,实例化具有特定注解的组件
- 特定组件包括:
- @Component: 基本注解, 标识了一个受 Spring 管理的组件。
- @Respository: 标识持久层组件。
- @Service: 标识服务层(业务层)组件。
- @Controller: 标识表现层组件。
对于扫描到的组件, Spring 有默认的命名策略: 使用非限定类名, 第一个字母小写。也可以在注解中通过 value 属性值标识组件的名称。
当在组件类上使用了特定的注解之后, 还需要在 Spring 的配置文件中声明。
< context:component-scan base-package=”Spring”></context:component-scan >
- base-package 属性指定一个需要扫描的基类包,Spring 容器将会扫描这个基类包里及其子包中的所有类。当需要扫描多个包时, 可以使用逗号分隔。
如果仅希望扫描特定的类而非基包下的所有类,可使用 resource-pattern 指定扫描的资源,示例:
- < context:component-scan base-package=”..” resource-pattern=”Respository/*“ />
- < context:include-filter > 子节点表示要包含的目标类。
- < context:exclude-filter > 子节点表示要排除在外的目标类。
- < context:component-scan > 下可以拥有若干个 < context:include-filter > 和 < context:exclude-filter > 子节点
< context:include-filter > 和 < context:exclude-filter > 子节点支持多种类型的过滤表达式:
1 | //注解类型 |
10、组件装配 自动注入
< context:component-scan >元素还会自动注册AutowiredAnnotationBeanPostProcessor实例
- 该实例可以自动装配具有 @Autowired 和 @Resource 、@Inject注解的属性。
- 建议 @Autowired 自动装配 Bean。
- @Autowired 注解自动装配具有兼容类型的单个Bean属性。
- @Resource 注解要求提供一个 Bean 名称的属性,若该属性为空,则自动采用标注处的变量或方法名作为 Bean 的名称
构造器, 普通字段 (即使是非 public), 一切具有参数的方法都可以应用@Autowired 注解。默认情况下, 所有使用 @Autowired 注解的属性都需要被设置。当 Spring 找不到匹配的 Bean 装配属性时, 会抛出异常, 若某一属性允许不被设置,可以设置 @Autowired 注解的 required 属性为 false。
默认情况下, 当 IOC 容器里存在多个类型兼容的 Bean 时, 通过类型的自动装配将无法工作。此时可以在 @Qualifier
注解里提供 Bean 的名称。 Spring 允许对方法的入参标注 @Qualifiter 已指定注入 Bean 的名称。
- @Autowired 注解也可以应用在数组类型的属性上, 此时 Spring 将会把所有匹配的 Bean 进行自动装配。
- @Autowired 注解也可以应用在集合属性上, 此时 Spring 读取该集合的类型信息, 然后自动装配所有与之兼容的 Bean。
- @Autowired 注解用在java.util.Map上时,若该 Map 的键值为 String,那么 Spring 将自动装配与 Map 值类型兼容的 Bean,此时 Bean 的名称作为键值。
11、Spring表达式语言:SpEL
Spring 表达式语言(简称SpEL):是一个支持运行时查询和操作对象图的强大的表达式语言。语法类似于 EL:SpEL 使用 #{…} 作为定界符,所有在大框号中的字符都将被认为是 SpEL。SpEL 为 bean 的属性进行动态赋值提供了便利。
- 通过 SpEL 可以实现:
- 通过 bean 的 id 对 bean 进行引用
- 调用方法以及引用对象中的属性
- 计算表达式的值
- 正则表达式的匹配
三、Aspect-Oriented Programming
1、AOP 面向切面编程
- 是一种新的方法论, 是对传统 OOP(Object-Oriented Programming, 面向对象编程) 的补充。
- AOP 的主要编程对象是切面(aspect), 切面模块化 –> 横切关注点。
- 在应用 AOP 编程时, 仍然需要定义公共功能, 但可以明确的定义这个功能在哪里, 以什么方式应用, 并且不必修改受影响的类。
- 这样一来横切关注点就被模块化到特殊的对象(切面)里。
AOP所处理的问题
- 代码混乱:越来越多的非业务需求(日志和验证等)加入后, 原有的业务方法急剧膨胀。每个方法在处理核心逻辑的同时还必须兼顾其他多个关注点。
- 代码分散:以日志需求为例, 只是为了满足这个需求, 不得不在多个模块(方法)里多次重复相同的日志代码。如果日志需求发生变化, 必须修改所有模块。
AOP 的好处:
- 每个事物逻辑位于一个位置, 代码不分散, 便于维护和升级。
- 业务模块更简洁, 只包含核心业务代码。
2、使用动态代理解决上述问题
- 代理设计模式的原理:
使用一个代理将对象包装起来, 然后用该代理对象取代原始对象。任何对原始对象的调用都要通过代理。代理对象决定是否以及何时将方法调用转到原始对象上
3、AOP 术语
- 切面(Aspect): 横切关注点 (跨越应用程序多个模块的功能) 被模块化的特殊对象。
- 通知(Advice): 切面必须要完成的工作。
- 目标(Target): 被通知的对象。
- 代理(Proxy): 向目标对象应用通知之后创建的对象。
- 连接点(Joinpoint): 程序执行的某个特定位置:类某个方法调用前、后、方法抛出异常后
- 连接点由两个信息确定:
- 方法表示的程序执行点。
- 相对点表示的方位。
- 例如 Calculator.add() 方法执行前的连接点,执行点为 Calculator.add();方位为该方法执行前的位置。
- 连接点由两个信息确定:
切点(pointcut): 每个类都拥有多个连接点:例如 Calculator 的所有方法实际上都是连接点,即连接点是程序类中客观存在的事务。
AOP 通过切点定位到特定的连接点。类比:连接点相当于数据库中的记录,切点相当于查询条件。切点和连接点不是一对一的关系,一个切点匹配多个连接点。
切点通过 org.springframework.aop.Pointcut 接口进行描述,它使用类和方法作为连接点查询条件。
4、在 Spring 中启用 AspectJ 注解支持
- 要在 Spring 应用中使用 AspectJ 注解, 必须在 classpath 下包含 AspectJ 类库:
- aopalliance.jar
- aspectj.weaver.jar
- spring-aspects-4.0.0.RELEASE.jar
- spring-aop-4.0.0.RELEASE.jar
将 aop Schema 添加到
要在 Spring IOC 容器中启用 AspectJ 注解支持, 只要在 Spring 配置文件中定义一个空的 XML 元素 <aop:aspectj-autoproxy/>
1
2<!-- 配置自动为匹配 aspectJ 注解的 Java 类生成代理对象 -->
<aop:aspectj-autoproxy></aop:aspectj-autoproxy>
当Spring IOC容器侦测到Spring配置文件中的< aop:aspectj-autoproxy />元素时, 会自动为 AspectJ 切面匹配的 Bean 创建代理。
5、用 AspectJ 注解声明切面
要在 Spring 中声明 AspectJ 切面, 只需要在 IOC 容器中将切面声明为 Bean 实例。
- @Aspect //声明此类是一个切面对象
- @Component //声明此类是 Spring 容器 管理的组件
当在 Spring IOC 容器中初始化 AspectJ 切面之后, Spring IOC 容器就会为那些与 AspectJ 切面相匹配的 Bean 创建代理。在 AspectJ 注解中, 切面只是一个带有 @Aspect 注解的 Java 类。
通知是标注有某种注解的简单的 Java 方法
- AspectJ 支持 5 种类型的通知注解:
- @Before: 前置通知, 在方法执行之前执行
- @After: 后置通知, 在方法执行之后执行
- @AfterRunning: 返回通知, 在方法返回结果之后执行
- @AfterThrowing: 异常通知, 在方法抛出异常之后
- @Around: 环绕通知, 围绕着方法执行
指定切面的优先级
在同一个连接点上应用不止一个切面时, 除非明确指定, 否则它们的优先级是不确定的。
- 切面的优先级可以通过实现 Ordered 接口或利用 @Order 注解指定。
- 实现 Ordered 接口, getOrder() 方法的返回值越小, 优先级越高。
- 若使用 @Order 注解, 序号出现在注解中。
1 | import org.aspectj.lang.JoinPoint; |
一个切面可以包括一个或者多个通知
前置通知:在方法执行之前执行的通知
- 前置通知使用 @Before 注解, 并将切入点表达式的值作为注解值。
- 让通知访问当前连接点的细节。
- 在通知方法中声明一个类型为 JoinPoint 的参数,然后就能访问链接细节。如方法名称,参数值
1
2
3
4
5
6
7"execution(public int spring.aop.*(int, int))") (
public void beforeMethod(JoinPoint joinPoint) {
String methodName = joinPoint.getSignature().getName();
Object[] args = joinPoint.getArgs();
System.out.println("The method " + methodName + " begins with " + Arrays.asList(args));
}
后置通知:在目标方法执行后。
- (无论是否发生异常),都执行的通知。
- 后置通知是在连接点完成之后执行的, 即连接点返回结果或者抛出异常的时候, 下面的后置通知记录了方法的终止。
- 在后置通知中还不能访问目标方法执行的结果。
1
2
3
4
5"execution(public int spring.aop.*(int, int))") (
public void afterMethod(JoinPoint joinPoint) {
String methodName = joinPoint.getSignature().getName();
System.out.println("The method " + methodName + " ends");
}
返回通知:在方法正常结束后执行的代码
- 返回通知是可以访问到方法的返回值的。
- 无论连接点是正常返回还是抛出异常, 后置通知都会执行。
- 但如果只想在连接点返回的时候记录日志, 应使用返回通知代替后置通知。
在返回通知中访问连接点的返回值
- 在返回通知中, 只要将 returning属性添加到 @AfterReturning 注解中, 就可以访问连接点的返回值。
- 该属性的值即为用来传入返回值的参数名称。
- 必须在通知方法的签名中添加一个同名参数。returning=”result” 签名属性也为 result 。在运行时, Spring AOP 会通过这个参数传递返回值。
- 原始的切点表达式需要出现在 pointcut 属性中。
1
2
3
4
5"execution(public int spring.aop.*(..))",returning="result") (value=
public void afterReturning(JoinPoint joinPoint, Object result){
String methodName = joinPoint.getSignature().getName();
System.out.println("The method " + methodName + " ends with " + result);
}
异常通知:在目标方法出现异常时会执行的代码
- 可以访问到异常对象, 且可以指定在出现特定异常时在执行通知代码。
- 只在连接点抛出异常时才执行异常通知
将 throwing 属性添加到 @AfterThrowing 注解中, 可以访问连接点抛出的异常。
- Throwable 是所有错误和异常类的超类。所以在异常通知方法可以捕获到任何错误和异常。
- 如果只对某种特殊的异常类型感兴趣, 可以将参数声明为其他异常的参数类型. 然后通知就只在抛出这个类型及其子类的异常时才被执行。
- 比如讲下面签名参数的 Exception 换成 NullPointerException 只有发生了 NullPointerException 才会执行。
1
2
3
4
5"execution(public int spring.aop.*(..))",throwing="e") (value=
public void afterThrowing(JoinPoint joinPoint, Exception e){
String methodName = joinPoint.getSignature().getName();
System.out.println("The method " + methodName + " occurs excetion:" + e);
}
环绕通知
- 环绕通知是所有通知类型中功能最为强大的, 能够全面地控制连接点。 甚至可以控制是否执行连接点。
- 对于环绕通知来说, 连接点的参数类型必须是 ProceedingJoinPoint。它是 JoinPoint 的子接口, 允许控制何时执行, 是否执行连接点。
- 在环绕通知中需要明确调用 ProceedingJoinPoint 的 proceed() 方法来执行被代理的方法。
- 如果忘记这样做就会导致通知被执行了, 但目标方法没有被执行。
注意: 环绕通知的方法需要返回目标方法执行之后的结果, 即调用 proceedingJoinPoint.proceed() 的返回值, 否则会出现空指针异常。
- 环绕通知需要携带 ProceedingJoinPoint 类型的参数。
- 环绕通知类似于动态代理的全过程: ProceedingJoinPoint 类型参数决定是否执行目标方法。
- 且环绕通知必须有返回值, 返回值即为目标方法的返回值。
1 | "execution(public int spring.aop.*(..))") (value= |
重用切入点定义
- 在编写 AspectJ 切面时, 可以直接在通知注解中书写切入点表达式。 但同一个切点表达式可能会在多个通知中重复出现。
- 在 AspectJ 切面中, 可以通过 @Pointcut 注解将一个切入点声明成简单的方法。
- 切入点的方法体通常是空的, 因为将切入点定义与应用程序逻辑混在一起是不合理的。
- 切入点方法的访问控制符同时也控制着这个切入点的可见性。
- 如果切入点要在多个切面中共用, 最好将它们集中在一个公共的类中. 在这种情况下, 它们必须被声明为 public。
- 在引入这个切入点时, 必须将类名也包括在内。 如果类没有与这个切面放在同一个包中, 还必须包含包名。
- 其他通知可以通过方法名称引入该切入点。
1 | /** |
引入通知(很少使用)
- 引入通知是一种特殊的通知类型.
- 它通过为接口提供实现类, 允许对象动态地实现接口, 就像对象已经在运行时扩展了实现类一样.
6、用基于 XML 的配置声明切面
- 除了使用 AspectJ 注解声明切面, Spring 也支持在 Bean 配置文件中声明切面。
- 这种声明是通过 aop schema 中的 XML 元素完成的。
正常情况下, 基于注解的声明要优先于基于 XML 的声明。
- 通过 AspectJ 注解, 切面可以与 AspectJ 兼容, 基于 XML 的配置则是 Spring 专有的。
- 由于 AspectJ 得到越来越多的 AOP 框架支持, 以注解风格编写的切面将会有更多重用的机会。
基于 XML:声明切面
- 当使用 XML 声明切面时, 需要在
根元素中导入 aop:Schema - 在 Bean 配置文件中, 所有的 Spring AOP 配置都必须定义在 <aop:config> 元素内部。
- 对于每个切面, 都要创建一个 <aop:aspect> 元素来为具体的切面实现引用后端 Bean 实例。
- 切面 Bean 必须有一个 id 标示符, 供 <aop:aspect> 元素引用。
基于 XML:声明切入点
- 切入点使用 <aop:pointcut> 元素声明。
- 切入点必须定义在。
- 1、<aop:aspect> 元素下 ——> 定义在 <aop:aspect> 元素下: 只对当前切面有效。
- 2、<aop:config> 元素下 ——> 定义在 <aop:config> 元素下: 对所有切面都有效。
- 基于 XML 的 AOP 配置不允许在切入点表达式中用名称引用其他切入点。
1 | <!-- 配置 bean --> |
四、Spring 中的事务管理
Spring 既支持编程式事务管理, 也支持声明式的事务管理。
1、编程式事务管理:将事务管理代码嵌入到业务方法中来控制事务的提交和回滚。必须在每个事务操作中包含额外的事务管理代码。
2、声明式事务管理:大多数情况下比编程式事务管理更好用。它将事务管理代码从业务方法中分离出来, 以声明的方式来实现事务管理。
事务管理作为一种横切关注点, 可以通过 AOP 方法模块化。 Spring 通过 Spring AOP 框架支持声明式事务管理。
- Spring 从不同的事务管理 API 中抽象了一整套的事务机制。 开发人员不必了解底层的事务 API, 就可以利用这些事务机制。
- 有了这些事务机制, 事务管理代码就能独立于特定的事务技术了。
1、用 @Transactional 注解 声明式地管理事务
1、配置以下信息
- 添加<tx:> 命名空间
1 | <!-- 1、 配置事务管理器 --> |
2、在相应的方法上用 @Transactional 注解标注
2、用 XML 事务通知 声明式地管理事务
1、添加<tx:> 命名空间。
2、配置事务管理器 transactionManager 。
hibernateTransactionManager mybatisTransactionManager
3、配置元素声明事务通知 <tx:advice></tx:advice>
4、配置事务切入点 <aop:config>
5、在 <aop:config> 中配置 <aop:pointcut> 表达式。
6、在 <aop:config> 中声明一个增强器通知与切入点关联起来 。
<aop:advisor advice-ref=”txAdvice” pointcut-ref=”txPointCut”/>
由于 Spring AOP 是基于代理的方法, 所以只能增强公共方法。因此, 只有公有方法才能通过 Spring AOP 进行事务管理。
1 | <!-- 1. 配置事务管理器 --> |
3、事务传播行为 (propagation behavior)
当事务方法被另一个事务方法调用时, 必须指定事务应该如何传播
例如: 方法可能继续在现有事务中运行, 也可能开启一个新事务, 并在自己的事务中运行。
事务传播属性可以在 @Transactional 注解的 propagation 属性中定义 (PROPAGATION_REQUIRED) 默认传播行为。
事务的传播行为可以由传播属性指定。 Spring 定义了 7 种类传播行为
事务传播行为类型 | 说明 |
---|---|
PROPAGATION_REQUIRED (默认) | 如果当前没有事务,就新建一个事务,如果已经存在一个事务中,加入到这个事务中。 |
PROPAGATION_SUPPORTS | 支持当前事务,如果当前没有事务,就以非事务方式执行。 |
PROPAGATION_MANDATORY | 使用当前的事务,如果当前没有事务,就抛出异常。 |
PROPAGATION_REQUIRES_NEW | 新建事务,如果当前存在事务,把当前事务挂起。 |
PROPAGATION_NOT_SUPPORTED | 以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。 |
PROPAGATION_NEVER | 以非事务方式执行,如果当前存在事务,则抛出异常。 |
PROPAGATION_NESTED | 如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则执行与PROPAGATION_REQUIRED类似的操作。 |
REQUIRED 传播行为
- 如果当前没有事务,就新建一个事务,如果已经存在一个事务中,加入到这个事务中。
REQUIRES_NEW 传播行为
- 它表示该方法必须启动一个新事务, 并在自己的事务内运行。 如果有事务在运行, 就应该先挂起它。
4、并发事务所导致的问题
- 当同一个应用程序或者不同应用程序中的多个事务在同一个数据集上并发执行时, 如果没有采取必要的隔离机制,可能会出现许多意外的问题
并发事务所导致的问题可以分为下面三种类型:
- 脏读: 对于两个事务 T1, T2, T1 读取了已经被 T2 更新但还没有被提交的字段. 之后, 若 T2 回滚, T1读取的内容就是临时且无效的。
- 不可重复读: 对于两个事务 T1, T2, T1 读取了一个字段, 然后 T2 更新了该字段. 之后, T1再次读取同一个字段, 值就不同了。
- 幻读: 对于两个事务 T1, T2, T1 从一个表中读取了一个字段, 然后 T2 在该表中插入了一些新的行. 之后, 如果 T1 再次读取同一个表, 就会多出几行。
5、事务的隔离级别 (Isolation level)
Spring 支持的事务隔离级别
事务的隔离级别要得到底层数据库引擎的支持, 而不是应用程序或者框架的支持。
事务隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
READ-UNCOMMITTED (读未提交) | 是 | 是 | 是 |
READ-COMMITTED (读已提交数据) | 否 | 是 | 是 |
REPEATABLE-READ (可重复读) | 否 | 否 | 是 |
SERIALIZABLE (串行化否) | 否 | 否 | 否 |
设置隔离事务属性
- 用 @Transactional 注解声明式地管理事务时可以在 @Transactional 的
isolation
属性中设置隔离级别。 - 用 事务通知 声明式地管理事务时可以在
<tx:advice><tx:attributes><tx:method isolation=” “> 元素中指定隔离级别。
6、设置回滚事务属性 (rollback)
默认情况下只有未检查异常(RuntimeException和Error类型的异常)会导致事务回滚。而受检查异常不会。
注解声明式地管理事务 事务的回滚规则可以通过 @Transactional 注解的 rollbackFor 和 noRollbackFor
属性来定义。
- 这两个属性被声明为 Class[] 类型的, 因此可以为这两个属性指定多个异常类。
事务通知 声明式地管理事务时可以在
<tx:advice><tx:attributes><tx:method rollbackFor=” “> 元素中指定回滚规则。
- 如果有不止一种异常, 用逗号分隔。
7、超时和只读属性 (timeout read-only)
由于事务可以在行和表上获得锁,因此长事务会占用资源, 并对整体性能产生影响。
如果一个事物只读取数据但不做修改
, 数据库引擎可以对这个事务进行优化。
- 超时事务属性: 事务在强制回滚之前可以保持多久. 这样可以防止长期运行的事务占用资源。
- 只读事务属性: 表示这个事务只读取数据但不更新数据, 这样可以帮助数据库引擎优化事务。
- 用 @Transactional 注解声明式地管理事务时可以在 @Transactional 的
read-only timeout
(秒级别) 属性中设置。 - 用 事务通知 声明式地管理事务时可以在
<tx:advice><tx:attributes><tx:method read-only=”” timeout=””>元素中指定。
web.xml 配置启动 Spring IOC 容器的 Listener
1 | <!-- 配置启动 Spring IOC 容器的 Listener --> |
1 | <servlet> |
JdbcTemplate 简介
为了使 JDBC 更加易于使用, Spring在JDBC API上定义了一个抽象层, 建立一个 JDBC 存取框架。
1 | <!-- 配置 Spirng 的 JdbcTemplate --> |
- 使用 SQL 中列的别名完成列名和类的属性名的映射。 例如 last_name lastName
- 不支持级联属性 JdbcTemplate 是一个 JDBC 的小工具, 而不是 ORM 框架。
感谢阅读
If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. If the images used in the blog infringe your copyright, please contact the author to delete them. Thank you !