Spring的事务机制详解：3个核心原理让你面试不再卡壳

面试被问到 Spring 事务隔离级别时，你是不是脑子一片空白？明明用了 @Transactional，为什么数据还是不一致？别慌，今天我们把 Spring 事务的底层逻辑拆碎了讲，从 JDBC 连接池到 AOP 拦截器，带你彻底搞懂这套机制。掌握这些最佳实践，不仅能应付面试，更能解决生产环境中的脏读、幻读难题。

一句话原理：基于代理的 JDBC 事务控制

Spring 事务的核心本质，是对 JDBC Connection 对象的状态管理。它通过 AOP 动态代理，在目标方法执行前后插入事务控制逻辑，将业务代码的执行包裹在 Connection 的 commit 和 rollback 之间。这不是魔法，而是对 Java 标准事务 API 的优雅封装。

类比解释：餐厅服务员的“订单打包”流程

想象你是一家餐厅的服务员（Spring 事务管理器），顾客点了一桌菜（业务代码）。服务员不会每做一道菜就端给顾客，而是等所有菜做完，统一检查无误后（验证逻辑），再一次性打包送到前台（Commit）。如果中间发现某道菜没做熟（抛出异常），服务员会立刻通知厨房全部重新做，而不是把做好的端走（Rollback）。

关键在于：服务员手里只有一个托盘（JDBC Connection）。如果托盘满了或者被其他服务员抢走了，他就没法完成打包。这就是为什么我们需要理解 Spring 是如何持有和管理这个“托盘”的。

源码剖析：TransactionInterceptor 如何拦截你的方法

Spring 事务的实现核心在于 TransactionInterceptor。当你的服务类被标记为 @Transactional 时，Spring 容器会为其创建一个代理对象。当你调用该方法时，实际执行的是代理对象的逻辑。

// 简化版的 TransactionInterceptor 核心逻辑
public Object invoke(MethodInvocation invocation) throws Throwable {// 1. 获取当前方法的事务属性（隔离级别、传播行为等）TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(invocation.getMethod());// 2. 如果方法没有事务属性，直接执行原方法if (txAttr == null) {return invocation.proceed();}// 3. 开启事务：从 DataSource 获取 Connection，并绑定到当前线程TransactionStatus status = transactionManager.getTransaction(txAttr);try {// 4. 执行业务逻辑Object result = invocation.proceed();// 5. 提交事务：调用 Connection.commit()transactionManager.commit(status);return result;} catch (Throwable ex) {// 6. 回滚事务：调用 Connection.rollback()transactionManager.rollback(status);throw ex;}
}

这段伪代码揭示了真相：Spring 并没有修改你的业务代码，它只是在你的代码外面套了一层“壳”。这个壳负责管理 Connection 的生命周期。

流程描述：从方法调用到数据库落盘

让我们跟踪一次典型的事务执行流程，看看数据是如何从内存流向磁盘的：

代理拦截：调用 userService.save()，请求被 JdkDynamicProxy 或 CGLIB 代理拦截。
属性解析：TransactionInterceptor 读取 @Transactional 注解，解析出 propagation=REQUIRED，isolation=DEFAULT。
获取连接：DataSourceTransactionManager 从连接池（如 HikariCP）中获取一个 Connection 对象。
绑定线程：该 Connection 被放入 ThreadLocal 中，确保当前线程内的所有 DAO 操作都使用同一个连接。这是理解“事务内共享连接”的关键。
执行 SQL：MyBatis 或 JPA 执行 SQL 时，会从 ThreadLocal 中取出这个 Connection，而不是重新从连接池获取。
状态判断：方法执行完毕，无异常，调用 connection.commit()。
释放资源：Connection 归还连接池，ThreadLocal 清除引用。

关键点：如果在第 5 步中，你手动调用了 connection.commit()，那么第 6 步的 Spring 事务提交就会失效，因为数据库层面已经提交了。这就是很多开发者踩坑的地方。

实战验证：为什么你的事务失效了？

在真实项目中，事务失效是最常见的问题。以下三个场景，你能识别出几个？

场景一：自调用失效

@Service
public class OrderService {public void createOrder() {// 这里的调用不会触发事务，因为 this 是原始对象，不是代理对象this.validateStock(); }@Transactionalpublic void validateStock() {// 业务逻辑}
}

原因：Spring 事务基于代理，this 指向的是原始对象，没有经过 AOP 拦截。 解决方案：注入自身代理，或使用 AopContext.currentProxy()。

场景二：异常被吞掉

@Transactional
public void pay() {try {deductBalance();} catch (Exception e) {log.error("支付失败", e);// 异常被捕获，没有抛出，Spring 认为方法执行成功}
}

原因：Spring 默认只对未检查异常（RuntimeException）和 Error 进行回滚。如果异常被 try-catch 吞掉，Spring 无法感知错误。 解决方案：在 @Transactional 中指定 rollbackFor = Exception.class，或者在 catch 块中手动标记回滚 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。

场景三：非 public 方法

@Transactional
void updateStatus() {// 业务逻辑
}

原因：Spring 事务默认只拦截 public 方法。虽然 CGLIB 可以代理 public 和非 public 方法，但 Spring 的 AnnotationTransactionAttributeSource 默认只识别 public 方法上的注解。 解决方案：将方法改为 public，或自定义 TransactionAttributeSource。

进阶技巧：隔离级别与并发控制

在市政公用工程中，涉及资金结算、资源分配等场景，数据一致性要求极高。理解事务隔离级别至关重要。

隔离级别	脏读	不可重复读	幻读	适用场景
READ_UNCOMMITTED	是	是	是	几乎不用，性能最高但风险最大
READ_COMMITTED	否	是	是	通用场景，Oracle 默认
REPEATABLE_READ	否	否	是	MySQL 默认，通过 MVCC 解决大部分并发问题
SERIALIZABLE	否	否	否	极高一致性要求，性能最低

注意：MySQL InnoDB 在 REPEATABLE_READ 级别下，通过 Next-Key Locking 机制，实际上避免了大部分幻读问题。但如果你使用的是 MyISAM 引擎或特定数据库，隔离级别的表现可能不同。

最佳实践建议：

短事务原则：事务应尽可能短，避免在事务内进行远程调用（RPC/HTTP），这会长时间占用数据库连接，导致连接池耗尽。
只读优化：对于查询操作，使用 @Transactional(readOnly = true)，Spring 可以对此进行优化，如使用主从库的从库查询。
传播行为：默认使用 REQUIRED。如果方法不需要事务，明确使用 NOT_SUPPORTED 或 SUPPORTS，避免不必要的事务开销。

底层细节：JDBC 规范与 Spring 的映射

根据 JDBC 规范（RFC 相关标准虽不直接定义 JDBC，但遵循类似的连接管理思想，具体参考《Java Database Connectivity Reference Manual》），Connection 对象是事务的载体。Spring 的 PlatformTransactionManager 接口定义了一组标准方法，将底层数据库的差异抽象化。

例如，HibernateTransactionManager 和 JtaTransactionManager 都实现了这个接口，但内部实现不同。JTA（Java Transaction API）支持跨数据源的事务，适用于分布式系统。而在单体应用中，JDBC 事务管理器更为轻量高效。

在市政公用工程系统中，如果涉及多个微服务（如计费服务、工单服务、资源服务），可能需要引入 JTA 或分布式事务方案（如 TCC、Saga）。但此时，Spring 的本地事务管理依然是基础，每个微服务内部仍需保证自身数据的一致性。