1. 为什么声明式事务是Spring JDBC里最值得吃透的一环刚接触Spring JDBC那会儿我对事务的理解还停留在“手动开、手动提交、出错回滚”的阶段。每次写业务方法开头先拿Connection中间一堆try-catch最后在finally里小心翼翼地commit或者rollback。代码能跑但一旦业务逻辑变复杂比如一个方法里要操作三张表中间还调用了别的Service事务边界就开始变得模糊——到底该在哪一层开事务嵌套调用会不会重复提交异常被吞了怎么办这些问题靠手写JDBC的模板代码几乎没法优雅解决。后来用上Spring的声明式事务才真正体会到什么叫“把横切关注点从业务代码里剥离出去”。你只需要在方法或者类上打一个Transactional剩下的开启、提交、回滚、连接绑定Spring全帮你处理了。听起来简单但实际用起来坑一点都不少什么情况下事务会失效传播行为怎么选只读事务到底有没有用rollbackFor不写会怎样这些问题如果没搞清楚线上出问题的时候你连日志都看不懂。这篇内容就是围绕Spring JDBC的声明式事务管理展开的。我会从整体设计思路讲起把核心概念、配置方式、传播行为、隔离级别、失效场景、排查技巧全部拆开揉碎配上可以直接抄的代码和参数说明。不管你是刚学Spring Boot的新手还是已经用了几年但一直没系统梳理过的老手应该都能从中找到一些之前忽略的细节。全文基于常见的Spring Boot JDBC实践来写不依赖任何特定框架版本思路通用。2. 声明式事务的整体设计与核心思路拆解2.1 从编程式到声明式到底省了什么先说说编程式事务长什么样这样对比才直观。用Spring的TransactionTemplate写编程式事务大概是这个路子transactionTemplate.execute(status - { jdbcTemplate.update(INSERT INTO orders ...); jdbcTemplate.update(UPDATE inventory ...); return null; });这段代码本身没问题事务边界清晰异常会自动回滚。但问题是每个需要事务的方法你都得包一层业务代码和事务控制代码混在一起。如果方法里还有条件分支、循环调用代码很快就变得难以维护。声明式事务的核心思路是AOP代理。Spring在容器启动时会为标注了Transactional的Bean生成一个代理对象。当你调用这个Bean的方法时实际上调用的是代理对象代理会在方法执行前开启事务、把Connection绑定到当前线程方法执行完后根据是否抛异常来决定提交还是回滚。业务代码里完全看不到事务的痕迹这就是“声明式”三个字的含义。注意声明式事务依赖代理所以只有通过代理对象调用的方法才会被事务管理。同一个类内部的方法直接调用this.method()是不会走代理的这是最常见的失效场景之一后面会详细讲。2.2 为什么Spring JDBC场景下更推荐声明式有人可能会问MyBatis、Hibernate也有声明式事务为什么单独说Spring JDBC其实声明式事务的底层机制是通用的但Spring JDBC的场景有几个特点让它特别适合声明式第一Spring JDBC本身就是轻量封装没有Session、一级缓存这些概念事务管理的职责非常纯粹就是Connection的开启、提交、回滚。声明式事务和它的契合度最高不会出现ORM框架里那种“事务和Session生命周期不一致”的坑。第二Spring JDBC通常配合DataSourceTransactionManager使用这个事务管理器直接操作DataSource和Connection逻辑简单透明。你只要配置好数据源事务管理器几乎不需要额外调优。第三在微服务或者多数据源场景下Spring JDBC的声明式事务更容易做定制。比如你需要根据某个条件动态切换数据源或者在一个事务里操作多个数据源分布式事务的简化场景基于DataSourceTransactionManager扩展比基于ORM框架要灵活得多。2.3 核心组件与执行链路声明式事务的完整链路涉及几个关键组件理解它们之间的关系对排查问题非常有帮助组件职责常见实现PlatformTransactionManager事务管理的顶层接口定义获取、提交、回滚事务的方法DataSourceTransactionManagerTransactionDefinition定义事务属性传播行为、隔离级别、超时、只读DefaultTransactionDefinitionTransactionStatus表示当前事务的运行状态DefaultTransactionStatusTransactionInterceptorAOP拦截器负责在方法前后织入事务逻辑由Spring自动装配BeanFactoryTransactionAttributeSourceAdvisor切面顾问决定哪些Bean和方法需要被事务代理由EnableTransactionManagement注册执行链路大致是这样的调用方调用代理对象的方法 →TransactionInterceptor拦截 → 根据TransactionDefinition获取或创建事务 → 执行业务方法 → 根据执行结果提交或回滚 → 清理线程绑定的Connection。这条链路里任何一个环节出问题都会导致事务行为不符合预期。比如TransactionDefinition里的传播行为配错了就会出现“明明抛了异常却没回滚”或者“不该回滚的时候回滚了”。3. 核心配置与实操要点全解析3.1 开启声明式事务的两种方式在Spring Boot项目里最简单的方式是直接在启动类或者配置类上加EnableTransactionManagementConfiguration EnableTransactionManagement public class TransactionConfig { // 数据源和JdbcTemplate的配置 }不过实际上如果你用的是Spring Boot的spring-boot-starter-jdbc这个注解通常可以省略。因为DataSourceTransactionManagerAutoConfiguration会自动配置一个DataSourceTransactionManager而TransactionAutoConfiguration会在检测到PlatformTransactionManager存在时自动启用事务管理。也就是说只要你引入了JDBC starter并且配置了数据源声明式事务就已经可用了。但如果你用的是多数据源或者需要自定义事务管理器那就必须手动配置。比如Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { return new DataSourceTransactionManager(dataSource); }这里有个细节DataSourceTransactionManager的构造函数接收DataSource它会通过DataSourceUtils.getConnection()来获取连接。如果你在事务方法里直接用dataSource.getConnection()拿到的会是另一个连接事务自然就不生效了。所以务必确保你的DAO层用的是JdbcTemplate或者通过DataSourceUtils获取连接。3.2 Transactional注解的关键属性Transactional注解有一堆属性常用的就那么几个但每一个都值得说清楚propagation传播行为这是最容易出问题的属性。默认是REQUIRED意思是如果当前没有事务就新建一个如果有就加入。其他常用的还有REQUIRES_NEW挂起当前事务新建一个独立事务、NESTED嵌套事务基于保存点、SUPPORTS有事务就用没有就非事务执行、NOT_SUPPORTED挂起当前事务非事务执行。isolation隔离级别默认是DEFAULT也就是用数据库的默认隔离级别。MySQL的InnoDB默认是REPEATABLE_READOracle默认是READ_COMMITTED。一般情况下不需要改除非你有特殊的并发需求。timeout超时时间单位是秒默认是-1不超时。如果某个事务可能执行很久建议设置一个合理的超时时间避免长时间占用连接。readOnly只读默认是false。设置为true时Spring会做一些优化比如设置Connection的readOnly属性某些数据库驱动会据此优化查询。但要注意只读事务里如果执行了写操作行为取决于数据库实现不一定会报错。rollbackFor回滚异常默认只对RuntimeException和Error回滚受检异常不会触发回滚。这是很多人踩过的坑——方法里抛了IOException事务却没回滚。解决办法就是显式指定rollbackFor Exception.class。noRollbackFor不回滚异常指定哪些异常不触发回滚用的比较少但在某些业务场景下有用。3.3 传播行为的选择逻辑与实战场景传播行为是声明式事务里最抽象的部分我用几个实际场景来说明怎么选场景一订单创建 库存扣减。这两个操作必须在同一个事务里要么都成功要么都失败。用默认的REQUIRED就行因为它们是同一个业务方法里的连续操作。场景二订单创建 发送通知。发送通知失败不应该导致订单回滚这时候可以把发送通知的方法标注为REQUIRES_NEW让它在一个独立事务里执行。但要注意如果通知方法内部抛了异常外层事务不会回滚你需要自己catch住。场景三批量导入每条记录独立事务。比如导入1000条数据希望某一条失败不影响其他条。这时候可以在循环里调用一个标注了REQUIRES_NEW的方法每条记录一个事务。但这样性能会很差因为每次都要新建连接。更好的做法是用批量操作 保存点或者干脆不用事务靠数据库的唯一约束来保证一致性。场景四嵌套调用内层失败不影响外层。用NESTED传播行为内层事务基于保存点内层回滚不会导致外层回滚。但NESTED需要数据库支持保存点MySQL的InnoDB是支持的。实操心得传播行为的选择没有绝对的对错关键是想清楚“内层失败时外层应该怎么办”。如果外层必须回滚用REQUIRED如果外层不受影响用REQUIRES_NEW或NESTED如果外层有没有事务都行用SUPPORTS。3.4 事务管理器与数据源的绑定关系DataSourceTransactionManager在开启事务时会通过TransactionSynchronizationManager把Connection绑定到当前线程的ThreadLocal里。后续在同一个线程里调用JdbcTemplate它会通过DataSourceUtils.getConnection()拿到这个已经绑定的Connection从而保证所有操作都在同一个事务里。这个机制有一个重要的推论事务是线程绑定的。如果你在事务方法里开了新线程去执行数据库操作新线程拿不到绑定的Connection事务自然就不生效了。这是多线程场景下事务失效的根本原因。另外如果你在事务方法里手动调用了dataSource.getConnection()拿到的也是一个新连接不受事务管理。所以务必统一使用JdbcTemplate或者DataSourceUtils。4. 完整实操流程与关键环节实现4.1 项目依赖与基础配置先给出一个最小可运行的配置。假设你用的是Maven依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependencyapplication.yml里的数据源配置spring: datasource: url: jdbc:mysql://localhost:3306/demo?useSSLfalseserverTimezoneUTC username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 30000这里用的是HikariCP连接池Spring Boot默认就是它。连接池的配置直接影响事务的表现如果maximum-pool-size太小高并发下事务方法会因为拿不到连接而超时如果connection-timeout太短稍微慢一点的查询就会报错。一般建议maximum-pool-size设置为数据库最大连接数的70%左右connection-timeout至少30秒。4.2 一个完整的业务场景转账转账是经典的事务场景涉及两个账户的余额变动。先建表CREATE TABLE account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, balance DECIMAL(18, 2) NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0 );然后写DAO层用JdbcTemplateRepository public class AccountDao { private final JdbcTemplate jdbcTemplate; public AccountDao(JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } public BigDecimal getBalance(Long id) { return jdbcTemplate.queryForObject( SELECT balance FROM account WHERE id ?, BigDecimal.class, id); } public int deduct(Long id, BigDecimal amount) { return jdbcTemplate.update( UPDATE account SET balance balance - ? WHERE id ? AND balance ?, amount, id, amount); } public int add(Long id, BigDecimal amount) { return jdbcTemplate.update( UPDATE account SET balance balance ? WHERE id ?, amount, id); } }Service层用TransactionalService public class TransferService { private final AccountDao accountDao; public TransferService(AccountDao accountDao) { this.accountDao accountDao; } Transactional(rollbackFor Exception.class) public void transfer(Long fromId, Long toId, BigDecimal amount) { int deducted accountDao.deduct(fromId, amount); if (deducted 0) { throw new IllegalStateException(余额不足); } accountDao.add(toId, amount); } }这段代码有几个关键点rollbackFor Exception.class确保受检异常也回滚deduct方法里带了balance ?条件防止余额扣成负数如果扣减失败直接抛异常事务回滚。4.3 参数计算与边界条件处理转账场景里金额的计算必须用BigDecimal不能用double。BigDecimal的subtract和add方法会返回新对象不会修改原对象。比较金额时用compareTo而不是equals因为equals会比较精度。BigDecimal a new BigDecimal(100.00); BigDecimal b new BigDecimal(100.0); System.out.println(a.equals(b)); // false System.out.println(a.compareTo(b)); // 0数据库字段用DECIMAL(18, 2)对应Java的BigDecimal。JdbcTemplate在查询时会自动映射但要注意MySQL的DECIMAL返回的BigDecimal精度和scale是准确的不需要额外处理。边界条件方面需要处理金额为负数或零、转出账户和转入账户相同、账户不存在、余额不足。这些判断最好在Service层做抛出自定义异常让事务回滚。4.4 事务执行过程的日志观察想确认事务是否真的生效最直接的办法是打开Spring的事务日志。在application.yml里加logging: level: org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG org.springframework.transaction.interceptor: TRACE启动后调用转账方法你会看到类似这样的日志Creating new transaction with name [com.example.TransferService.transfer]: PROPAGATION_REQUIRED, ISOLATION_DEFAULT Acquired Connection [HikariProxyConnection123456] for JDBC transaction Switching JDBC Connection to manual commit Initiating transaction commit Committing JDBC transaction on Connection [HikariProxyConnection123456] Releasing JDBC Connection after transaction如果看到Creating new transaction说明事务开启了看到Committing说明提交了。如果方法抛异常会看到Initiating transaction rollback和Rolling back JDBC transaction。这些日志是排查事务问题的第一手资料。注意日志级别调到TRACE会输出大量信息生产环境不要长期开启排查完记得改回去。5. 常见问题与排查技巧实录5.1 事务失效的六大场景声明式事务失效是最高频的问题我整理了一个速查表失效场景原因解决办法同类内部方法调用this调用不走代理注入自身代理或用AopContext.currentProxy()方法不是publicSpring AOP只代理public方法改成public或用AspectJ模式异常被catch异常没抛到代理层在catch里重新抛出或手动回滚rollbackFor没配默认只回滚RuntimeException显式指定rollbackFor Exception.class多线程调用事务绑定在ThreadLocal避免在事务方法里开新线程操作数据库数据源不匹配事务管理器和DAO用的不是同一个DataSource检查配置确保统一其中同类内部调用是最隐蔽的。比如Service public class OrderService { public void createOrder() { this.doCreate(); // 这里不会走代理事务不生效 } Transactional public void doCreate() { // 数据库操作 } }解决办法有三种一是把doCreate抽到另一个Service里二是注入自身Service public class OrderService { Autowired private OrderService self; public void createOrder() { self.doCreate(); // 通过代理调用 } }三是用AopContext.currentProxy()但需要开启exposeProxy true。5.2 事务不回滚的排查思路遇到“抛了异常但数据还是写进去了”的情况按这个顺序排查第一步确认异常类型。如果是受检异常检查rollbackFor有没有配。默认只回滚RuntimeException和Error。第二步确认异常有没有被吞掉。在catch块里打日志看看异常是不是被捕获后没有重新抛出。第三步确认方法是不是public。非public方法不会被代理。第四步确认调用方式。是不是同类内部调用是不是通过new创建的对象第五步打开事务日志看有没有Creating new transaction。如果没有说明事务根本没开启。第六步检查数据源。如果项目里有多个数据源确认事务管理器和DAO用的是同一个。5.3 传播行为导致的“诡异”现象有一次我遇到一个场景外层方法标注了Transactional内层方法标注了REQUIRES_NEW结果内层方法执行完后外层方法抛异常内层的数据却没有回滚。这其实是符合预期的——REQUIRES_NEW会挂起外层事务新建一个独立事务内层事务提交后就和外层无关了。外层回滚不会影响已经提交的内层事务。反过来如果内层用NESTED内层回滚只会回滚到保存点外层可以选择继续或者也回滚。但NESTED有个限制它依赖JDBC的保存点如果数据库不支持保存点比如某些NoSQL就会退化成REQUIRED。还有一个常见的坑REQUIRES_NEW需要一个新的数据库连接。如果连接池满了内层事务会一直等连接导致外层事务也卡住。在高并发场景下要特别注意连接池的配置。5.4 只读事务的误区Transactional(readOnly true)经常被当成性能优化手段但实际上它的效果取决于数据库和驱动。在MySQL里设置readOnly后驱动会发送SET SESSION TRANSACTION READ ONLY但InnoDB并不会因此做特殊优化。真正的优化是告诉数据库“这个事务里不会有写操作”某些数据库可以据此减少锁的开销。但要注意只读事务里如果执行了写操作MySQL会直接报错Cannot execute statement in a READ ONLY transaction而有些数据库可能只是忽略。所以不要以为加了readOnly true就绝对安全该做的校验还是要做。另外readOnly对JdbcTemplate的查询没有额外优化它只是设置Connection的属性。如果你真的想优化查询性能应该从索引、SQL语句、连接池配置入手。5.5 事务超时与连接泄漏Transactional(timeout 5)设置的是事务的超时时间单位秒。超时后Spring会尝试回滚事务但实际行为取决于数据库驱动。有些驱动会在超时后抛出异常有些则不会立即中断正在执行的SQL。更危险的是连接泄漏。如果事务方法里手动获取了Connection但没有关闭或者某个操作阻塞了很长时间连接池的连接会被耗尽。排查连接泄漏可以用连接池的监控功能比如HikariCP的leakDetectionThresholdspring: datasource: hikari: leak-detection-threshold: 60000设置60秒如果连接超过60秒没归还就会打警告日志。这个阈值不要设太小否则正常的长事务也会被误报。6. 进阶技巧与个人经验补充6.1 多数据源下的事务管理多数据源场景下每个数据源需要独立的事务管理器。如果你在一个方法里同时操作两个数据源默认情况下只有一个事务管理器生效另一个数据源的操作不在事务里。解决办法是用ChainedTransactionManagerSpring 5.3之前或者JtaTransactionManager需要XA支持。但更实际的做法是尽量避免跨数据源的强事务用最终一致性方案替代。如果确实需要可以这样配置Bean public PlatformTransactionManager transactionManager( DataSource primaryDataSource, DataSource secondaryDataSource) { DataSourceTransactionManager primary new DataSourceTransactionManager(primaryDataSource); DataSourceTransactionManager secondary new DataSourceTransactionManager(secondaryDataSource); return new ChainedTransactionManager(primary, secondary); }但要注意ChainedTransactionManager并不是真正的分布式事务它只是按顺序提交多个事务管理器如果第二个提交失败第一个已经提交了无法回滚。所以它只适合“两个数据源的操作大概率都成功”的场景。6.2 事务与异步的配合在事务方法里发异步消息或者调用异步方法要特别小心。因为异步方法在新线程里执行拿不到事务绑定的Connection也不会参与事务。如果你希望异步操作在事务提交后再执行可以用TransactionSynchronizationManager.registerSynchronizationTransactionSynchronizationManager.registerSynchronization( new TransactionSynchronization() { Override public void afterCommit() { // 事务提交后执行 asyncService.doSomething(); } } );这样能保证异步操作只在事务成功提交后触发避免“事务还没提交异步操作已经读了旧数据”的问题。6.3 事务边界的粒度控制事务边界不是越大越好。一个大事务会持有连接很长时间增加锁竞争降低并发能力。我的一般原则是事务里只放必要的数据库操作远程调用、文件IO、复杂计算都放到事务外面。比如一个下单流程校验参数 → 查询库存 → 扣减库存 → 创建订单 → 发送通知。其中“查询库存”可以放在事务外“扣减库存”和“创建订单”放在事务内“发送通知”放在事务提交后。这样事务的持有时间最短并发能力最强。6.4 一个容易被忽略的细节事务与缓存如果你在事务方法里操作了缓存比如Redis要注意缓存和数据库的一致性。常见做法是先更新数据库再删除缓存但如果在事务提交前删了缓存其他线程可能读到旧数据并重新写入缓存。更稳妥的做法是用afterCommit回调来删缓存TransactionSynchronizationManager.registerSynchronization( new TransactionSynchronization() { Override public void afterCommit() { redisTemplate.delete(cacheKey); } } );这样能保证缓存删除发生在数据库提交之后减少不一致的窗口。6.5 测试环境下的事务回滚写单元测试时经常希望测试完数据库回到初始状态。Spring Test提供了Transactional注解加在测试类上每个测试方法执行完后会自动回滚SpringBootTest Transactional public class TransferServiceTest { Autowired private TransferService transferService; Test public void testTransfer() { transferService.transfer(1L, 2L, new BigDecimal(100)); // 断言... } }但要注意如果测试方法里用了REQUIRES_NEW传播行为内层事务会独立提交不会随外层回滚。这种情况下需要手动清理数据。6.6 生产环境的事务监控生产环境里事务的执行情况需要监控。可以自定义一个TransactionSynchronization在事务提交或回滚时打点public class TransactionMonitor implements TransactionSynchronization { private final long startTime System.currentTimeMillis(); Override public void afterCompletion(int status) { long cost System.currentTimeMillis() - startTime; if (status STATUS_COMMITTED) { metrics.recordCommit(cost); } else { metrics.recordRollback(cost); } } }然后在事务方法里注册这个监听器。这样能统计事务的提交率、回滚率、平均耗时对排查性能问题很有帮助。7. 写在最后的一些实操体会声明式事务看起来只是加个注解的事但真正用好需要理解它背后的代理机制、线程绑定、传播行为。我踩过的坑里大部分都是因为“想当然”——以为加了注解就万事大吉结果同类调用失效、异常被吞、传播行为配错各种问题层出不穷。我的建议是新项目里所有涉及多表写操作的方法都显式加上Transactional(rollbackFor Exception.class)不要依赖默认值。传播行为除非有明确需求否则一律用默认的REQUIRED。事务方法尽量保持public避免同类内部调用。测试环境打开事务日志确认事务真的生效了再上线。还有一点事务不是银弹。有些场景用事务反而会带来性能问题比如大批量导入、长耗时的业务操作。这时候可以考虑用补偿机制、状态机、最终一致性方案来替代强事务。技术选型没有绝对的对错关键是匹配业务场景。最后分享一个排查事务问题的小技巧在事务方法的第一行打一条日志在最后一行也打一条然后打开DataSourceTransactionManager的DEBUG日志。如果两条业务日志之间没有事务日志说明事务没生效如果有Creating new transaction但没有Committing说明事务回滚了。这个方法简单粗暴但非常有效。
1. 为什么声明式事务是Spring JDBC里最值得吃透的一环刚接触Spring JDBC那会儿我对事务的理解还停留在“手动开、手动提交、出错回滚”的阶段。每次写业务方法开头先拿Connection中间一堆try-catch最后在finally里小心翼翼地commit或者rollback。代码能跑但一旦业务逻辑变复杂比如一个方法里要操作三张表中间还调用了别的Service事务边界就开始变得模糊——到底该在哪一层开事务嵌套调用会不会重复提交异常被吞了怎么办这些问题靠手写JDBC的模板代码几乎没法优雅解决。后来用上Spring的声明式事务才真正体会到什么叫“把横切关注点从业务代码里剥离出去”。你只需要在方法或者类上打一个Transactional剩下的开启、提交、回滚、连接绑定Spring全帮你处理了。听起来简单但实际用起来坑一点都不少什么情况下事务会失效传播行为怎么选只读事务到底有没有用rollbackFor不写会怎样这些问题如果没搞清楚线上出问题的时候你连日志都看不懂。这篇内容就是围绕Spring JDBC的声明式事务管理展开的。我会从整体设计思路讲起把核心概念、配置方式、传播行为、隔离级别、失效场景、排查技巧全部拆开揉碎配上可以直接抄的代码和参数说明。不管你是刚学Spring Boot的新手还是已经用了几年但一直没系统梳理过的老手应该都能从中找到一些之前忽略的细节。全文基于常见的Spring Boot JDBC实践来写不依赖任何特定框架版本思路通用。2. 声明式事务的整体设计与核心思路拆解2.1 从编程式到声明式到底省了什么先说说编程式事务长什么样这样对比才直观。用Spring的TransactionTemplate写编程式事务大概是这个路子transactionTemplate.execute(status - { jdbcTemplate.update(INSERT INTO orders ...); jdbcTemplate.update(UPDATE inventory ...); return null; });这段代码本身没问题事务边界清晰异常会自动回滚。但问题是每个需要事务的方法你都得包一层业务代码和事务控制代码混在一起。如果方法里还有条件分支、循环调用代码很快就变得难以维护。声明式事务的核心思路是AOP代理。Spring在容器启动时会为标注了Transactional的Bean生成一个代理对象。当你调用这个Bean的方法时实际上调用的是代理对象代理会在方法执行前开启事务、把Connection绑定到当前线程方法执行完后根据是否抛异常来决定提交还是回滚。业务代码里完全看不到事务的痕迹这就是“声明式”三个字的含义。注意声明式事务依赖代理所以只有通过代理对象调用的方法才会被事务管理。同一个类内部的方法直接调用this.method()是不会走代理的这是最常见的失效场景之一后面会详细讲。2.2 为什么Spring JDBC场景下更推荐声明式有人可能会问MyBatis、Hibernate也有声明式事务为什么单独说Spring JDBC其实声明式事务的底层机制是通用的但Spring JDBC的场景有几个特点让它特别适合声明式第一Spring JDBC本身就是轻量封装没有Session、一级缓存这些概念事务管理的职责非常纯粹就是Connection的开启、提交、回滚。声明式事务和它的契合度最高不会出现ORM框架里那种“事务和Session生命周期不一致”的坑。第二Spring JDBC通常配合DataSourceTransactionManager使用这个事务管理器直接操作DataSource和Connection逻辑简单透明。你只要配置好数据源事务管理器几乎不需要额外调优。第三在微服务或者多数据源场景下Spring JDBC的声明式事务更容易做定制。比如你需要根据某个条件动态切换数据源或者在一个事务里操作多个数据源分布式事务的简化场景基于DataSourceTransactionManager扩展比基于ORM框架要灵活得多。2.3 核心组件与执行链路声明式事务的完整链路涉及几个关键组件理解它们之间的关系对排查问题非常有帮助组件职责常见实现PlatformTransactionManager事务管理的顶层接口定义获取、提交、回滚事务的方法DataSourceTransactionManagerTransactionDefinition定义事务属性传播行为、隔离级别、超时、只读DefaultTransactionDefinitionTransactionStatus表示当前事务的运行状态DefaultTransactionStatusTransactionInterceptorAOP拦截器负责在方法前后织入事务逻辑由Spring自动装配BeanFactoryTransactionAttributeSourceAdvisor切面顾问决定哪些Bean和方法需要被事务代理由EnableTransactionManagement注册执行链路大致是这样的调用方调用代理对象的方法 →TransactionInterceptor拦截 → 根据TransactionDefinition获取或创建事务 → 执行业务方法 → 根据执行结果提交或回滚 → 清理线程绑定的Connection。这条链路里任何一个环节出问题都会导致事务行为不符合预期。比如TransactionDefinition里的传播行为配错了就会出现“明明抛了异常却没回滚”或者“不该回滚的时候回滚了”。3. 核心配置与实操要点全解析3.1 开启声明式事务的两种方式在Spring Boot项目里最简单的方式是直接在启动类或者配置类上加EnableTransactionManagementConfiguration EnableTransactionManagement public class TransactionConfig { // 数据源和JdbcTemplate的配置 }不过实际上如果你用的是Spring Boot的spring-boot-starter-jdbc这个注解通常可以省略。因为DataSourceTransactionManagerAutoConfiguration会自动配置一个DataSourceTransactionManager而TransactionAutoConfiguration会在检测到PlatformTransactionManager存在时自动启用事务管理。也就是说只要你引入了JDBC starter并且配置了数据源声明式事务就已经可用了。但如果你用的是多数据源或者需要自定义事务管理器那就必须手动配置。比如Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { return new DataSourceTransactionManager(dataSource); }这里有个细节DataSourceTransactionManager的构造函数接收DataSource它会通过DataSourceUtils.getConnection()来获取连接。如果你在事务方法里直接用dataSource.getConnection()拿到的会是另一个连接事务自然就不生效了。所以务必确保你的DAO层用的是JdbcTemplate或者通过DataSourceUtils获取连接。3.2 Transactional注解的关键属性Transactional注解有一堆属性常用的就那么几个但每一个都值得说清楚propagation传播行为这是最容易出问题的属性。默认是REQUIRED意思是如果当前没有事务就新建一个如果有就加入。其他常用的还有REQUIRES_NEW挂起当前事务新建一个独立事务、NESTED嵌套事务基于保存点、SUPPORTS有事务就用没有就非事务执行、NOT_SUPPORTED挂起当前事务非事务执行。isolation隔离级别默认是DEFAULT也就是用数据库的默认隔离级别。MySQL的InnoDB默认是REPEATABLE_READOracle默认是READ_COMMITTED。一般情况下不需要改除非你有特殊的并发需求。timeout超时时间单位是秒默认是-1不超时。如果某个事务可能执行很久建议设置一个合理的超时时间避免长时间占用连接。readOnly只读默认是false。设置为true时Spring会做一些优化比如设置Connection的readOnly属性某些数据库驱动会据此优化查询。但要注意只读事务里如果执行了写操作行为取决于数据库实现不一定会报错。rollbackFor回滚异常默认只对RuntimeException和Error回滚受检异常不会触发回滚。这是很多人踩过的坑——方法里抛了IOException事务却没回滚。解决办法就是显式指定rollbackFor Exception.class。noRollbackFor不回滚异常指定哪些异常不触发回滚用的比较少但在某些业务场景下有用。3.3 传播行为的选择逻辑与实战场景传播行为是声明式事务里最抽象的部分我用几个实际场景来说明怎么选场景一订单创建 库存扣减。这两个操作必须在同一个事务里要么都成功要么都失败。用默认的REQUIRED就行因为它们是同一个业务方法里的连续操作。场景二订单创建 发送通知。发送通知失败不应该导致订单回滚这时候可以把发送通知的方法标注为REQUIRES_NEW让它在一个独立事务里执行。但要注意如果通知方法内部抛了异常外层事务不会回滚你需要自己catch住。场景三批量导入每条记录独立事务。比如导入1000条数据希望某一条失败不影响其他条。这时候可以在循环里调用一个标注了REQUIRES_NEW的方法每条记录一个事务。但这样性能会很差因为每次都要新建连接。更好的做法是用批量操作 保存点或者干脆不用事务靠数据库的唯一约束来保证一致性。场景四嵌套调用内层失败不影响外层。用NESTED传播行为内层事务基于保存点内层回滚不会导致外层回滚。但NESTED需要数据库支持保存点MySQL的InnoDB是支持的。实操心得传播行为的选择没有绝对的对错关键是想清楚“内层失败时外层应该怎么办”。如果外层必须回滚用REQUIRED如果外层不受影响用REQUIRES_NEW或NESTED如果外层有没有事务都行用SUPPORTS。3.4 事务管理器与数据源的绑定关系DataSourceTransactionManager在开启事务时会通过TransactionSynchronizationManager把Connection绑定到当前线程的ThreadLocal里。后续在同一个线程里调用JdbcTemplate它会通过DataSourceUtils.getConnection()拿到这个已经绑定的Connection从而保证所有操作都在同一个事务里。这个机制有一个重要的推论事务是线程绑定的。如果你在事务方法里开了新线程去执行数据库操作新线程拿不到绑定的Connection事务自然就不生效了。这是多线程场景下事务失效的根本原因。另外如果你在事务方法里手动调用了dataSource.getConnection()拿到的也是一个新连接不受事务管理。所以务必统一使用JdbcTemplate或者DataSourceUtils。4. 完整实操流程与关键环节实现4.1 项目依赖与基础配置先给出一个最小可运行的配置。假设你用的是Maven依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependencyapplication.yml里的数据源配置spring: datasource: url: jdbc:mysql://localhost:3306/demo?useSSLfalseserverTimezoneUTC username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 30000这里用的是HikariCP连接池Spring Boot默认就是它。连接池的配置直接影响事务的表现如果maximum-pool-size太小高并发下事务方法会因为拿不到连接而超时如果connection-timeout太短稍微慢一点的查询就会报错。一般建议maximum-pool-size设置为数据库最大连接数的70%左右connection-timeout至少30秒。4.2 一个完整的业务场景转账转账是经典的事务场景涉及两个账户的余额变动。先建表CREATE TABLE account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, balance DECIMAL(18, 2) NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0 );然后写DAO层用JdbcTemplateRepository public class AccountDao { private final JdbcTemplate jdbcTemplate; public AccountDao(JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } public BigDecimal getBalance(Long id) { return jdbcTemplate.queryForObject( SELECT balance FROM account WHERE id ?, BigDecimal.class, id); } public int deduct(Long id, BigDecimal amount) { return jdbcTemplate.update( UPDATE account SET balance balance - ? WHERE id ? AND balance ?, amount, id, amount); } public int add(Long id, BigDecimal amount) { return jdbcTemplate.update( UPDATE account SET balance balance ? WHERE id ?, amount, id); } }Service层用TransactionalService public class TransferService { private final AccountDao accountDao; public TransferService(AccountDao accountDao) { this.accountDao accountDao; } Transactional(rollbackFor Exception.class) public void transfer(Long fromId, Long toId, BigDecimal amount) { int deducted accountDao.deduct(fromId, amount); if (deducted 0) { throw new IllegalStateException(余额不足); } accountDao.add(toId, amount); } }这段代码有几个关键点rollbackFor Exception.class确保受检异常也回滚deduct方法里带了balance ?条件防止余额扣成负数如果扣减失败直接抛异常事务回滚。4.3 参数计算与边界条件处理转账场景里金额的计算必须用BigDecimal不能用double。BigDecimal的subtract和add方法会返回新对象不会修改原对象。比较金额时用compareTo而不是equals因为equals会比较精度。BigDecimal a new BigDecimal(100.00); BigDecimal b new BigDecimal(100.0); System.out.println(a.equals(b)); // false System.out.println(a.compareTo(b)); // 0数据库字段用DECIMAL(18, 2)对应Java的BigDecimal。JdbcTemplate在查询时会自动映射但要注意MySQL的DECIMAL返回的BigDecimal精度和scale是准确的不需要额外处理。边界条件方面需要处理金额为负数或零、转出账户和转入账户相同、账户不存在、余额不足。这些判断最好在Service层做抛出自定义异常让事务回滚。4.4 事务执行过程的日志观察想确认事务是否真的生效最直接的办法是打开Spring的事务日志。在application.yml里加logging: level: org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG org.springframework.transaction.interceptor: TRACE启动后调用转账方法你会看到类似这样的日志Creating new transaction with name [com.example.TransferService.transfer]: PROPAGATION_REQUIRED, ISOLATION_DEFAULT Acquired Connection [HikariProxyConnection123456] for JDBC transaction Switching JDBC Connection to manual commit Initiating transaction commit Committing JDBC transaction on Connection [HikariProxyConnection123456] Releasing JDBC Connection after transaction如果看到Creating new transaction说明事务开启了看到Committing说明提交了。如果方法抛异常会看到Initiating transaction rollback和Rolling back JDBC transaction。这些日志是排查事务问题的第一手资料。注意日志级别调到TRACE会输出大量信息生产环境不要长期开启排查完记得改回去。5. 常见问题与排查技巧实录5.1 事务失效的六大场景声明式事务失效是最高频的问题我整理了一个速查表失效场景原因解决办法同类内部方法调用this调用不走代理注入自身代理或用AopContext.currentProxy()方法不是publicSpring AOP只代理public方法改成public或用AspectJ模式异常被catch异常没抛到代理层在catch里重新抛出或手动回滚rollbackFor没配默认只回滚RuntimeException显式指定rollbackFor Exception.class多线程调用事务绑定在ThreadLocal避免在事务方法里开新线程操作数据库数据源不匹配事务管理器和DAO用的不是同一个DataSource检查配置确保统一其中同类内部调用是最隐蔽的。比如Service public class OrderService { public void createOrder() { this.doCreate(); // 这里不会走代理事务不生效 } Transactional public void doCreate() { // 数据库操作 } }解决办法有三种一是把doCreate抽到另一个Service里二是注入自身Service public class OrderService { Autowired private OrderService self; public void createOrder() { self.doCreate(); // 通过代理调用 } }三是用AopContext.currentProxy()但需要开启exposeProxy true。5.2 事务不回滚的排查思路遇到“抛了异常但数据还是写进去了”的情况按这个顺序排查第一步确认异常类型。如果是受检异常检查rollbackFor有没有配。默认只回滚RuntimeException和Error。第二步确认异常有没有被吞掉。在catch块里打日志看看异常是不是被捕获后没有重新抛出。第三步确认方法是不是public。非public方法不会被代理。第四步确认调用方式。是不是同类内部调用是不是通过new创建的对象第五步打开事务日志看有没有Creating new transaction。如果没有说明事务根本没开启。第六步检查数据源。如果项目里有多个数据源确认事务管理器和DAO用的是同一个。5.3 传播行为导致的“诡异”现象有一次我遇到一个场景外层方法标注了Transactional内层方法标注了REQUIRES_NEW结果内层方法执行完后外层方法抛异常内层的数据却没有回滚。这其实是符合预期的——REQUIRES_NEW会挂起外层事务新建一个独立事务内层事务提交后就和外层无关了。外层回滚不会影响已经提交的内层事务。反过来如果内层用NESTED内层回滚只会回滚到保存点外层可以选择继续或者也回滚。但NESTED有个限制它依赖JDBC的保存点如果数据库不支持保存点比如某些NoSQL就会退化成REQUIRED。还有一个常见的坑REQUIRES_NEW需要一个新的数据库连接。如果连接池满了内层事务会一直等连接导致外层事务也卡住。在高并发场景下要特别注意连接池的配置。5.4 只读事务的误区Transactional(readOnly true)经常被当成性能优化手段但实际上它的效果取决于数据库和驱动。在MySQL里设置readOnly后驱动会发送SET SESSION TRANSACTION READ ONLY但InnoDB并不会因此做特殊优化。真正的优化是告诉数据库“这个事务里不会有写操作”某些数据库可以据此减少锁的开销。但要注意只读事务里如果执行了写操作MySQL会直接报错Cannot execute statement in a READ ONLY transaction而有些数据库可能只是忽略。所以不要以为加了readOnly true就绝对安全该做的校验还是要做。另外readOnly对JdbcTemplate的查询没有额外优化它只是设置Connection的属性。如果你真的想优化查询性能应该从索引、SQL语句、连接池配置入手。5.5 事务超时与连接泄漏Transactional(timeout 5)设置的是事务的超时时间单位秒。超时后Spring会尝试回滚事务但实际行为取决于数据库驱动。有些驱动会在超时后抛出异常有些则不会立即中断正在执行的SQL。更危险的是连接泄漏。如果事务方法里手动获取了Connection但没有关闭或者某个操作阻塞了很长时间连接池的连接会被耗尽。排查连接泄漏可以用连接池的监控功能比如HikariCP的leakDetectionThresholdspring: datasource: hikari: leak-detection-threshold: 60000设置60秒如果连接超过60秒没归还就会打警告日志。这个阈值不要设太小否则正常的长事务也会被误报。6. 进阶技巧与个人经验补充6.1 多数据源下的事务管理多数据源场景下每个数据源需要独立的事务管理器。如果你在一个方法里同时操作两个数据源默认情况下只有一个事务管理器生效另一个数据源的操作不在事务里。解决办法是用ChainedTransactionManagerSpring 5.3之前或者JtaTransactionManager需要XA支持。但更实际的做法是尽量避免跨数据源的强事务用最终一致性方案替代。如果确实需要可以这样配置Bean public PlatformTransactionManager transactionManager( DataSource primaryDataSource, DataSource secondaryDataSource) { DataSourceTransactionManager primary new DataSourceTransactionManager(primaryDataSource); DataSourceTransactionManager secondary new DataSourceTransactionManager(secondaryDataSource); return new ChainedTransactionManager(primary, secondary); }但要注意ChainedTransactionManager并不是真正的分布式事务它只是按顺序提交多个事务管理器如果第二个提交失败第一个已经提交了无法回滚。所以它只适合“两个数据源的操作大概率都成功”的场景。6.2 事务与异步的配合在事务方法里发异步消息或者调用异步方法要特别小心。因为异步方法在新线程里执行拿不到事务绑定的Connection也不会参与事务。如果你希望异步操作在事务提交后再执行可以用TransactionSynchronizationManager.registerSynchronizationTransactionSynchronizationManager.registerSynchronization( new TransactionSynchronization() { Override public void afterCommit() { // 事务提交后执行 asyncService.doSomething(); } } );这样能保证异步操作只在事务成功提交后触发避免“事务还没提交异步操作已经读了旧数据”的问题。6.3 事务边界的粒度控制事务边界不是越大越好。一个大事务会持有连接很长时间增加锁竞争降低并发能力。我的一般原则是事务里只放必要的数据库操作远程调用、文件IO、复杂计算都放到事务外面。比如一个下单流程校验参数 → 查询库存 → 扣减库存 → 创建订单 → 发送通知。其中“查询库存”可以放在事务外“扣减库存”和“创建订单”放在事务内“发送通知”放在事务提交后。这样事务的持有时间最短并发能力最强。6.4 一个容易被忽略的细节事务与缓存如果你在事务方法里操作了缓存比如Redis要注意缓存和数据库的一致性。常见做法是先更新数据库再删除缓存但如果在事务提交前删了缓存其他线程可能读到旧数据并重新写入缓存。更稳妥的做法是用afterCommit回调来删缓存TransactionSynchronizationManager.registerSynchronization( new TransactionSynchronization() { Override public void afterCommit() { redisTemplate.delete(cacheKey); } } );这样能保证缓存删除发生在数据库提交之后减少不一致的窗口。6.5 测试环境下的事务回滚写单元测试时经常希望测试完数据库回到初始状态。Spring Test提供了Transactional注解加在测试类上每个测试方法执行完后会自动回滚SpringBootTest Transactional public class TransferServiceTest { Autowired private TransferService transferService; Test public void testTransfer() { transferService.transfer(1L, 2L, new BigDecimal(100)); // 断言... } }但要注意如果测试方法里用了REQUIRES_NEW传播行为内层事务会独立提交不会随外层回滚。这种情况下需要手动清理数据。6.6 生产环境的事务监控生产环境里事务的执行情况需要监控。可以自定义一个TransactionSynchronization在事务提交或回滚时打点public class TransactionMonitor implements TransactionSynchronization { private final long startTime System.currentTimeMillis(); Override public void afterCompletion(int status) { long cost System.currentTimeMillis() - startTime; if (status STATUS_COMMITTED) { metrics.recordCommit(cost); } else { metrics.recordRollback(cost); } } }然后在事务方法里注册这个监听器。这样能统计事务的提交率、回滚率、平均耗时对排查性能问题很有帮助。7. 写在最后的一些实操体会声明式事务看起来只是加个注解的事但真正用好需要理解它背后的代理机制、线程绑定、传播行为。我踩过的坑里大部分都是因为“想当然”——以为加了注解就万事大吉结果同类调用失效、异常被吞、传播行为配错各种问题层出不穷。我的建议是新项目里所有涉及多表写操作的方法都显式加上Transactional(rollbackFor Exception.class)不要依赖默认值。传播行为除非有明确需求否则一律用默认的REQUIRED。事务方法尽量保持public避免同类内部调用。测试环境打开事务日志确认事务真的生效了再上线。还有一点事务不是银弹。有些场景用事务反而会带来性能问题比如大批量导入、长耗时的业务操作。这时候可以考虑用补偿机制、状态机、最终一致性方案来替代强事务。技术选型没有绝对的对错关键是匹配业务场景。最后分享一个排查事务问题的小技巧在事务方法的第一行打一条日志在最后一行也打一条然后打开DataSourceTransactionManager的DEBUG日志。如果两条业务日志之间没有事务日志说明事务没生效如果有Creating new transaction但没有Committing说明事务回滚了。这个方法简单粗暴但非常有效。
语法分析器对接collegevm5)
