为了更好地管理事务,Spring 提供了两种事务管理机制,分为编程式事务和声明式事务。
编程式事务
编程式事务在 Spring 中是通过显式地编写代码来控制事务的界限和行为。在 Spring 中主要是通过使用 TransactionTemplate
或PlatformTransactionManager
来实现的。
TransactionTemplate
TransactionTemplate
是Spring提供的一个模板类,用于简化编程式事务管理。它处理了事务的创建、提交或回滚等标准步骤。我们只需要提供执行的业务逻辑即可:
public void test() {
transactionTemplate.execute(new TransactionCallbackWithoutResult() {
protected void doInTransactionWithoutResult(TransactionStatus status) {
try {
// 执行业务逻辑
} catch (Exception e) {
status.setRollbackOnly();
}
}
});
}
PlatformTransactionManager
PlatformTransactionManager
则是一种更低级别的处理编程式事务的方式。我们需要手动创建和管理事务,包括事务的开始、提交和回滚。
public void test() {
TransactionDefinition def = new DefaultTransactionDefinition();
TransactionStatus status = transactionManager.getTransaction(def);
try {
// 执行逻辑
// 事务提交
transactionManager.commit(status);
} catch (Exception e) {
// 事务回滚
transactionManager.rollback(status);
throw e;
}
}
编程式事务需要提供了完全的控制,但是需要我们更加多的编码量,会使得代码更加复杂些。
声明式事务
声明式事务允许我们通过声明(而非直接编码)来管理事务,比如依靠注解或者配置 XML 来管理事务。在声明式事务中,事务的管理是由 Spring 框架自动完成的,我们只需要定义事务的范围和规则。
目前,声明式事务可以通过两种主要方式实现:
- 基于
@Transactional
注解的事务管理 - 基于XML的事务管理
基于 @Transactional
注解的事务管理方式很简单,就是在类或者方法上使用@Transactional
注解来声明事务,例如:
@Transactional
public void test() {
}
基于XML的事务管理,则需要在 XML 配置文件中定义事务建议和事务规则:
<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="transfer" propagation="REQUIRED"/>
</tx:attributes>
</tx:advice>
<aop:config>
<aop:pointcut id="bankServiceOperation" expression="execution(* com.example.BankService.transfer(..))"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="bankServiceOperation"/>
</aop:config>
为什么不推荐使用@Transactional声明式事务?
编程式事务和声明式事务各有优缺点。
- 编程式事务:允许开发者对事务有更加精确的控制,也更加灵活些。但是需要开发者写入更多的代码来管理事务,增加了代码的复杂度。同时,事务管理和业务混合在一起,导致事务管理的代码入侵业务代码,增加了代码的耦合度。
- 声明式事务:简单易用,一个注解就可以搞定。同时事务管理和业务代码分离,没有入侵业务代码,使开发者专注于业务逻辑的开发,事务的管理维护交个 Spring 框架来做。但是它依然存在一些问题,例如不够灵活,有局限性之类的。
目前,Spring 官方是推荐使用声明式事务,但为什么有些公司要禁止使用 @Transactional
它呢?主要是有如何几个坑,而这些坑又容易忽略且容易导致生产事故。
坑一:用不对,容易失效
@Transactional
虽然使用起来很简单,有些人在开发的时候就草草加上 @Transactional
,但是他们不知道,一旦你没有用对,是容易导致事务失效的:
@Transactional
应用在非 public 修饰的方法上- 异常被 catch 捕获导致
@Transactional
失效 - 同一个类中方法调用,导致
@Transactional
失效 - @Transactional 注解属性 propagation 设置错误
- @Transactional 注解属性 rollbackFor 设置错误
- 数据库引擎不支持事务
@Transactional
应用在 final 方法上- 多线程调用
关于失效的场景,大明哥专门写了一篇文章来分析,详情请阅读:@Transactional 注解的失效场景
坑二:粒度把握不好,导致长事务
有些小伙伴非常喜欢加 @Transactional
,为了方便就直接在类上面增加(碰到这种直接拿出去鞭尸),这种会导致该类的所有 public 方法都加上事务,导致不必要的性能开销,同时事务的边界也不清晰。
由于 @Transactional
的方便,可能会导致部分小伙伴会忽略,这样会导致什么问题呢?他可能会在被 @Transactional
嵌套的方法里面做一些长耗时操作,比如 RPC 远程调用、文件读写、消息发送等等。如果这些操作被包裹在事务里面会发生什么呢?
- 这些操作都是长耗时操作,会拉长整个事务,导致数据库连接长时间被占用,如果某个时间段该类业务突然增加,会导致数据库连接耗尽。
- 容易导致数据不一致。通过 RPC 调用成功,但是我们代码出现异常导致事务回滚,而 RPC 又不能回滚,从而导致数据不一致。
总结
也不是喷 @Transactional
,毕竟 Spring 官方都推荐声明式事务,我有啥资格瞎 BB 呢?但是有些规范他都是血泪的教训,曾几何时,作为初出茅庐的大明哥,也是很喜欢使用 @Transactional
,毕竟简单、干净、优雅。但是,优雅的同时,也带来的就是一些血和泪。
大明哥在这里并不是要你放弃@Transactional
,这是我们在使用它的时候可能需要提高警惕,不要被它优雅的外表迷惑了。当你在新增一个 @Transactional
时一定要仔细想想如下几个问题:
- 这个方法真的有必要增加
@Transactional
吗? - 这个方法内部是不是有不需要事务的操作?
- 不要事务的操作是不是可以抽离出来?
- 这个方法里面是否有耗时操作?
Java 面试宝典是大明哥全力打造的 Java 精品面试题,它是一份靠谱、强大、详细、经典的 Java 后端面试宝典。它不仅仅只是一道道面试题,而是一套完整的 Java 知识体系,一套你 Java 知识点的扫盲贴。
它的内容包括:
- 大厂真题:Java 面试宝典里面的题目都是最近几年的高频的大厂面试真题。
- 原创内容:Java 面试宝典内容全部都是大明哥原创,内容全面且通俗易懂,回答部分可以直接作为面试回答内容。
- 持续更新:一次购买,永久有效。大明哥会持续更新 3+ 年,累计更新 1000+,宝典会不断迭代更新,保证最新、最全面。
- 覆盖全面:本宝典累计更新 1000+,从 Java 入门到 Java 架构的高频面试题,实现 360° 全覆盖。
- 不止面试:内容包含面试题解析、内容详解、知识扩展,它不仅仅只是一份面试题,更是一套完整的 Java 知识体系。
- 宝典详情:https://www.yuque.com/chenssy/sike-java/xvlo920axlp7sf4k
- 宝典总览:https://www.yuque.com/chenssy/sike-java/yogsehzntzgp4ly1
- 宝典进展:https://www.yuque.com/chenssy/sike-java/en9ned7loo47z5aw
目前 Java 面试宝典累计更新 400+ 道,总字数 42w+。大明哥还在持续更新中,下图是大明哥在 2024-12 月份的更新情况:
想了解详情的小伙伴,扫描下面二维码加大明哥微信【daming091】咨询
同时,大明哥也整理一套目前市面最常见的热点面试题。微信搜[大明哥聊 Java]或扫描下方二维码关注大明哥的原创公众号[大明哥聊 Java] ,回复【面试题】 即可免费领取。